As consultants, we have the privilege of helping our clients along their agile journeys. It is always interesting, as each client is on their unique path with various levels of success and challenge in their agile adoption. Most of them are also using traditional project delivery for some of their projects…. And, I have to admit, I love this!
As a “where the rubber meets the road” kind of consultant, I appreciate the difference between theoretical and applied agile concepts. I love the challenge of facilitating applied solutions for our clients.
I do not mean to minimize the importance of our coaching and training towards agile best practices – this is really important. But at the end of the day, our clients appreciate applied agile that meets them where they are at and elevates them on their journey.
Having said that, there are three things I feel strongly about doing from the start of agile projects to maximize business value for our clients, regardless of their degree of agile adoption. My blog summarizes these points.
For the project with a “blank sheet of paper…”
Facilitate a product release plan and story map.
Haphazard approaches to project runways and getting the team on the same page are inefficient and costly. Visualization of product and story maps provides the strategic plan for the stakeholders and agile team.
The release map should answer: What is the theme/feature set and when is the release date? Remember, this will be more detailed for the current release, and will become more detailed for subsequent releases through progressive elaboration.
Key factors to drive the strategic formation of the product map are driving maximum business value and mitigating risks, that is, choosing what to learn about early. Short releases that maximize what is not done (the 80/20 rule of features) and obtaining user feedback soon is invaluable – the more quickly product gets into the hands of end users, the more value our clients realize! In a perfect world, product vision, program and portfolio plans are key inputs that the product map supports.
The story map depicts all the high level activities end users perform using the software. End users are on the first row and their high level activities are on the second row. You can tell a chronological story going from left to right.
For example, the administrator sets the companies and users, then the insurer submits their filing, and then the analyst performs their analysis. These activities get decomposed into smaller activities and prioritized into releases.
I love story maps because they are the perfect way to seed a product backlog and bring ongoing value throughout the project. This value is realized by:
- Catalyzing conversations
- Focusing on end users
- Depicting the big picture
- Being easy to communicate, share, and check if anything is missing
- Identifying and showing dependencies
- Prioritizing work
- Showing what the team is working toward for each release AND what the user outcome will be
Slicing it in a variety of ways to meet different outcomes like identifying minimal viable product (MVP); product releases; or by learning objective
For the client that is not ready to start with their most valuable business functionality….
Encourage them to do it anyway!
We can help our clients maximize business value by facilitating the estimation of relative value of features/capabilities that are then used to prioritize the release plan and product backlog.
There are some helpful Agile games like Buy a Feature that can help in the determination of business values. A story map and product backlog not driven by maximizing business value will produces sub-optimized results and who wants that?
Leveraging business value with quick releases and spikes that help obtain user feedback and learn in a time-boxed way help us and our clients figure out what is needed. This is really hard for the client that wants to provide most of the direction up front, but we know from traditional project management that this just does not work.
Having a systematic way to deal with unknowns and risks through spikes and a risk-adjusted backlog helps our clients as they develop an agile mindset. They become more comfortable with ambiguity, learning/failing fast, and managing risks early on – all good things!
When there is reluctance…
Encourage transparency to all stakeholders from the start.
Sprint demos to key stakeholders and visible information radiators are key feedback mechanisms, metrics, and cultural drivers on projects. If the client believes that, “We don’t have enough developed yet to demo to our business sponsor and key stakeholders” then chances are the release plan is not maximizing value or the team is not as far along as desired.
Regardless, this should be known to all. Not doing so is the opposite of a healthy agile culture. The team should welcome feedback throughout the process as inputs to the product backlog and release plan. Business value cannot be maximized if the key stakeholders are not routinely part of the feedback process.
Also, visible information radiators should be readily viewable and updated after each iteration. This is especially important for clients that are new to agile, because they will be tempted to use traditional project metrics.
A couple of my favorites are the release burnup chart and trend of open defects by priority.
I like the release burnup chart because in addition to showing the work completed/remaining, it tracks changes in release scope. It helps demonstrate the required trade-off of scope if resources and budget are fixed. And it also informs release planning as the team velocity become steady.
I like the open defect trend chart because it is a good visual reminder of the accumulation of technical debt that is being incurred.
Wrap Up
These three steps will help us and our clients maximize business value and establish some good agile practices early on.
Have fun on your next journey!
| Reference: | Three Considerations For Your Agile Project from our JCG partner Sherry Stevens at the Keyhole Software blog. |
