Making Plans
Emerging Agile Planning Pitfalls
Life is filled with best made plans. From recent January resolutions to our travel bucket list, everyone attempts to form short and long-time life milestones. Yet sometimes we need to reset the timeline. A recent goal for me, the undertaking of initial coaching training, has also triggered reflections on how effective and evolved our Agile practices are.
Regular planning and grooming are important activities in any effective Agile practice. It ensures we embody the manifesto principle of responding to change over blindly following a plan. Following my recent reset, I reflect on some of the pitfalls that have plagued our planning processes. Furthermore, in the spirit of continuous improvement, I outline potential changes currently being undertaken to kick these habits.
Makin’ Plans
A key consideration should be that an element of upfront planning is necessary. Winging it is just not an option. The project mindset of numerous large organisations in my experience leads to one of two bad patterns. Significant upfront planning that delays development and refuses to adapt to evolving client needs. Or no upfront planning at all, resulting in a product that is simply a set of disjointed features.
There is a danger that development teams initially misinterpret responding to change as not requiring any upfront planning at all. That is certainly my experience. Without an initial direction and clearly communicated business strategy, developers will struggle to appreciate how distinct features connect into a centralised product.
To ensure consistent client value is delivered, techniques such as User Story Mapping coined by Jeff Patton should be leveraged to give us our initial backlog items. The added benefit is such exercises are help us establish a baseline for a product roadmap. Furthermore, the strategy helps identify an initial MVP, that can respond to change using grooming, planning and estimation tasks.
I Want to Know Your Plans
Client engagement is one of the biggest challenges that we currently face. Rather than being an intentional act, it is simply a byproduct of their busy work lives. The common fix is to introduce a mediator role between users and technology to free up the time. Although this may be perceived to save time, this instance of The Telephone Game can unintentionally influence the product deliverables.
A commitment to direct collaboration from expert users is the sole mechanism to ensure we build the right product. A strong Product Owner will ensure all features take us step by step towards the product goal. User Story Mapping is merely the start of the journey. Our biggest mistake are Business Analysts performing the prioritisation and grooming individually. A close second would be not providing sufficient training on the roles and responsibilities of a successful Product Owner.
Rather than using our BA mediators, the Product Owner must contribute to planning sessions including regular backlog review. This should be performed in conjunction with the development team and analysts in a centralised medium with all updates committed against the story. That prevents a chaotic grooming ceremony I observed recently for another squad, where previously agreed acceptance criteria was discussed yet again.
Plans Within Plans
Over the years we have experimented with various formats for breaking down and estimating stories. One of the biggest mistakes I’ve seen several teams make is planning and estimating stories at the same time. To date, a lack of presence of the Product Owner on our planning sessions have meant planning work for the upcoming sprint have been a development team specific activity. This leads to a lack of transparency when items overrun, or even communication of items currently under development.
With our current focus on improving client engagement, attendance in planning sessions by the Product Owner on planning sessions has been agreed. This means that the breaking down and estimating portions need to be conducted separately. Having separate meetings avoids bamboozling our owner with technical detail. Coupled with improved backlog grooming, we can also ensure stories are ready to break down and estimate.
Stealing Time From the Faulty Plan
To paraphrase a well known saying, I’ll leave the worst to last. The biggest cardinal sin I’ve witnessed teams performing is estimating in time and not points. Engineers will still refer to a story taking X points, but really they have established a one-to-one mapping between these disparate constructs. Time does not work for several reasons. A simple search will reveal numerous opinions on estimate pitfalls. I of course have several arguments myself.
Firstly, optimistic programmers quite simply cannot give accurate estimates of how long something will take them to complete. Blockers and manual mistakes are never counted in these estimates. Other commitments such as hackathons, one day holidays and knowledge shares are rarely included either. Yet clients incorrectly assume that X days is an accurate estimate that they will question when deliver is delayed to X+1 and beyond.
Another relates to developer experience. Particular tasks that take one day for one engineer will take several for another depending on experience. That’s not to say that we should always assign to the more experienced programmer. Good technical leaders will ensure all developers are grown and supported to foster a skills balance within the team.
Use of points in conjunction with velocity are key to addressing these issues. Breaking the point-time relationship paradox is going to be an exceptionally difficult undertaking in my initial coaching attempt. Agreeing a day agnostic points system is the first step in this journey. Soon enough I’ll find out how bumpy the ride will be.
Thanks for reading my reflections. Claps and sharing of your own reflections are always greatly appreciated!
