Jun 9th, 2021
Plan to Plan
Part 3: Plan to Change
Written by: Kirk Hoaglund, Executive Board Chair
With a large release of pent-up demand, our project load has increased significantly since the lows of mid-pandemic. Our need to carefully plan, as I mentioned in my prior posts Plan to Plan: Our Way Back and Plan to Plan: Your Plan Foundation has felt much like training for a marathon after time away from the sport. We are making progress. I’ll add to my prior post which outlined four pillars of planning with additional considerations that allow adaptation to change: Plan to Change.
While observing those four key, agile ceremonies of “Planning Session”, “Daily Standup”, “Review”, and “Retrospective” we add others in to help us recognize and adapt to change.
During Iteration: Review
As mentioned in my prior post, a review allows the team to demonstrate to the product owner and stakeholders completed work. Along with the team, product owner, and project manager, pertinent stakeholders should attend. We’ve modified this guideline to provide for short and more frequent review sessions. We often hold three to five such sessions during a two-week sprint. Not only does this allow our stakeholders to see progress and give feedback, it provides a key cadence framework. Almost like a project heartbeat.
Before and During Iteration: Backlog Grooming
Common to many agile methods is the concept of “backlog grooming” in which the scrum master and product owner review items on the backlog prior to the beginning of an iteration to ensure they are ready-to-go for the upcoming sprint. We work to maintain a groomed backlog that extends a few iterations into the future. Shortly before a new iteration begins, the highest priority backlog items are groomed, ready for the Planning Session. This catches changes earlier and allows reprioritization, as needed, to adapt.
We may insert a smaller grooming session mid-sprint to allow adaptation to high-priority changes. Traditional agile methods seek to divert these kinds of changes to a future iteration. We’ve found that some changes can be diverted while others do need attention, thereby altering this sprint’s committed item list.
Anytime: Design Spike
During the course of authoring useful user stories, while tasking during Iteration Planning, within a grooming session, or by reaction to unknowns or uncontrolled dependencies, it may be necessary to refine the team’s understanding of a feature. When it becomes clear that clarity is lacking, it is very important to acknowledge and deal with it. Most projects involve many, complex components, existing systems, and outside dependencies. These things will introduce surprises. Plan for that, it will happen.
Work performed by the team must be acknowledged, planned, and scheduled. Upon an acknowledgement that more information is needed, a design spike is written. This is similar to a user story, but has the purpose of digging into a feature to get clarity and to understand the ramifications of its implementation. Outcome of this activity include a set of changes to the initiating feature, a set of new features, elimination of features, or rescheduling features to accommodate the timing of dependencies. This is important work.
Acknowledging, up front and continuously, that our complex world, complex business problems, and many contributing systems will introduce change, is key. It will happen, so Plan to Change.