Thursday 24 March 2011

Agile Subverts The Archaic Corporate Class System

Poll for reasons as to why certain organisations fail to successfully adopt Agile and you'll be confronted with reflex responses that focus on development practices or zero in on the type of industry trying to "Agile" themselves.


I'm not going to launch into technical reasons why certain organisations struggle with Agile and Scrum. Rather, I'm going to focus on the ceremonial aspects of Scrum and why it poses a threat to the tacit Corporate Class System that exists in most mid-to-large scale corporate entities which in turn explains emotively why Agile isn't jumped upon like the latest Groupon Voucher. 


Waterfall
Compare the difference between how requirements are captured for a project between Waterfall and Scrum. Waterfall appeases all of the grandiose notions of a bygone Skyscraper age of big business and protects the status quo. You have some Bert Cooper ("Mad Men") character in his carpet office reading a hefty Project Proposal document that has been toiled over by minions he has probably never heard of. Too important to read the full document - Bert will skip to the part at the end of the 200 page treekiller whereby he will be promised how much the project will cost and how much the project will earn him. He will also be advised as to when the project will be completed.


The minions, fuelled with an increase in self-worth due to playing a part in this document, feel integral to the machinations of the big Corporate power wheel and treat the proposal as a sacred artefact; they'll argue amongst themselves as to wordings / sections and seek appropriate cross-departmental sign-off for every detail, to the most granular level. After all, Bert is reading this and signing if off. Also, stealth stakeholders claiming to have a vested interest in the project all jump out of the woodwork - demanding to read the proposal and red pen it before it reaches Bert. This document diminishes their hierarchical importance within the organisation if they don't have input into its content.


Bert might have a committee of Yes Men underneath him (The VP Berts) who will advise him accordingly, but ultimately he signs the cheques and therefore signs the Project Proposal - thus greenlighting it. His underlings will be sent turgid and regular reports as to the progress of the project whilst Bert plays golf in his office. They will also meet to frigidly protect the project from any flaky changes to the project. These changes are too trivial to annoy Bert with; underlings dream themselves of being Bert one day and do not want to deal with such small fry matters when they are in charge - so why would Bert?


Eventually the project drifts or the costs spirals or the requirements change or the dynamics of the industry itself changes...but it's too late to change / save the project now because look at the vast manpower and effort invested. The Software Engineers are probably to blame as the requirements were LOCKED DOWN in the project proposal and everyone signed it off then and had a chance to voice objections, so what's the difficulty now? And why the hell are so many changes required for this project? Why wasn't this thought of at the beginning? "That Project Proposal was a CONTRACT Goddamnit!"


The original sponsor of the project has left by now anyway as it was proposed X months ago and his/her replacement doesn't want to be politically associated with this failure. Bert and his VP Berts have already forgotten why the project was started in the first place and what the intended benefit was. No one can remember exactly, because the "fall guy" has already left. One thing is guaranteed, no one is going to read that two hundred page document again because they are "too busy."


By now, more projects have been commissioned anyway and Bert, flexing his muscle, removes the Technical Lead on the project due to the their incompetence of this failed delivery. The Project Managers, blinking out traffic light statuses throughout this failure, are contract only anyway and they take a job elsewhere with a higher daily rate. Working on one of Bert's projects looks good in their portfolio. Bert's rivals don't want to be outdone and so these Project Managers are snapped up after a twenty minute interview.


The next project proposal is four hundred pages long because no one wants to be the next fall guy and therefore a further level of detail and sign-off is required. Everyone is weary of Bert's trigger-happiness. 


Scrum
Transplant this set of characters to Scrum and you have a different story. Rather than a project proposal being scrutinised, the product backlog is stored in a central location and transparently available for everyone to see. No one but the most vested stakeholder contributes any requirements or user stories. If it's freely open for everyone to contribute then it cannot be important, surely?


One of the VP Berts is begrudgingly "demoted" / elected as product owner. They'll chat to Bert when he is in the country to work out what his priorities are for quick value and incremental release. Bert will be frustrated that he has a loose spreadsheet of "stories" serving as his requirements document as opposed to an important looking treekiller document and continually wants to know when the project will be finished so he can sell it to customers.


The VP Bert Product Owner resents having to "stand up" at a meeting with the lowly developers on a daily basis (don't get him started on the clapping for when a task is done! Business and Money are SERIOUS) and doesn't like having to wait till the end of this hippy new-age ceremony before he can ask questions to the developers. Also, why the casual office attire? What's wrong with chairs at a meeting? Furthermore, he cannot attend every standup due to "more important meetings" and so needs the developers to inform him when a "meaty" standup is coming so he can be sure to attend. But he needs notice.


Consequently, and to VP Bert Product Owner's dismay, this Project is like a needy girlfriend constantly requiring feedback and sampling. Every few weeks, the VP Bert Product Owner has to make ACTUAL CHOICES that shape and guide the product. Furthermore, if he is too busy to provide the feedback, the developers SIT AROUND AND DO NOTHING! 


"Surely someone was paid to shape the requirements at some PMO level when the original idea was conceived? With no weighty documentation and contractual sign-off process, suddenly the development cycle seems flaky and lacking structure. Also, you're telling me that in order to understand how the project is going I have to tell Bert to 'turn up to standups' rather than send him some metric-guided report on a frequent basis? Now I see from the retrospective that those lowly developers are blaming my lack of involvement in the product as to why it is slipping! I told them I had board meetings. Maybe we should regain control using waterfall - I'm too important  busy for this"

No comments:

Post a Comment