More Than Cliche
Thanks to this post, I recalled several thoughts I once told some people quite a while ago about the nature of the agile practice.
At the core of that post is this:
“Agile cannot help you if managers continue to run the project and use teams as tools to build it up nor if the team is not mature enough to take responsibility and march together towards a shared and defined goal that quantifies success. Without trust and mutual respect, a team cannot achieve an Agile transformation; and yes, Agile would fail you every time.”
Culture, management, mindset shift. Deja vu, right?
There’s more than cliche here.
Misconceptions About Agile
Here are my two cents.
Agility can’t be evaluated and measured at the project level. Its deep implications for work culture shift require a far more holistic way of measuring the practice of designing, developing, and delivering.
Agile promises better results only in a probabilistic manner, and the granularity aims at the team and above level, not on the project or program level. It ties to measuring team or org performance, rather than assessing project performance. An agile project may or may not save money or deliver better product. However, an agile team is more likely to do both over the long term, resulting in even bigger benefits at the operational and strategic level of the org.
Agile performance is often harder to measure because it introduces dynamic and uncertain activities at the team level by imposing constraints (e.g. iteration over elaboration), and it relies on “what we don’t know” rather than “what we know” to manage risks. The former is tricky to “measure”, while the latter is the basis for metrics in traditional models like waterfall.
Understanding that probabilistic prospect of the agile practice requires an org to walk a fine line between pilot “proof-of-concept” initiative and faithful design management, both are risky if an org still operates in the good old way.
Don’t Transform Your People, Transform Your Org Instead
A common argument against the cliche of culture and mindset shift is that, you can’t except people to change as fast as Peter Parker gets bitten by a weird spider. Adopting agile is more of a cultural change than a technical or operational one, hence the conflict between short-term proof-of-concept and the long term shift.
While the above argument makes some sense, it’s missing the point when it comes to adopting Agile.
Because becoming agile is NOT about transforming an org’s people, but about transforming the org itself.
When the org is not transformable, it can’t be easily shaped when it comes to flexibility in structure, accountability, accounting, and risk management. And therefore it can’t easily facilitate a environment where people can practice Agile, even when people want to. And for the people who don’t, they’d never get a chance to change their minds.
Introducing the agile practice without transforming the org at the same time, is like abruptly asking your employees to jump from the 25th floor of the office building while promising them everything is going to be okay. Do you think they’d jump? Would you? They’d insist you don’t have to look and then fake it, and tell you how great it was afterwards – oops, that’s exactly how agile initiatives fail.
Your org needs to become transformable in the first place, so that you can shape the operation and risk management toward a feasible environment where people are accountable to do what agile practice requires, instead of being accountable for what the traditional accounting requires.
How to become a transformable org is beyond the scope of the post.
The good news is that I’m co-writing a book about it.
{END}
Noah Fang 
1 comment