Princely agile

Whether running an agile project or a Prince 2 project, the principles at work are the same, in both cases a project is broken up into small pieces and regular formal inspection is applied to ensure alignment. It is in the detail of the how & why of that decomposition, and the interpretation & exercise of control, that important differences can be found. Another important difference is the level of prescription, Prince 2 attempts to describe the complete set of possible project contexts and states that the method should be pared to fit. Agile methods, like scrum, tend to prescribe very little and insist that context will determine how the method or framework should be extended for any given situation.

Ironically enough the majority of so-called Prince 2 projects are PINO (prince in name only), have few or no (non-project management) products defined and never include stages (which should not be confused with phases), nor the associated formal decision moments on how to proceed, or not. This means that stopping a project often only becomes an option when original deadlines and/or budgets have been thoroughly and spectacularly violated, more often than not without the delivery of any usable product whatsoever. The PID (project initiation document) often remains live deep into the project lifecycle, sometimes being finalised only when the project draws to a close (talk about gaming the numbers!).

Product based planning is a cornerstone of Prince2 and, if applied appropriately, can provide a link to agile methodologies. Appropriate application would involve hi-level specification of products during the Initiation phase, whereafter detail is added incrementally and iteratively, just-in-time and through collaboration with the team. Minimum viable product (or feature) should be the guiding principle in designing a product breakdown structure (PBS) - not process flow like requirements document, analysis document etc.

But if scrum is a framework for project management, why would you need Prince 2 at all?

Well, scrum is indeed sparsely prescriptive and basically says nothing about (financial) governance other than that it is up to the Product Owner. In fact the role of Product Owner is one of the most problematic aspects of scrum. Scrum says that the PO should have vision & authority and be (always) available to the team thereby ensuring maximum value delivery. This is a difficult assignment, and if the stakeholder and/or user landscape is complex enough, it requires nearly superhuman abilities to execute satisfactorily. A sparse version of Prince 2 could provide a solution here. Specifically, a steeringboard could provide a workable escalation channel in priority disputes (as long as it is still employed according to the principle of management by exception, i.e. at the discretion of the PO), and the maintenance of a formal business case might provide an explicit policy for the PO to work from from day to day.

I have used Gojko Adzic's (most excellent!) Specification by Example to create a mapping between Prince 2 phases (always mandatory != stages) and agile execution:

Project Start

• State goals (Brief/Mandate)
• Appoint Steering Board
• Appoint Project Manager or PO
• Assign existing team(s) to the project

Project Initiation

• Collaboratively determine scope (hi-level PBS e.g. in the form of Story Mapping/Initial creation of Product Backlog, consisting necessarily of primarily rough-grained stories)
• Create business case
• Collaboratively elucidate hi-level risks

An initiation phase could easily consist of a small number of sprints, this would ensure a much better understanding of scope & risk, and allow for using actual velocity in provisional (release) planning etc

Project Execution

• Managing stages & stage boundaries: Each iteration is closed with the demonstration of working software, actual progress is tangible and concrete which means that the validity of the business case can be continually reviewed and assessed with confidence. The definition of formal stages to this end may be overkill.
• Work package creation & acceptance (and associated wasteful hand-offs) are replaced by the ongoing collaborative activities of backlog grooming (“refining the specification”) & sprint planning. A project manager (if there is one) therefore has no role in activity planning.

Closing a project

• Lessons learned – continually generated during the project (review & retrospective)
• Product handover – not necessarily applicable if every sprint realises (potentially) shippable product
• Review goals

Et voila – princely scrum!

Of course, there are those who suggest that management generally (Radical Management, Management 3.0) and financial governance specifically (Beyond Budgeting) would also benefit hugely from an agile approach. I agree, princely scrum (if and when contextually appropriate) should be but a step on the road to imperious agility.

What's eating Bob Marshall? (A polemic)

Today, dear reader I present you with a polemic. I feel obliged to warn you before hand because polemics as a rule are not my favourite fodder, and you might prefer to be spared my petulant outburst, as indeed I tried to resist penning it. But I can't get no satisfaction, so here goes:

Alright! OK @flowchainsensei, we get it! The scribes and the Pharisees have taken over. And they're in bed with the money lenders. Agile is not the true gospel.

Bob Marshall (@flowchainsensei) is concerned for the state of our “broken industry”. Do we inhabit the same digital space? My world is turned upside-down & inside-out with increasing regularity. Are not many of the problems in fact a measure of the industry's success?

Yes, it's important to have people around who see the glass as half-empty but it's really tiresome to have people running around screaming “Fire!” all day because the toast was burnt at breakfast.

In his prolific railing against all that is wrong in the world (of software development) Marshall consistently pits Deming, Buckminster Fuller and Ackoff, the truly wise, against those pretenders from Snowbird (and especially their disciples), while simultaneously, incongruously, lambasting all that is agile as old-fashioned and even outright evil. Don Reinertsen rightly points out however that the implications of systems thinking are potentially “terrifying” and concrete manifestations of Buckminster Fuller's sociological ideas sundered quickly under the crushing weight of their naiveté.

Any utopia is an El Dorado, and anybody claiming to know the way there is necessarily a charlatan.

But let's just assume that Marshall has seen the light, and that if we follow him we will arrive in the promised land, what will it be like? Well, like all visions of paradise, it's pretty enticing, as per Marshall's own description. But how do we get there? According to Marshall - by way of an instantaneous mindset shift effected simultaneously throughout the entire organisation.

There are leaps of faith and leaps of faith.

Luckily, Marshall also offers more practical tips, like ditching CVs. I find that an attractive idea, but the associated technical advice is weak - “hire mindset, not experience; where someone wants to go is what counts, not where they've been”. That's anti-empirical and probably the best way ever devised for ensuring the hiring of the slithery of tongue.

Another good idea that he espouses is subsidiarity. Marshall's version however has something unsettlingly absolute to it and is tinged with begrudgery: Leave it all up to the ordinary people, the folks on the front lines, and everything will be fine. Workers good, managers bad. To me, it smacks of the worst kind of spiteful socialism.

Dialogue is another favourite of Marshall's in his search for a better world, although an exchange has to be of a very specific type before it can qualify as dialogue. When I posted a link to my response to Marshall's “Agile Coaching is Evil”as a comment to said blog, he apparently felt that it wasn't in the spirit of dialogue and did not publish it. Repeated fruitless efforts at eliciting a reason for this have helped germinate some very uncharitable thoughts in my mind, thoughts through which sycophants and yes-men flit. I may just be paranoid.

So, sensei or coach? Whomsoever is willing to pick and choose from systems thinking, agile, lean and/or (social) complexity. Whomsoever eschews dogma and mystery. Whomsoever strives to help you improve your effectiveness through mindful practice & considered reflection.

Beware the false prophet – identifiable by his penchant for citing personally vetted Ancient Wisdom from August Thinkers, while hard-selling a puritanically proprietary Utopia.