2.2. Hello Agile: The Pursuit of Information
In the previous post we learned about the Cone of Uncertainty. Journeying through this Cone requires as much supporting information you can get your hands on and process. A user experience designer may choose to discard a design if the feedback from user testing is negative. An investigation by the engineering team may discover serious flaws in the planned approach. A delivery manager may uncover dependencies which cannot be resolved, causing some routes to be unnavigable.
Teams may choose a number of ways to find the supporting information they need, but whichever method the team chooses, there is always a time and cost trade-off to consider.
Scoping through Phases
Irrespective of the size of the work, a common approach is to split the tasks into phases. The Product Manager works with the business to analyse the data they have and figures out the next piece of work to undertake. Within this phase, the Product Manager may run additional scoping with other departments such as Legal, Marketing and Sales. Depending on the product in question, user experience designers will take the product requirements and complete a scoping phase too. The output of all these phases is eventually fed to the technical team who assess the feasibility of the business requirements, the design and their ability to implement that within the technical and time constraints they work under. If the team can figure out a way to implement the designed solution in a way which is satisfactory for all stakeholders, the work can proceed to the build phase.
This approach is considered to be low cost, as each discipline is only pulled in when it is completely necessary. If the initial idea is not backed up by the data, then UX designers are not troubled for a design. If legal or budgetary hurdles cannot be overcome, then engineers need not spend any effort on completing a technical scoping phase.
The trade-off here is that for this low cost, we have a lengthy process: enough certainty to proceed to building the solution is only available when all disciplines have completed their analyses in turn. Rather than taking days or weeks, this can take many months. If this sounds like an exaggeration consider the last few projects your team undertook: when was the idea for those projects first discussed? What had to happen for them to make it onto the quarterly roadmap? What further events and actions took place to take that roadmap item and have it turned into prioritised pieces of work which could be completed and released to the customer?
In addition to long lead times from inception to execution to release of an idea, there are further pitfalls with this approach which are not often acknowledged. This can only be considered low cost if the scoping phases do not require rework or additional information from previous phases. The UX designer may find that the underlying information from the Product Manager is not rich enough to design a meaningful experience. Just as likely (if not more likely), the engineering team may find that the design and requirements simply cannot be implemented within the timescales. And legal concerns may be so tightly coupled to the actual technical approach (e.g. service level agreements, types of encryption used, access to privacy notices) that this may need revisiting after the technical scoping has been done.
Consider also that transitions from one phase to the next may require sign-off first. A Product Manager may have to present the idea to senior stakeholders for approval. A UX designer may have to present the proposed experience to the wider UX team to ensure consistency across the product suite. Engineers may have to write RFC documents to support their planned technical changes. Each activity in this chain only adds to the time it takes to get towards certainty. As well as slowing the process down, this also highlights the handoffs in effect with this approach. The initial idea passes through the Product team, to design and then to the engineering team. With each handoff, the team runs the risk that the purpose and vision for this feature is distorted or lost. Even with stringent management and comprehensive documentation to convey the needs of the customer, the developed product may not fully match the intentions of the business.
And by the time the solution is built and delivered to customers, perhaps the window of opportunity has passed and customers have already found what they need through a competitor.
With the cost of re-running scoping phases, the cost of correcting (or living with) a product that does not adequately fulfil what the customer needs and worse, missing the business opportunity entirely, it’s easy to see that this approach may not be as low-cost as initially believed.
Scoping through Swarming
An alternative to the phased approach to scoping does exist. Rather than passing the feature from one discipline to the next, everyone ‘swarms’ together to complete their scoping efforts at the same time. The Product Manager brings data analysis skills to the table as the same time as design and engineering bring their respective expertise. Together, they brainstorm the implementation details and experiences they need to build and through a process of elimination, identify the winning solutions earlier. Any blockers and edge cases which may have otherwise been identified at the very end are raised early, reducing (or eliminating entirely) the need for re-work.
Typically, this is considered a high-cost solution as everyone must be available at the same time. This is costly both in the planning of the swarming session as other activities must stop, but also in the risk that such a session itself might be delayed until free time can be found in everyone’s calendar. Thus, while the session itself is being planned, the team and business are not moving through the Cone at all. (This actually touches upon another problem: in the name of efficiency we fill our working weeks so we’re 100% busy. The downside of course is when we need to respond to a new need from the customer or wider team, we’re often too busy.)
For the high cost of the swarming session, the team and business find themselves arriving at a place of certainty at a much faster rate, where the solution can be built and launched sooner, provide value to customers earlier and capitalise on the business opportunity when it’s most fruitful. Even if as a result of the swarming the team decides that to not proceed with the build (perhaps because the effort does not justify the value), the team has gained the information it needs to make this decision early, rather than at the end of a series of scoping phases.
It’s worth pointing out that Research & Development departments in organisations are responsible for what are essentially early-stage flights into the Cone of Uncertainty. They are tasked with discovering how to turn new insights and technologies into valuable products. When you consider that more than $100bn was spent on R&D across just 10 companies in 2017 (including Amazon, Apple, Alphabet and Samsung), it’s clear that the biggest and most successful companies opt for the high-cost fast approach for information discovery.
Design Sprints
As more organisations look towards swarming during the scoping phase of product development, one swarming method gaining popularity is to do so by running a week-long ‘Design Sprint’. Popularised by Jake Knapp from Google Ventures, this is a carefully choreographed approach. The goal for those taking part is to explore opportunities, and then pursue the most promising one until a prototype is built and tested. Teams start from a place of near-complete uncertainty, and end the Sprint having developed a working prototype and gained real user feedback.
This is a demanding week. Not only for the people involved in the Sprint but for the business itself. Development teams and stakeholders alike mark themselves as unavailable for the whole Sprint and shut themselves off from their normal day-to-day responsibilities.
There is an additional cost to be aware of too: the product developed here is only a prototype and not for production. It would only be through a stroke of luck that any of the design or technical work could be retained for use in the live product.
The pay-off is that potentially months long investigation efforts are condensed and completed in a week.
In the next post, we complete this chapter by tackling one of the most misunderstood, divisive and abused concepts in the Agile world: the Minimum Viable Product.
About Agile Bites
Agile Bites is a series of posts written by Mohammed Rizwan which, when put together, intend to serve as a course for individuals and teams. Starting from Agile basics, we’ll move to more challenging topics such as Kanban’s work-in-progress limits and Scrum anti-patterns, whilst attempting to figure out exactly what an MVP is.
Follow Agile Bites to ensure you don’t miss a single post: https://medium.com/agile-bites
