Don’t Iterate! Get It Right the First Time: We end up Iterating Because We Cannot Make Sense of the Data. Too Much Data Is Going to Waste
This is a story about a regular organization. It relays what happened after the Chief Executive Officer came back from a leadership conference and told his management team that they should adopt the Agile framework from that moment onwards.
The executive team asked a few questions and did a bit of research. Reading the Agile manifesto, they got excited by how easy it was. They passed around a memo that stated the Four Pillars of Agile as:
- “Individuals and interactions over processes and tools,
- Working software over comprehensive documentation,
- Customer collaboration over contract negotiation,
- Responding to change over following a plan.”
And set out to do just that.
They threw away some of their old software and ways of doing things. They set up an environment that had lots of meeting rooms and coffee break areas to encourage frequent interactions.
They didn’t document new changes because they felt that the constant face-to-face engagements would enhance productivity without the red tape. Besides, the idea was to create continuous results. If the software was the continuous result for a programming group, then constant social media campaigns were a measurable outcome for the marketing department.
They threw their customers’ dinners, invited them to join in some meetings, and felt betrayed when customers took some of the original ideas they had discussed over to the competitor to implement.
And finally, they did not bother their subordinates with great plans and how to implement them. Instead, they researched market trends, making statements like, “What are those guys at Spotify doing differently? Let’s try and do some of that here.”
After following these principles for six months and not seeing progress, they finally hired an Agile expert with an Information Technology background to come and spend time with their teams and show them how to “do Agile better.” But after two weeks, the expert’s opinion was that the company was not doing Agile at all.
The first thing he highlighted was how their strict hierarchical structure prohibited lower-level employees from providing direct feedback to their executive in areas in which the employees were the Subject-Matter Experts.
He told them that the company wanted functional results, but they were not allowing subordinates to know what kind of results they were expecting. Consequently, subordinates were working on ways to improve existing processes, to do the same thing better, rather than do a new thing well. They did not know what problems to solve.
He explained that the reason that Spotify had been successful in implementing Agile was due to re-organizing around self-managed, cross-functional teams that were goal-focused.
Where contracting was concerned, unfair negotiation practices resulted in customers having difficulty meeting some of the stringent requirements for payment. As a result, they would often come to the initial meetings to gather insight. But before being tied down by rigid contracts, they took these ideas to other organizations to develop.
Finally, not giving their employees goals and direction was making them lackluster. They felt that there were only so many ways to improve business processes without working towards an overarching goal. Any attempt to garner direction was met with responses about how the team should be self-led. This resulted in higher-performing employees starting to become disengaged.
He summed up his presentation by telling them that if the company wanted to implement Agile, it must implement all the concepts and not just the buzzwords.
The first thing that he highlighted to the executives was how the manifesto did not suggest ignoring processes and tools but instead preferring individuals and interactions over these. He told them how this was true for all the pillars of the Agile manifesto.
What was true for this organization is true for most organizations attempting to implement Agile today.
The way to overcome this is to understand why the Agile way of implementing development worked so well for computer programs in the first place.
The first clue is that when Agile was implemented over Waterfall, there was an emphasis on clearly defined customer expectations. In the example above, the executives could be seen as customers of the wider enterprise. However, by not documenting their vision and communicating it to subordinates, they were not giving the teams a problem to solve. There was no clearly defined customer objective. Thus, subordinates kept getting demotivated by the lack of growth in the organization.
To do Agile properly, executives needed to communicate what direction they wanted the company to advance in. Executives could create a general project plan to align with what would be called an epic in Information Technology. Self-directing teams could then use the epic as the target goal for their user stories and sprints while adjusting their internal processes and activities toward achieving this goal.
Contracts needed to be negotiated with an Agile mindset — that of seeing customers as partners. Therefore, terms and conditions needed to benefit both sides of the deal. Teams could adopt one of the Agile contracting types best suited for their project requirements.
The Incremental Delivery type, which allows payments to be made in stages, provides an optional walk away position at each stage. The Target Cost method ensures that the project’s overall cost does not exceed a predetermined amount by sharing any gains or losses that result from a variance from the initially agreed amount. The Capped Time and Materials approach curtails excessive expenditure by the supplier.
Additionally, any response to changes in the external environment needs to come from all levels. Those closest to creating services and products are best suited to adjust these and give customers what they need just in time.
What we can conclude then is that Agile is not failing business. Business is failing Agile because they have not taken the time to understand its roots and correctly translate the framework into their current environment. My advice would be to put the buzzwords and copycat behavior on the back burner. Instead, go back to basics. Before you iterate, Sprint, have Scrums and Epics — understand their original application, and set up processes that directly correlate. Who knows, future companies could be asking how you were able to become the market leader.
If you’re interested in reading more articles like this, here are a few links to my other articles:
How to Validate if Your Startup, New Business or Venture Will Succeed Using Fractals
What I Learned from 12,000 Executives and CEOs that Can Change Your Life
References
Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R. C., Mellor, S., Schwaber, K., Sutherland, J., & D. Thomas. (2001, February 13). Manifesto for Agile software development. Agile Alliance. https://agilemanifesto.org/
Byar, C., & Carr, B. (2020, September 18). Have we taken Agile too far? Bain and Company. https://www.bain.com/insights/books/doing-agile-right/about/doing-agile-wrong/
Cruth, M. (n.d.). Discover the Spotify model. Atlassian. https://www.atlassian.com/agile/agile-at-scale/spotify
Doing Agile wrong. (2020, September 18). Bain and Company. https://www.bain.com/insights/books/doing-agile-right/about/doing-agile-wrong/
Thoren, P. (2017). Agile People: A Radical Approach for HR & Managers (That Leads to Motivated Employees). Lioncrest Publishing.