Visualizing Agility With The Cone of Uncertainty, Part 2 Why Your CI/CD Pipeline Should Reach All The Way From Portfolio To Release

By James K Smith, linkedin.com/in/jamesksmith, [email protected]

In Part 2 of this article, James uses his favorite business graphic to show you how to move from creating a plan to continuously planning, integrating and delivering.

Part 1: Visualizing the Cone of Uncertainty Part 1

In Part 1 of this article, I used my favorite business graphic, The Cone of Uncertainty, to illustrate how human agility works to get to a minimum survivable solution. In this part, I'll continue referring to the Cone to help us visualize business agility from initial ideation to product increment release. The result is a process that continually increases signal and reduces noise, exposes more dysfunction, and minimizes over-committing every step of the way.

Years ago I was managing a huge project with multiple scrum/kanban teams. Cross dependencies could be substantial, and stakeholders were not accustomed to that level of required engagement. At the beginning of every three month program increment, we would have a big PI planning meeting. Often it would be reduced to producing a usual big plan up front, and didn't adhere to the spirit of what I believe PI planning sessions are supposed to serve, which is a look ahead encouraging organization of goals with some detail, identifying obvious dependencies, and emphasizing collaboration around the goals, all with an eye toward leanness and efficiency.

Outcomes from these meetings never seemed to be very edifying though. Seemed like if everybody wasn't an expert on PI planning, many still treated it like an effort to create a big plan up front (old waterfall habits die hard). The response to this might be to get everybody to understand what PI planning is really meant to do, but that's not practical given the number of players involved and their legacy roles. Plus, these kinds of meetings were very expensive, so I questioned if there wasn't a leaner way to get the signal we needed to ensure our chances of positive outcomes.

So then we added pre-PI planning at the end of the prior three month increment. That seemed to help a little more regarding creating more project signal and reducing noise, but it still had a “band-aid” feel to it. There were still way too many “research spike” stories indicating the presence of noise that were popping up in sprints, and I hate research spike stories. The results of these stories are not ideal, and technically they were just not business value stories, as they focused way too much on the “hows” as their reason for existence. In my view, sprint backlogs are best for three different kinds of stories: business value stories which can be pointed, kaizen (improvement) stories with no points, and regrettably, defect stories which can't be pointed either. Strive toward zero escape defects so you don't have to mess with these kinds of stories.

Up to this point, this nagging thought kept creeping around in my head that we weren't trending up in our performance because we just weren't doing things right according to the framework.

Well, in the end I realized that kind of thinking was unprofitable, dogmatic, and simply not lean . And it occurred to me that this direction we were going in with PI planning (planning, pre-planning, why not pre-pre-planning?) in an attempt to increase signal and reduce noise was revealing an answer that was staring us in the face.

“THERE IS NO PLAN, ONLY PLANNING”

Late in the contract, I wanted to encourage a different approach. The approach consisted of putting together an “Approach” team comprised of PO's and contributors from the scrum teams. This team would execute on a multi-status workflow that would continuously produce ready stories for the scrum and kanban teams, and this effort existed entirely outside of sprinting or kanban intervals. The advantage to this approach is that it provided a very productive mix of continual inspecting and adapting, revealing dysfunction since the approach itself could be measured and repeated, and protection against over-committing. All these attributes are characteristic of the human agility we're already wired for (as I described in part 1 of this article).

Essentially, the starting point of the CI/CD pipeline is moved from the sprint all the way up to portfolio level. What is being delivered along the workflow is more signal and less noise from state to state, ultimately producing units of work that can more easily be committed to by our scrum/kanban teams. The outcome from the teams is enough signal that contributes to a minimum viable solution in the form of a product increment. Participation on this “Approach” team would be accounted for in the capacity planning portion of Sprint Planning.

I discussed this “Approach” workflow with some of the other leadership, but it was just too late in the project to pivot with any results. But then I had another opportunity years later at a large corporation to see this Approach process implemented to great effect. Thanks to a mentor coach who was already at this engagement and implementing Approach, it was so effective that PI planning meetings were not needed. When my mentor coach made the statement “There is no plan, only planning,” that's when it all clicked, and my thoughts on this expansion of the narrow definition of CI/CD were validated.

In part 3 of this article, I'll describe the “Approach” process in detail and overlay it onto the Cone of Uncertainty to show how it increases signal substantially and decreases noise so that your outcomes are higher quality and arrived at more quickly.

Until next time,

James

James Smith has a 25 year career building high-performing technology teams and organizations for a multitude of industries. He enjoys working with startups to some of the largest corporations in the world, has held several highland games world records, and has pitched to VC using nothing more than napkin drawings and a bowl of M and M's. He claims there's only one truely always-optimizable XOR result in the universe, that either 2+2=4 or it doesn't, but not both. Otherwise, some of the best answers can be found in the grey areas.

#kanban #agile #scrum #safe #less #velocity #flowefficiency #cycletime #agiletransformation #agilecoaching #lean #pmofficers