Looking Ahead in Agile
agile methodology
internal processes
refinement
planning
One of the major downsides of continuous development in Agile is the difficult inclusion of roadmap planning to keep an even squad velocity when moving from one sub-initiative to the next. I was tasked with creating the Look Ahead capability for a pod of 7 product squads that would refining work and feed multiple backlogs seamlessly.
Who are the users? What are their goals?
The product group to build our account opening and maintenance function on the platform was comprised of 7 product teams that integrated separate code bases into the same experience using in an Agile-at-Scale delivery model. Having so many teams created a lot of toe-stepping and confusion and so the product underwent a process shift to swarm teams together. The goal was to have multiple product teams within a swarm working on just 3 problems collaboratively instead of having 7 different problems separately.
One of the effects of this change was that teams no longer had isolated backlogs to refine upcoming scopes according to their own priorities. Instead, there was a single product-level priority and backlog across all of the teams and swarms.
The Problem Statements
In the new organization structure, there are 3 product leads collaborating in the same space. Whose job was it to refine the product-level backlog?
If swarms are focused on continuous delivery, when would they make time to refine backlog items?
How would a swarm or product team refine sub-initiatives for large, complex features that may impact multiple swarms?
How might we ensure that discovery and analysis are not overlooked in the new swarm structure?
The Solution Approach
Incorporate continuous discovery into the continuous delivery process by creating a formal Lookahead Function.
Target Goals & Metrics:
Define a process for refining large initiatives into backlog stories that can be assigned to swarms and squads.
Minimize how much downtime squads experience when shifting from completed work to new work.
The marching orders
I was asked to lead the creation of a “Look Ahead” pod that would produce a steady stream of refined scopes for the product’s backlog. The idea was that the swarms would be able to release a sub-initiative and then turn their attention to the next priority and immediately begin delivering on it.
Online research didn’t yield a great deal of clarity on how to integrate a Look Ahead faculty into an Agile practice. Luckily there were a few practitioners in-house who had started “strategy squads” and “lookahead centers of excellence”. I interviewed them to get some guidance, and set about making my first attempt.
The first approach
My first action was to create a wiki page on the intranet of all of the questions I needed to answer to make this process viable. The biggest hurdle to success was how I would refine large scopes when it was just myself as the sole dedicated Look Ahead member. After all, defining a problem and then designing a solution in isolation wasn’t going to yield realistic requirements. I would need the help of business analysts to help identify what alternatives users had today, systems analysts to uncover technology limitations and available services, and product owners who had the power to commit to scopes for external team dependencies. I proposed a voluntary participation model: associates who had capacity to take on a Look Ahead story were invited to take split their time between their dedicated team and the Look Ahead pod to lend a hand and own a story. This could work since analysts tend to have a varied workload in Agile from sprint to sprint depending on the type of work the team is doing.
I didn’t want to become a bottleneck to people taking part, so I created a JIRA backlog of all of the sub-initiatives that we needed to refine and an easy process catering to those associates who could only spend a sprint with the Look Ahead pod. Each question that I had for the sub-initiative, whether large or small, was a separate story spike that someone could take, explore on their own, and then return back with an answer.
As the process became more clear, I continued to adapt Agile methodologies to fit my needs. I reviewed Definitions of Ready and Done with internal and dependency product owners to ensure that what I produced would be useful and published a “Working Agreement” for those joining the Look Ahead pod temporarily. Once a week, I gave a stand-up style status at the MetaScrum to my key stakeholders.
The Outcome
The process definitely had some strong results, both positive and negative.
Some Positive Results
Product team members of different roles were encouraged to stretch a bit outside of their discipline to help find answers to necessary questions, which led to better knowledge-sharing across the product.
Tracking open questions as stories in JIRA and staying aligned to a 2-week sprint schedule required the contributors to think clearly about what they were trying to ask about and how it would contribute to a better experience. There was less analysis and design waste.
Working ahead of the delivery sprints enabled us to incorporate user research stories into our refinement and showed how valuable upfront user inquiry is to solution definition
Having a visual backlog of the work that needed refinement forced the product leadership to have tough conversations about what scopes really deserved to be highly prioritized. There could no longer be multiple #1 scopes.
Some Less Than Positive Results
It was very apparent early on that one dedicated resource would not be enough to make significant traction on some of the big, complex scopes.
Having product team members ducking in and out as they had availability left stories suddenly unattended and in the air.
Without the ability to plan on a steady capacity, we could only tackle one item at a time, which would never get out ahead of the teams who were expecting work.
The goal of handing off solutions so that teams could stay in continuous delivery removed the creativity and agency from the teams. Whether they were developers, analysts, designers, or product owners, the teams receiving the refined solution work felt that they had no ownership of their work anymore.
Ultimately, the product leadership realized that having only one person dedicated to this work wasn’t enough and the Look Ahead function was integrated into the team operations instead. Going forward, I worked directly with teams to refine sub-initiatives.
Additional Notes
The dissolution of the Look Ahead function was by no means a failure. Eight months later, the product is taking another try at standing up a formal Look Ahead team with dedicated members from different disciplines. We’ve incorporated the positive results from my experiment and pivoted where I identified issues. Continuous experimenting leads to success!