The Agile Scaling Checklist

When I first read The Checklist Manifesto by Dr. Atul Gawande it got me thinking about a checklist that could be effective and easy to use by my clients to help determine if a change they were considering making to a policy, a procedure, an organizational structure, facilities or a practice would improve their level or agility or impede it.

I thought I’d share my Agile Scaling Checklist with you to help the community, but also to start to get some feedback on it so that it may be further improved.

To utilize this checklist there are a few basic theorems that you should understand and agree with, otherwise you may not think the checklist is that helpful.

• Concept #1 – The most valuable quality of a software development organization is predictability in terms of time and quality.  This is true whether you are in an IT department producing systems for internal customers or at a commercial software company.  It is even more important in the commercial software development setting.  Much goodness flows from such predictability.  One of the most important benefits IMO, is that it fosters trust within the organization, with customers and with Wall Street.  Trust is the lubricant which makes teams, especially cross-functional teams, work more efficiently and effectively together and fosters continual process improvement.
• Concept #2 – Agile transformations require systems thinking.  When planning and making changes in an organization, you need to be aware of how one change will affect other aspects of the system or how one change can require changes in other areas of the organization to be successful.  This may sound like common sense, but it is shocking how few people take a holistic or systems view of their work, their life and the planet.One of my favorite organizational examples of this is an organization that begins touting the importance of cross-functional teams of people working as teams and delivering as teams, yet the incentive policies of the same organization reward individual performance and heroics – the “rock star” and “firefighter” mentality.

Ok, so if you accept these two concepts then I believe this checklist will be useful to you.

Consider this checklist as a tool for assessing whether an action is conducive to your successful agile transformation.  I like using it as a legend for documents / emails that propose changes that may affect the agile adoption. If a change doesn’t improve one of these facets of an effective agile organization then you should really question why you’re doing it. Of course you also don’t want a change that improves one while lowering others for a zero or negative net gain. But it should be understood, there is always give and take. This is why it is so important to have systems-oriented thinking when considering the impact of a change.

 
Agile Scaling Checklist

___ Trust

___ Collaboration

___ Transparency

___ Empowerment

___ Continuous Improvement

___ Simplicity

 

In my experience these are the key ingredients for a team / organization to reach predictability in terms of time and quality.

Let me explain a bit about each of the elements in this check list.

• Trust: Trust fosters open communication, and open communication increases the level of trust. If nurtured, trust continues to grow in this cycle.  Of course trust is a fragile thing, especially when you add variables like distributed agile teams where you lose the benefit of receiving the full meaning of someone’s message through their verbal and non-verbal communication.  Having an environment where it is safe to ask “why?” requires trust in management.  More on why this is important in a bit.
• Collaboration: Successful agile organizations have cross-functional, highly collaborative teams.  This results in engaging more of the skill sets involved in software product development earlier in the process.  Not only is the efficiency of the team improved, but also agile development practices such as TDD enable a team to be more effective at validating what they are building. This helps to ensure that the product is what the customer wants and that it delivers to the conditions of satisfaction.  And let’s not forget that sometimes over-used word, synergy.  Highly collaborative agile teams can enjoy a level of output that exceeds what the individuals on the team could accomplish on their own (just think back to waterfall, serialized, functionally silo-ed teams).
• Empowerment: This covers the areas of self-organizing and to some degree self-managing teams. These elements of an Agile Team are what make it capable of working efficiently with crisp decision making. Empowerment is also at the foundation of emergent design which to my experience is the most effective form of design because it adds the lean element of “last responsible moment” decision making. An empowered team has the necessary authority to realistically support their commitment to delivering a product backlog.

• Transparency: Agile teams that keep their current state of progress against a backlog visible on a day to day basis give the team and the organization the ability to see, as early as possible,  when trends in the basic metrics begin going in the wrong direction.  This ensures that the organization has the maximum number of options at its disposal to address the issue.  Teams that do not have transparency only communicate their problems when they reach the end of an iteration (or worse, release). At that point, the organization has no options to correct for issues, and the one option left is usually taken: Look for someone to blame – the blame game (truly a trust killer).
• Continuous Improvement: Agile development processes are learning processes, so a key ingredient for success is a Plan-Do-Check-Act cycle within any process.  Actions that dismiss or defer this cycle are damaging to a successful agile adoption.  Trust is woven in the fabric of continuous improvement as well; without it, getting to the root causes of issues can be challenging, and just treating symptoms of issues frequently doesn’t result in improvement.  Therefore once again we see the inter-connectivity of these ingredients.  Actions that damage trust will likely reduce the effectiveness of continuous improvement activities.  I mentioned before about the importance of having an environment where it is safe to ask why.  Asking why is at the heart of continuous improvement.  If there isn’t trust established both within teams and between teams and management that it is safe to ask “why,” this will impede continuous process improvement.
• Simplicity: This comes back to one of the principles found in the Agile Manifesto.  Simplicity is the art of maximizing the amount of work not done.  This applies in prescribed processes for requirements gathering, analysis and design as well as project management, coding and testing.

With this understanding of the Agile Scaling Checklist, I encourage you to give it a try and see how balanced your systems thinking is when proposing changes.  If anything it will draw you more into systems thinking, which in my experience can only be a good thing.

I will continue to post as the checklist evolves… Enjoy!