About 10 years ago, Ken Schwaber (widely credited with being one of the founders of Scrum as we know it today) famously said in an interview “ … I estimate that 75% of those organizations using Scrum will not get the benefits that they hope for …”.  It is a remarkably candid statement and in my experience of working with different organizations as an Agile practitioner, trainer, coach and consultant, it has resonated with me.

Logic demands that iterative, incremental development should lead to more predictable outcomes, more flexibility and greater customer orientation. What comes in the way of value realization?

In this post, I describe some of the reasons that I have come across and what can be done about it.

  1. Organizations don’t change – they try to change Agile to fit into their dysfunctional ways. One team I knew had strong functional loyalties which insisted on keeping Developers and Testers apart. To the extent, that even their daily stand-up meetings were two part meetings. One “common” meeting and one meeting only of testers, where the other tribe was not permitted! If the organization encourages adversarial relationships, there is no way the team members will collaborate.
  2. Organizations don’t really trust their teams and lose the spirit of self-organization. One executive I knew insisted on 100% completion of sprint goals and would blow his top saying the team lacked accountability. Naturally, the team responded by getting ultra conservative about estimates and refused to take stretch goals. Then he complained that the team was not productive. In such an atmosphere, the team will never be truly self-organized and will not give results that they potentially can.
  3. Organizations treat Agile as “something that the team needs to do” and do not provide organizational support. One of the teams I worked with had a Product Owner who refused to write stories or come to demos. He wanted to write long requirement specifications and then not be bothered until the product was ready for release. A team without support from a Product Owner and the business will never be successful.
  4. Some organizations make a great beginning but lose momentum quickly. One of the teams saw tremendous value by bringing in automated builds and tests. But once they reached 20% test coverage, they refused to invest further in continuous integration. These practices quickly became obsolete and the team went back to their old ways after a few months.

I could go on and on.

The fact is that Agile on its own does not solve any problems. By asking you to deliver incrementally and learn along the way, it simply holds a mirror and gives you clues about where you need to focus next. If you do not act on these, you will never derive benefits from it, leading to the sad state of affairs that Ken Schwaber had seen long ago.

So what to do?

Appoint a process coach (call it Enterprise Agile Coach or Virtual PMO or whatever you like), who keeps you honest with regard to the basic principles of Agility. This could be an internal role or external. In my experience, it is always helpful from time to time to bring in an external coach to develop independent perspective and then transition to an internal organization to implement the necessary changes. If you think it is too costly, think again. Even a 2% gain in velocity or time to market would easily pay for a 3 year consulting assignment!

Here is an approach we like to take on Agile Consulting assignments.

Agile Consulting Assignments

This is what happens at each stage.

  1. Assessment: A comprehensive online assessment that looks at the Agility of an organization from different perspectives. It combines assessment of the COMPETENCY of the teams, the extent to which the PROCESS is embedded and the CULTURE of self-organization and continuous improvement. It also brings in different perspective assessments based on the stakeholders who are undergoing the assessments.
  2. Detailed Discovery: Based on the assessment, a plan is made to go through the potential issues in detail. This requires working with the teams with the feet on the ground to truly understand the underlying causes of the observations that the assessment brings out. This leads to a map of the existing processes.
  3. Improvement Backlog: Based on the discovery, the team gets into a workshop to compile the backlog of improvement actions necessary. The backlog is prioritized and responsibilities assigned to specific team members. Metrics are identified to track the progress on each initiative and improvement milestones are established.
  4. Implement: The team implements the improvement actions, executing several improvement sprints.
  5. Measure and Reflect: The outcomes from the actions are measured and tracked. Necessary course corrections may be implemented. Typically at this point the team is ready to take over the improved process.

The process is cyclical because after each step improvement and period of stabilization, the teams must challenge themselves and look for the next wave of improvements.

Get in touch if you want to know more and discuss how this can work for your organization.