Most organisations adopting Agile ways of working want the gain without the pain. They look to minimise organisational change, find ways to compromise and yet still expect to realise the benefits others have achieved through taking more radical action.
I've played leading roles in some agile disasters where pragmatism was used as an excuse to avoid tackling difficult challenges. I’d like to share some of that experience with you in the hope that you’ll see the warning signs and be able to correct your course before disaster strikes.
The agile manifesto provides some very clear statements of principles that we should all use to guide our ways of working, but I know I've been guilty of being too quick to compromise on these.
"Individuals and interactions over processes and tools"
I've coached teams where interactions between people are difficult by design. In the past many organisations consciously distributed their workforce to benefit from wage arbitrage or to access scarce skills. Creating effective teams in this environment requires people to work together who are geographically separated, work in different time-zones and may be employed by different companies.
This reflects the way organisations try to take a pragmatic approach to maximising the cost efficiency of the resources, but show limited interest in the principles behind effective teams. We all know that high performing teams work best when face-to-face interaction is the primary communication channel. It’s the best way to create a sense of belonging, common goals and a shared vision. And these days virtual face-to-face communication can be achieved, with high quality video conferencing facilities in dedicated team spaces, but this is too often overlooked.
The lesson is: when you encounter a team that isn't regularly communicating face-to-face ask why and what plans are in place to fix it? You’ll rapidly uncover deeply held beliefs that you’ll need to challenge and change.
"Working software over comprehensive documentation"
It is increasingly rare to find an organisation that openly values comprehensive documentation over software. However, too many organisations don’t appreciate the subtle but significant difference between maybe-working software and working software.
Let's be clear, working software is software that actually works. Software that is ready for user acceptance testing or integration with software written by other teams is maybe-working software, it might work, we don’t know.
The temptation, especially when scaling up, is to create definitions that result in acceptance of maybe-working software. That looks pragmatic but does not work as well as sticking to the principle of focusing on creating working software.
When you encounter a team that isn't creating working software, ask what plans are in place to fix this. You are likely uncover a number of technical issues that need resolving.
"Customer collaboration over contract negotiation"
Experience tells me that the majority of software created in large organisations is written by people who are not on that organisations’ payroll. This model can be brilliant, it allows the organisation to focus on being great at doing business things and provides access to technically talented teams of people.
All these teams have contracts, these are formally documented for external suppliers but how many contracts encourage and reward collaboration? Very few. How many organisations seek to engage talented teams of people with proven track records of collectively solving business challenges? Even fewer. It is tempting to compromise and just focus on the contractual necessities rather than tackle the more complex issue of what relationships and organisational structure support collaboration.
When you encounter a team where collaboration isn’t evident ask what is being done to enable and encourage it? The chances are that compromises have been made instead of confronting the need to implement fundamental organisational change to create a collaborative environment.
"Responding to change over following a plan"
There is an assumption that regardless of the agile framework adopted, responding to change will come naturally to all agile teams. Yet this can often be wrong.
Teams that create maybe-working software will have dependencies on other teams, and too many dependencies lead to complicated plans, and complicated plans will make responding to change painful and so the pragmatic response may be to try to avoid that pain.
Equally, teams that are funded through business cases or contracts that state what must be created will feel bound to stick to the contracted plan as that is easier than reviewing the contractual requirements.
When you encounter a team that is reluctant to change, even when faced with empirical evidence that shows they are doing the wrong thing, take a step back and seek to understand why. It is rarely laziness or apathy, it is more often due to an organisational blocker that is preventing the team from being responsive to change.
The Pragmatic Vegetarian
I'm a pragmatic vegetarian; for breakfast I have scrambled eggs, grilled tomato and mushrooms, baked beans and thick cut granary toast... and a couple of slices bacon. I've always had bacon with cooked breakfast, it is how breakfast is eaten around here.
In too many projects, pragmatism leads the organisation to accept compromises that prevent the benefits of agile ways of working being realised. In response, we all need to stick to the principles that make agile work, even if that means taking some tough decisions.