Where Transformations Typically Start, Could Start, and Options

Guidance from leading agile frameworks and countless consulting companies often start and focus on teams adopting agile.  Select a pilot or a few early adopter teams and get going. Then, make a bit of progress and expand the coverage to more and more teams.  Sound familiar?  Is this what you experienced at your current or a previous company?

This approach is commonplace.  I have supported many agile transformations that did this.  But is this the only way?  Is this the best way?  Could we expand our thinking and look at what options we have? Yes, we can and should!

Let’s take a quick look at why this is so common.  Time after time, I come across two scenarios.  One is where the process is waterfall, and there is a desire to use agile. The second is where an agile approach is being used but could be improved.  Teams have plateaued with their current framework. Teams are actually “hybrid” waterfall with some small bits of agile (aka Wagile, ScrumFall, ScrumBut, etc.).

Ok, focusing on the team level does look to make sense.  But, what if the improved team performance results in enabling the ability to deliver the wrong work or work of lesser value faster?

To get in the proper mindset, think about this question for just a moment – how is work being scoped and brought to the delivery teams at your company? Could you, with relative ease, tie that work to an initiative that supports a company’s strategic objective (OKR, GQM, etc.)?  Or is it just the latest hot idea from a Stakeholder? Is the work the smallest quantity of work that can be done and still be seen as valuable by your customers? Is the work of one team and one system part of an overall improvement that spans multiple systems which multiple teams?

Let’s expand our thinking to the value stream, how we go from an idea to delivering something of value to your customers.  We can spot other areas beyond just our delivery teams to enable them to make meaningful improvements in delivering value to our customers.

Figure 1 represents key areas in Disciplined Agile’s Ideal Value Stream covering how an idea flows through investment decision, ordering (priority), ready to implement, development, and deployment to customers.

Figure 1: Idealized Value Stream

Figure 2 is a common approach to agile transformations.  We tend to spend a lot of time on number 1, the delivery team’s adoption of agile before we branch out to other areas. For example, it is common to move to improve DevOps.  A distant third focal point is the delivery intake process, with a distant fourth (if ever) improving product and portfolio management.

Figure 2: Common Agile Transformation Approach

Figure 3 is an alternate transformation approach where the focus starts with establishing a delivery intake process. Then, all requested workflows through the intake management process, once approved and ready for implementation, are placed in a prioritized holding queue.  Using a queue enables the delivery teams to pull the work when they have capacity vs. pushing work upon them at any point in time.  This transformation approach is an example that started with establishing a solid intake management process to enable the successful adoption of agile by delivery teams.

Figure 3: Alternate Transformation Approach – Start with Intake Process

Figure 4 shows what may appear like a HUGE transformation strategy.  It could be, but that is not my intent with this option.  We can identify improvements across the entire value stream and begin with those with buy-in, capacity, and support that will not be cognitive overload.  I encourage you to just pause for a moment and think about the minimum viable changes (MVCs) that could be taken on, leading to initial improvements in how we go from an idea to delivering value to a customer.

Figure 4: Transformation Approach – Improve Value Stream

If you would like to learn more, please watch the Live Stream Event that I did with Al Shalloway and Steve Tendon here: Un-Common Sense No. 8: Where Agile Transformations Typically Start, Could Start, and Options.