Agile is a philosophy which embraces (among other things) incremental delivery and improvement.
Yet some folks treat it as a binary, “you’re either doing it or you’re not”, operating model. They claim a team cannot embrace Agile principles without the whole organisation doing so.
This is a chicken and egg scenario which invariably results in a transformation stalemate.
What’s going on here? Is the effective adoption of agile values and principles being hampered by the very people who are promoting it?
The notion of Agile only working well if it is adopted by ALL people and teams across an organisation is one of the biggest mistakes agilists make when trying to encourage adoption of agile ways of working, IMO. The claim that all people and functional teams outside of I.T. (such as Sales, Operations, Marketing, Legal, etc.) need to immediately change how they are working to clear the way for the agile white knights to make everything better is a damaging one.
Clearly there is a significant irony at play here. People who claim to embrace Agile values and principles are pushing for big batch changes in “mindset” and practices across dozens, hundreds, sometimes thousands of employees. They’re all “doing it wrong”, apparently.
Agilists often bemoan the “dysfunctions” surrounding them. A common example of this is where a team’s Scrum Master or Agile Coach claims that their team wants to “do agile” but cannot because of one or more of these “impediments”:
- the team is not cross-functional
- the team has multiple dependencies
- the team is not working in a “value stream”
- the work is defined in projects and programs rather than products
- there is a separate QA/Ops/UX/UI team
- the work is prioritised incorrectly
- the work is not prioritised at all
- all work has equal priority
- the work is pushed into the teams
- there is no product vision
- there is no “product owner”
- the product owner is not acting like a product owner
- the product owner is a proxy and has no autonomy/authority
- there is not enough test automation
- there is too much WIP
- there is no time for improvement
- there is no UX person in the team
- etc. etc. etc.
The fundamental error in this “doom and gloom” approach is treating Agile as something you do, or need to convince or convert people to do. It isn’t.
Agile (ways of working) is something you SHOW people.
It is far easier to reject responsibility for one’s own situation than to get into the weeds and actually do the work to show that there are alternative, potentially better, approaches. Work isn’t prioritised? Have a crack at doing it yourself. Perhaps it hasn’t been prioritised because no one knows where to start. All work is defined in a big batch, with no small incremental release in sight? Try putting together a Lean Canvas and story map for the project to define a small but useful first release. Someone might be very grateful that you’ve done this, and start to see things they weren’t aware of beforehand. They will also tell you where your Lean Canvas and story map are “wrong”, including who else needs to input into them. Great! This now equips you with more knowledge to make them better, and further increase the chances of them being useful and thus used.
This technique of using small probes and activities — incremental experimentation to chip away at improvement by SHOWING agile techniques and practices in action — is a really effective way of shifting towards better and more enjoyable ways of working for all involved, and is by far the most pragmatic way of approaching agile adoption from the ground up. Sometimes these little gestures will not change anything, nor add any value. That’s fine. Some of them will, and when they do they are far more likely to stick, and promote further experimentation.
Organisations need to find their own version of what Agile means to them, given their short and long term improvement and/or delivery goals, and our job as agilists is to help them do that. “Agile” is an adjective not a noun. Like being “healthy” or “strong” or “virtuous”, the extent to which you can say you are Agile is a sliding scale — No, in fact it is many different but interconnected sliding scales, and few of them are linear.
Someone can be “healthy” in terms of their cardiovascular fitness and stamina, or their physical strength, but “unhealthy” in terms of the things they eat. Healthy in their positive and peaceful state of mind, unhealthy with their smoking. Being “healthy” is about finding contextual balances between things we like doing, dislike doing, should do and shouldn’t do.
Similarly, an organisation cannot binarily be Agile or Not Agile, and nor should it (or anyone else) care much about such a vanity metric. Its leaders might want to improve things in certain areas, or be quick to market with a particular product, and the use of Agile principles and techniques can most certainly help with these endeavours — in both small and large pockets across the organisation. There is nothing binary about this state of affairs, no matter what Agile thought leaders and large consultancies tell you.
Telling hundreds or thousands of people that they need to work differently from how they have been doing for sometimes many years is never going to result in anything other than bitterness and conflict. Particularly if you don’t SHOW them how to do this (and, “no”, facilitating a daily standup meeting or a story point estimation session doesn’t qualify).
If passionate agilists (like myself) really would like to see more agile organisations, we can influence this by doing the work to help people, teams and organisations improve on their own terms rather than pushing/cajoling/convincing/implementing our own agenda of ceremonies, processes and/or practices. Show people the benefits of story mapping by creating a story map yourself for the real work (with others if possible, but start on your own if not). Show people how to slice stories by slicing them yourself! Show people how to prioritise by prioritising the work!
Perhaps if more of us did this, Agile Coaches and practitioners would be listened to and respected more readily, and the failure rate of agile adoptions and transformations would decrease.
We are uncovering better ways of developing software by doing it and helping others do it.
~ Manifesto for Agile Software Development