The Path to a Better Way
In the last 2 posts we considered how some prominent Agile concepts and ideas may not be delivering their full potential. First, we looked at how work items tend to be treated as to-do lists, often arranged in a hierarchy. Then we examined the literary story/epic metaphor and the role it plays. In both cases, there were benefits at a small scale but they were lost as projects scale up in size.
In this post, we will explore an alternative approach, tackling the structure and the metaphor together. At the start, I suggested reconsidering long held assumptions. Now I am asking you to rotate your thinking 90 degrees, from a vertical hierarchy with a literary metaphor, to a horizontal flow and a journey metaphor.
Consider how you plan a journey on a GPS. First, you enter your final destination. If it is a long journey, you may have other interim destinations you need to pass through so you add them in too. Once that information is provided the system will suggest all the individual steps you need to take to get to each waypoint and ultimately to your destination.
It’s the same way products evolve. They start with a lofty goal; an objective or desired outcome. For any decent sized project these goals will be too big to achieve all at once. There will be checkpoints along the way to confirm it is on track to deliver the intended value and if it’s not, then adjust as necessary. Once the checkpoints have been identified, the individual work items to achieve each of them can be fleshed out.
Hence, the foundation of the journey metaphor for Agile development are: Destination, Waypoint and Step.
Destination
A significant goal, achievement, outcome or objective.
What constitutes as significant may vary from project to project. This is acceptable since it does not have to be “final” in the sense that there will not be anything after it. In the same way, reaching the destination you put in your GPS doesn’t mean you won’t later proceed to another place.
A Destination would represent a state where a value proposition can be realised. They would be set by the product manager.
Waypoint
An interim milestone or checkpoint.
A Waypoint is a logical point to evaluate how the work is progressing and if any changes need to be made based on what has been completed and what has been learned.
Waypoints should be agreed between the team and the product manager. The team will have insights for any risks that need to be explored and mitigated, and a Waypoint is the time to review the risk. So it makes sense that the team should have input to that. A Waypoint is also a checkpoint to ensure assumptions about the value proposition still hold and the product manager must be included as well.
Step
A small, incremental development or other activity that progresses towards a Waypoint and ultimately, a destination.
The team should decide what the necessary steps are to reach a Waypoint.
It may be tempting at this juncture to look at these and think that a Step corresponds to a story, a Waypoint corresponds to an epic and a Destination corresponds to a feature. But there is more to it than that. We now look at how to apply these structurally and metaphorically.
Step, Waypoint and Destination are not hierarchical; instead, they represent a progressive flow. The relationship between items is not parent/child. In some cases, it could represent a hard dependency. It can also just be a preferred sequencing. This means they can be fluid and change according to the circumstances.
Also, note that a Destination may have links to what will come after it - and that could be the next step. Metaphorically, when you make it to one Destination, you know the journey will continue, even if you don’t know where to at the time you set out.
Not only are these items not hierarchical, they are also not mutually exclusive. Completing the last leg on a journey can be seen as arriving at the final checkpoint; that checkpoint can also be the final destination. It follows that a step can also be a waypoint and a destination.
With the foundational concepts in place, there are many other journey related terms that can be applied that work with the metaphor.
Path: A linear progression from one item to another
Detour: An alternate path to follow when the intended path is blocked
Dead end: A path that does not end at a desired location
Pothole: Some repair work is needed here
Scout ahead/Exploration: The path forward is not clear, send a party ahead to find a way
Shortcut: An alternative path that is shorter or quicker than the original
The visualisation of this metaphor naturally lends itself to be a directed graph and opens up a variety of new user experiences and ways to explore an agile plan. The example below shows some of the immediate benefits and possibilities:
Immediately you can see and understand the relationship between things (It is the same dataset that was shown as a hierarchy in the first post.)
It looks like an actual roadmap
The sequencing of work is clear
The size of an item can be visualised for a quick relative comparison
Colour can be used to show status and progression
Work that does not align to goals is obvious
Simple interactions quickly enable these actions directly:
Adding and removing items
Reordering items
Expanding to see what is next
Collapsing to hide what is not relevant
A key element is the concept of a path defined earlier as a linear progression from one item to another. The image above is really a collection of paths that together present a plan. Paths can be useful in several ways:
Stakeholders may want to view the progress towards a destination
A product owner may want to view the progress towards a waypoint
A team may want to view the steps required to make their next milestone
All of the above can be derived from the same plan. They are all paths at different levels.
It is interesting to consider the path of a team towards a Waypoint. The path from one Waypoint to the next could be considered as the next “unit of work” for a team. So then, instead of having a time-based sprint, they could have an objective-based sprint which is naturally defined by the path between two consecutive Waypoints. Also, notice how a “sprint” works nicely within a journey metaphor.
If a sprint can be defined by the paths to be completed, is a traditional sprint board required? The path shows all the steps that need to be completed as well as their current progress. It is clear when something has not started yet. Even more than that, it is possible that the current sprint could be a filtered version of a larger plan.
That all seems pretty cool, but is it better? Does it address the shortcomings of other approaches?
Completion Focus: Work items are not presented as to-do lists. They show a progression to meet an objective. Completing work is still important and it is represented in a consumable manner.
Value Delivery: This is closely related to completion focus above. This approach naturally shows the progression to achieve the next value goal, and the next one and the one after that. The value proposition is always accessible by following the path.
Improve Collaboration: This is achieved in three ways. Firstly, the representation is easy to consume and understand quickly. Secondly, it is clear what value the team is striving for and what it will take to get there. Lastly, there is a consistent vocabulary and metaphor that can be used at all levels of the organisation.
Scalability: There can be any number of paths to reach a destination and each path can be an arbitrary length. The same concepts can be applied consistently regardless of the size of the project.
Flexibility: Just as in real life when travel plans change, the route may be altered. Paths can be added, removed or re-routed as necessary .These changes are easy to make and are easy to assess with this representation.
Query Support: A rethink of what a query should be for a journey is necessary and deserves its own post. For now, it is sufficient to say that it is possible, and it is really useful.
Have you ever found yourself referring to product development as a journey or a progression? Have you ever been frustrated by how much time you spend trawling through work items? If that is the case, then hopefully some of these ideas resonate with you. I’ve only just scratched the surface of where this is going. A teaser if you will. There is more to follow.
If this post has excited you, or reinvigorated a passion for truly Agile development, feel free to reach out to me. We are on the lookout for great people to evaluate, improve and refine these ideas. If that is something you would like to be a part of, let me know.