A colleague shared a thought provoking article by Todd Lankford about Program Increment (PI) Planning and why he, Lankford, cringes whenever he hears the phrase. While I agree at a high level with Lankford’s arguments regarding the need for teams to engage in continuous planning and the importance of breaking dependencies, as well as sharing the cringe factor felt when people clam to be Agile, I break with his thinking in the detail when it comes to PI Planning. The reason is that the article creates too many strawmen, an example of which is served up at the outset with an invented quote from a ‘Manager in Agile Transformation’:
“We are Agile! We have a backlog, and we host awesome PI Planning events.”
Lankford is correct in principle, that having a backlog, running PI Planning events, or name checking some Agile ceremonies does not an Agile organisation make. However, an argument is always in trouble when it relies on strawmen or worse, makes category errors to sustain its critique.
The original example of a category error, or category-mistake, was given by Gilbert Ryle in his book The Concept of Mind (1949), in which a visitor to Oxford University is said to have asked, upon viewing the colleges and library: “But where is the university?” The error by the visitor was to assume that a university is part of the category ‘units of physical infrastructure’ rather than ‘institutions’.
Category errors abound in Lankford’s article, as the heart of his argument against PI Planning seems to centre on creating an Agile mindset, helping teams to embrace change, and avoiding the arduous work needed to create an Agile organisation. As Lankford observes:
Program Increment (PI) Planning from the Scaled Agile Framework (SAFe) does not support an Agile mindset. All my experience with it tells me this is true. I have never seen PI Planning help a team embrace change.
Yet, SAFe is the default for those seeking Agile without having to endure a difficult change to their status quo. And SAFe sells itself as an Agile panacea.
As an historian I always advise; beware of generalisation. As a philosopher; beware sophistry (misrepresentation). The former, generalisation, is evident in the assertion that PI Planning is a framework used by organisations who want the baby without the labour pains. The latter, misrepresentation, occurs in pushing the notion that PI Planning is about creating a culture that embraces change. Thus, to quote Lankford’s words back at him: ‘Right there, the illusion begins.’
I would argue a better summation of PI Planning is in SAFe’s unwritten rule: ‘the people who do the work plan the work.’ This is because it goes to the heart of why PI Planning is beneficial: it creates ownership and accountability among the people who do the work. Something that is all too often lacking in organisational cultures where all care and no responsibility is the order of the day with teams that, if the project fails, take an ‘it is what it is’ attitude and assume there will always be a tomorrow to work on the fix. While the poor program manager, special pleading on my part, is left to face a ‘please explain’ like a person sent out into a typhoon with nothing but an umbrella.
Lankford’s objections to PI Planning in an Agile environment continues with:
[the] implication is you are Agile if you do PI planning… [which is] front and center with the Manifesto reference.
Yes, the SAFe website does quote the manifesto, but the context of a quote is often as important as the words of the quote. And the context of the quote? To outline what the Agile manifesto states is the most effective method of conveying information: face-to-face conversation. SAFe in this instance is not making any assertion about the Agile process beyond what it states is the best way to run information session.
Unpopular though this concept is in an age where employees increasingly demand 100% WFH, and much though people will troll out Elon Musk’s comments that employees must ‘return to office or ‘pretend to work’ elsewhere’ as representing the worst excesses of uncaring capitalism, humans have evolved as predominantly social creatures who need physical interaction – not avatars or video surrogates. Thus, face-to-face learning and planning is not so much something that is done because of technological limitations or uncaring leaders, but something that should be done because of deeply ingrained emotional-physiological needs. Far from making PI Planning antithetical to an Agile organisation, its emphasis on face-to-face planning should be a central theme for all organisations seeking to undertake transformational work.
Lankford’s case against PI Planning continues by presenting what appears his most damning indictment: ‘the PI Planning page fails to mention any of the four Agile values’. While he is factually correct, that the following are not directly name checked on the PI Planning page, he is incorrect that PI Planning does not account for them:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
The Agile Manifesto
Given the stress placed in PI Planning on personal interaction via face-to-face workshops, there is a clear emphasis on accounting for individuals and interactions. When placed in the broader context of PI Planning seeking to engender ownership and accountability by ensuring that ‘the people who do the work plan the work’, a program approach is manifest which focusses on software as the team need to deliver outcomes not merely output. By widening the group responsible for planning, customer collaboration is also accounted foras the emphasis is moved from a select sub-group to a larger group of stakeholders involved in the planning process. Finally, planning something from the outset is not axiomatically incompatible with remaining agile – viz-a-viz a project team’s ability to respond to change. This is writ large when we step away from the world of program delivery and look at one of the biggest ‘big room’ planning environments — the crucible of war.
Wander into a battle and try and plan in the moment, and not only will strategy be lacking, but the coordination of troops and logistics needed to ensure the right units are in the right place at the right time is more likely a result of luck rather than good planning. True, ‘command control‘ is not only highly effective at enabling leaders on the spot to make tactical decisions in the moment as the conditions change, but this does not obviate the need for an overarching strategy. Rather, it reinforces the importance of shared long-term goals.
Returning to program delivery and the same lessons hold true. PI Planning does, as Lankford correctly observes, create a big plan, and contract up front. But far from this preventing the plan from evolving or representing frailty and rigidity in the process, it is an essential element for what Lankford deems ‘a better path’ — continuous planning. This is because without the big plan there is no strategic goal toward which the exercise of command and control from sprint to sprint can lead. Without the and up front contract, there is no measure of accountability. In this context, PI Planning creates a framework which can be used to sense check the emerging evidence as the build gets underway and validate or invalidate the judgements made by the delivery team. This is where Scrums lightweight framework for continuous planning can, if employed effectively, dovetail with the longer term framework of PI Planning.
It is also inaccurate to assert that ‘PI Planning disrupts the flow of value’. This notion, again the result of a misapplication of PI Planning, only emerges as true if we accept the assertion that PI Planning only permits innovation once in the cycle, and that:
The mere presence of an IP iteration denotes the absence of innovation, planning, and sustainable pace in normal iterations. This is analogous to how a hardening iteration denotes a void of testing and getting to “done” during prior iterations.
Yet, as already outlined, PI Planning does not need to prohibit continuous planning, and the very nature of a Program Increment is it splits the larger strategic plan into smaller goals that, as per PI Plannings unwritten rule ‘the people who do the work plan the work’, can be managed using command and control by the squad who are responsible for the increment.
Where Lankford is on a more solid foundation is in observing that ‘PI Planning does nothing to break dependencies’. And I positively celebrate the assertion that:
No amount of perfect PI Planning execution makes up for ineffective team structures. When the team is a siloed area of expertise, mastery focuses on pieces and parts, not features. Teams composed of homogeneous skillsets can’t deliver end-user value by themselves.
However, I would take it one step further and argue that no amount of perfect planning, no matter the framework, will redress an ineffective team. The same is true of a program that is held hostage to dependencies, regardless of whether they are technical or the result of a business process. Thus, unless the existing organisational model is revised to accommodate a new ‘to be’ process that supports the program development, solutions are launched onto barren soil, and will not take root. In defence of PI Planning, the framework was never designed to break dependencies, only to identify them and foster ‘cross-team and cross-ART collaboration’.
This returns us to a recurring theme and in consequence a repeating criticism of Lankford’s article – its tendency to create strawmen from PI Planning and then offer ‘better paths’ to the implementation of Agile. For one thing, the approach is confusing, if my colleagues who referred the article are anything to go by, as there seem to be ‘better paths’ offered at regular intervals leading to uncertainty as to whether there is one better path to rule them all or if there are many ‘better paths’. Begging the question – which do I take?
CONCLUSION – A BETTER PATH!
I too cringe, but not when I hear Program Increment or PI Planning, but when I hear Agile. This is because people frequently struggle to think strategically and struggle even more to think in long-term scenarios. As a result, Agile is often improperly embraced by people who cannot plan beyond the next sprint or next quarter and who find it comforting to claim that longer term planning is ‘not Agile, but Waterfall’. This scenario is invariably trotted when a manager has got it horribly wrong and is seeking to pry the team away from the agreed plan and ‘pivot’ to a changing market. The truth is that there is a yawning chasm between creating an Agile mindset, helping teams to embrace change, and undertaking the arduous work needed to create an Agile organisation, and chaotic management that makes it up as they go and in consequence avoids long-term strategic planning as well as accountability for the outcome of the solution.
In this context, it is wrong to see PI Planning as synonymous with the Waterfall model. Namely, get a bunch of people into a room at the start, get them to plan the project, then get them to deliver the project. If one views PI Planning as only that, then Lankford is right: it is not Agile and there is a better way. But that is precisely where his overall argument collapses as it is a strawman of PI Planning = waterfall and waterfall ≠ agile.
Thus, the key takeaways from this response to Lankford are that a person is mistaken to think:
- PI Planning cannot be iterative
- PI Planning cannot be continuous
- PI Planning cannot contribute to the flow of value
- PI Planning cannot form part of a broader process to break dependencies
- PI Planning is merely, to paraphrase George Bernard Shaw, the illusion that collaboration has taken place
If you have a project team of hundreds of people and try and leverage the face-to-face ideal of PI Planning sessions to get everyone in the same physical room, particularly in this age of WFH, then PI can be untenable. But this is where the hierarchy of an organisation comes into play and Program Increments reveal their power. Once the broader strategic plan has been communicated, and program increments established, a squad of 8 or 12 people, who are already engaging daily in Agile ceremonies, can readily and regularly satisfy the unwritten rule of PI Planning, that: ‘the people who do the work plan the work’.
In this context, PI Planning is a ‘perilous path’, but only in organisations that are struggling to embrace change or whose leaders distort the intent of Agile and twist the notion of continuous planning so that they never need to think beyond the next sprint or quarter. But when PI Planning is deployed by leaders who have the nuance, skill, and strategic capability to deliver an Agile project with a multi-year roadmap, PI Planning is an invaluable framework for program delivery.
In other words, PI Planning works well when not blindly followed or incompetently lead.
Good night, and good luck.
Photo by David Travis on Unsplash.
