After reading the brilliantly inspired Half Arsed Agile Manifesto I was reminded of a recent phenomenon that has cropped up on CVs throughout the land.
"Adept at managing projects using Agile within a Prince2 Framework" - my first reaction is ha ha ha REJECT. Once I've reached the hundredth CV that contains this absurd claim however, it occurs to me that this is more widespread than I had feared.
Impulses tell me that Agile and Prince2 together in one sentence is like asking Christians and Atheists to co-write the Wikipedia entry on Evolution and yet I've had serious discussions with deadly serious individuals in serious organisations who are insulted when I suggest the contradictions at play. Organisations have hounded me to come in and interview for them; they proudly claim they have "perfected" Agile within a Prince2 framework and then we argue back and forth and suddenly they don't want me to work with them anymore. This doesn't mean that I'm some rigid Agile evangelist - but it does mean that I don't want to work for an organisation that fails to spot the inherent differences between the two frameworks. It also means that organisations don't want you if you fail to pay lip service to their lunacy.
Agile embraces change. It intuitively knows that projects will make mistakes and will require alterations throughout their life cycle. It doesn't erect boundaries and procedures to restrict this. It pre-empts change and hones it. It accepts it as a part of life. Prince2 safeguards against change rigidly and tries to deliver to the granular level every item as promised in the Project Initiation Document. When a change is requested, a committee meeting is held to assess the implications. The only thing they seem to share in common is the joint desire to "deliver a project".
What "Agile within a Prince2 framework" tells me within an organisational framework is somewhere that likes rhetoric such as "control" and "safeguard" at a Programme Management level but wants to appear to be cavalier and flair-driven at development level; in essence, it wants to have its cake and eat it. A project is never "finished" in Agile unless the stakeholder declares so - backlogs can always take extra submissions and work can always continue. You can't plan Agile projects using a Gantt chart if you accept that things will change as you go along. All you can promise is what you will attempt to deliver, on best endeavours, over the next iteration. Using velocity, you can estimate roughly how long the project should take, but only based on the current backlog that you have to work with.
Ultimately, what "Agile within a Prince2 framework" REALLY tells me is:
* An organisation who wants to appear Agile to excite potential investors
* An organisation who wants to appear Agile to tempt talented staff
* An organisation split in two - and both sides headbutting the other across the watercooler
* An organisation who doesn't get Agile or worse, doesn't believe in it but is doing it anyway.
I worry about where the industry is going. I feel like Robert Neville at the end of I Am Legend. The book, not the awful Will Smith film.
Wednesday, 30 March 2011
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 tooimportant busy for this"
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
Subscribe to:
Posts (Atom)