A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily.
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?
The actual story starts here.
One of the very good things about our organization was the value system we believed in.
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions.
- Despite the invigorating opportunity, we would not sign the contract and begin immediately.
- We would do a discovery workshop first. The objective was to arrive at a clear problem statement.
- We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect.
- We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders/decision-makers in their software development process.
- The workshop would run for 3 days. We will present our findings on the final day post-lunch.
We communicated this to our customer’s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer.
The sessions were primarily design thinking tools. To name a few, we had planned futurespectives, retrospectives, value stream mapping, pain point analysis, anchors and engines, and so on.
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions.
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.
Takeaways:
- Agile is not a silver bullet
- Saying ‘NO’ to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)
- Collaborative workshops help. They are transparent, objective, and emergent.
- Definition of the problem and objectives reduce communication overhead.
- Design Thinking tools enable visual communication and bring people on the same page.
- Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.
