I (Nick Coster) was interviewed on the Global Product Management Talk about a topic that I have been thinking about and working on for quite some time. The interview was with Cindy F Solomon and together we discussed The Agile Business Gap.
The Agile Business Gap exists where there is no well understood and repeatable way of converting high level ideas or business objectives into the level of granularity and detail that is required of a user story to effectively populate a product backlog to work effectively with an Agile Development team.
The Agile Business Gap describes the methodology gap that exists between the origins of an idea or a market insight and the creation of an initial (and ongoing) product backlog of user stories.
At its core the Agile approaches that we see are software development focused and in most cases anything that is beyond the boundaries of the Product Backlog and a release is largely ignored by any of the Agile methodologies.
Where do you see this Agile Business Gap being a problem?
The Agile Business Gap gets wider with the size of an organisation.
While the business is small the strategic intent of the company is easy to share and the number and types of customers is fairly small.
In these smaller businesses the whole team can operate in short fixed bursts of activity to feed in to regular product releases and improvements. The cadence of the product management process and the product delivery process can be easier to align.
As businesses grow however there are more existing customers to keep satisfied, more organisational stakeholders to get buy in from and more complex products and product portfolios that need to be considered with every new change. This is why traditional waterfall processes work so well within a larger organisation. All of these needs can be considered, agreed upon and neatly handed to the next stage of the development process. Unfortunately this usually results in a LOT of upfront time taken creating documents that are little more than detailed assumptions that are yet to be validated, and the very situation that the Agile manifesto and associated methodologies were created as a reaction against.
So the problem of the Agile Business Gap is to describe a way of capturing the strategic and market intent of an idea, collaborate with larger specialist developer and non-developer teams, and then generating just enough well written User stories that combined will result in a marketable product for release or launch.
Is there a way of closing the Gap in larger businesses?
The short answer is yes. But like any implementation of Agile, it does require a different mindset to fully embrace it. The reason that it is so important to this audience of Product Managers is that they are the center of the change.
- Problem Thinking must come before Solution Thinking.
- The Product Manager must deliver less more frequently.
- The Product Manager must be constantly prioritizing their activities and outputs to maximize business and market value.
So what do product managers actually have to do to bridge the Gap?
The main key is to use the same waterfall style activities of Market Research, Business Case approval, Target Market and Persona definition and market requirements / User Story writing, except that in an Agile framework each of these steps is only done a bit at a time, synchronized with the sprint or iteration lengths.
The outputs of these activities are always prioritized to deliver the most business and market value as soon as possible. Done well this will deliver the most valuable product functionality to the marketplace faster.
The key benefit of the faster market release is NOT speed to market, but is instead the faster learning that the business gains by testing every assumption earlier than the competition.
How does a business start closing the Agile Business Gap?
- Firstly get everyone working in fixed time boxes. These should be from 2-4 weeks long.
- From the business case or other market analysis identify the MOST VALUABLE user segment. The “most valuable” may the largest in size, or have a pain point need of frustration that they are desperate to address. Usually it is a combination of these.
- Create a persona for this Target Market and quickly story board the assumed user journey. Where are the points in The user journey that the persona has the greatest pain point Explore this in more detail.
- What are the most important outcomes that the persona is trying to achieve in this small segment of the User Journey?
- Formally write these up in the user story format of”As a <Persona Description>, i want to <achieve some clear outcome> so that I can <get closer to my Persona Goals>”
- Priorities these along with any other Low detail parts of the story boarded user journey into the Product Backlog.
What barriers do you see to being able to do this effectively?
Number 1 – The Product Owner.
The definition and resourcing of the Agile Product Owner role. This title is one of the biggest barriers to the effective implementation of an Agile product delivery function primarily because it is never resourced.
It is usually assumed that the Product Manager will step in an manage it, but this is like asking the Coach of a soccer game to also play goal keeper, just because the team is a man down. Since the Product Owners primary function is to manage the product backlog, it is a failure of any business that is “going Agile” not to resource this role effectively.
Number 2 – Solution Sign-offs / Approvals.
Larger businesses are conditioned to approving a final solution design of a product before committing resources to the build. Since an Agile development team is exploring possible solutions during the development process, there is no solution design available for approval. The sign-offs and approvals need to shift to collaboration and prioritization of the Product Backlog. Effective user stories have their own built in sign off process, where the acceptance criteria define a valid solution outcome. Again this is where the Product Owner role is vital for managing the stakeholder approvals for the User Stories on the Backlog.
Number 3 – Being satisfied with “good enough”.
The larger the business the more likely it is that the teams will begin to get territorial. This makes it more difficult to pass “unfinished” work from one team to the next. Instead each team feel the need to get it right before sharing it with other. The Agile methodologies generally operate in fixed time-boxes where each outcome that is being sought must be “ready enough” to be tested with a customer. It takes a lot of practice and a supportive team environment to able to share the first draft of every activity that the team is working on without fear of ridicule.
Please share any opinions or feedback that you have from the chat or the ideas above in the comments below.