Yesterday I read the post "Approaches how to scale agility" on the Zühlke Blog.
The topic is close to several ramblings I have published recently here on my blog:
- Something went wrong with Scrum: Analogies with the Underpant Gnomes and Sovjet Era Deathmarches
- Paradise Lost: SAFe banned from the Agile Heaven?
- Not happy with Agile, but why?
Of course I could not sit still and I posted a sarcastic comment on the post on the Zühlke Blog:
I knew about SAFe, but I am amazed at how many other approaches there are at milking the Agile cow... must be one hell of an udder!
The comment was published (I am a more or less regular commenter on the Zühlke Blog). However this morning the comment was deleted.
Ok I get it, this is a corporate blog, no place for sarcasm!
So I tried to formulate a more constructive comment about the topic of "Scaling Agile". It resulted in yet another ranting, which is now waiting moderation… unsure if it will pass the publication requirements (no sarcasm, what about criticism?) I decided that it actually is a post of its own...
Why I don't believe in scaling Agile to the Enterprise:
I am personally very sceptical about scaling Agility. Probably because of my understanding of "Agile". I think there is still no common understanding what Agile really means. Since there is no such common understanding, I think Agile is still mainly a marketing term that has probably reached the peak of its hype-curve. On this peak many people try to make money from it, and since money is in the enterprise there are a lot of attempts to marry Agile with the enterprise.
My current understanding of Agile is best described by the "Agile as a Doctrine" by Jason Yip:
1. Reduce the distance between problems and problem-solvers
2. Validate every step
3. Take smaller steps
4. Clean up as you go
Let's take SAFe as an example: Is there a visible attempt at adressing those points? I don't think so...
- Instead of reducing the distance between problems and problem-solvers we introduce more layers of indirection with several layers of "architects", "product owners" and "customer proxies". We add several layers of processes for roadmaps, plannings and priorizations. We introduce portfolio-, product- and release-management and build up several layers of backlogs. (example)
- Instead of validating small steps we focus on long-term roadmaps. We increase our effort in crafting complete backlogs. We believe that tracking activities on a micro level will somehow lead us to success.
- We have a hard time focusing on value, therefore we keep ourselves busy with optimising for productivity.
This is in my opinion a return to the waterfall. Of course, this is not a new insight: According to Forrester Water-Scrum-fall is the reality of Agile today.
Can we change that? I don't think so. I think most smart people understand the concepts of Agile in theory. I also think that most successful people today are applying Agile principles to their everyday work and personal lives.
However I have the feeling that Agile just does not scale well on big projects or on big organisations. The bigger a project/organisation the bigger the need for structure and formalism. At a certain size you need plan driven approaches. Sad as it sounds, trust can't be the main pillar of big organisations / big projects. Therefore people need a plan and the option to blame. And there is the inherent conflict with Agile.
In my opinion Agile works for small, enthusiastic teams where you can base everything on trust. It does not work in corporate environments. Of course there are exceptions (see Github Inc, or Valve ...), but they are really not comparable with typical management driven corporations.
And let's face it: Our management driven economy was very successful in the last decades. Waterfall worked! Plans worked! Management was successful!
Of course recent trends (i.e. trend to more knowledge work) seem to imply a change. Embracing Agility is also a consequence.
But I think the trend results in questioning the reason for the existence of large corporations. Why do we need large corporations in a purely knowledge-based and perfectly networked work environment?
I think that is the ultimate consequence of embracing Agility: Not scaling it to the big corporation, but denying the reason for corporations altogether.
Sadly consultants would not make money with that message...
Update (2014-02-16): Thanks to Scott Ocamb for replying to my post here: Scaling Agile - What does this even mean?
Update (2014-02-25): Thanks to Erwin van der Koogh for his highly interesting reply: Scale Agile by Scaling Autonomy
Jonas
ReplyDeleteI believe you're looking at this from the wrong perspective. You're thinking "Compared to the Agile I've used, how well does SAFe comply with Jason's (excellent) definition?" And the answer is "Less"
The more useful comparison is "Compared to companies who are very large and have not yet done any Agile, find it frightening and risky but are attracted by the benefits, how well does this compare with Jason's criteria?" and the answer is "A lot more"
Because if you truly believe that such organisations SHOULD not do Agile then you're effectively saying that Waterfall is the best model for them. And I don't agree, and am not prepared to abandon them.
Agility is not binary, and should not be subject to shibboleths of doctrinal purity.
This comment has been removed by the author.
ReplyDeleteMartin: clearly the post isn't saying that large organisations should not do Agile or that they should do waterfall. It's asserting that large organisations are a consequence of high-friction operating environments. As we move to a more integrated, disintermediated landscape, the necessity for large corporates falls away (perhaps) and the question of what large corporates should do (and so the need to scale agile) becomes somewhat irrelevant.
ReplyDeleteDo you think that there are only two SDLCs - Agile and Waterfall? And perhaps large organisations should evolve and adapt rather than simply try to assert an inappropriate (for them) set of methods.