The first article in this series looked at Aligning Around Value and the challenges that presents, this article will look at the practical aspects of “Aligning around Value”, and the final article will look at Funding and Reporting.
The material in these articles was first presented as a series of webinars available here.
Value Stream and ART Identification Workshop
The Value Stream and ART Identification Workshop is the practical process used to try to re-arrange your organization around value.
Buried at the heart of that is the simple statement:
Group the people in Development Value Streams
But how? What logic drives these decisions?
It is a bit of a black art, there’s not much written down.
Who should be working together?
Since the Value Stream and ART Identification Workshop was introduced to the Implementing SAFe Training back in 2016 Ivar Jacobson International has analyzed a few hundred Value Streams. Because the training is open-enrolment the analysis has covered scenarios from across the whole spectrum of industries rather than being constrained to a single company or industry. Time constraints within the training mean that it can be quick and dirty but it still generates enough data to allow patterns to seen that emerge when doing this repeatedly. It’s those patterns that this blog will explore.
Inputs
Before discussing the logic behind Development Value Streams it’s necessary to check that the right information is being gathered.
Map Out The Operational Value Stream
Map out the Operational Value Stream, the set of steps to get from trigger to.
Figure 1: Map Out The Operational Value Stream
What makes it a value stream? It’s a repeatable set of steps, the same each and every time.
If you’ve got a business process already mapped then use that as starting point. You probably don’t need the level of detail contained within the business process for this exercise and when the steps are being mapped out always ask “will this extra step result in finding another system?” if the answer is yes then add the step, if the answer is no then it’s more detail that needed so it can be combined with an existing step.
The grey figures at the top are the internal staff that keep the operational value stream running. In the Loans example used in the toolkit that could be Branch Staff or Call-Centre Staff interacting with the true end-customer, it could be back-office staff in the bank keeping the wheels of commerce turning. They are potential customers for our Development Value Stream. Remember, from a Lean perspective, The Customer is just the “recipient of our work”, they are Internal Customers. It should be possible to speak to internal customers directly so they can tell you what they want, what they really, really want1; rather than relying on people adopting developed personas and trying to answer on the customers behalf.
Solutions that support the Operational Value Stream
The next step is to identify the Solutions that support the Operation Value stream. Whilst these are being identified it is useful to gather some attributes about these solutions since those attributes can inform the decision logic later in the process.
Figure 2: Identify The Solutions That Support The Operational Value Stream
The attributes of interest are:
Tightly coupled
Can’t release Solution A without releasing Solution B at the same time, perfect lockstep. It might make sense to keep these two solutions within the same Development Value Stream so that release coordination is easier. Long term, tight coupling is bad, consider re-architecting, but this might be a compromise we make to get going so that the lean/agile processes can be used to help with the re-architecting.
External
The solution is external to our organization, we have limited or no control over its development. An example of this from the Loans scenario that is used in the training and toolkit might be Credit Scoring, it’s not uncommon for this service to be provided by an external supplier, Experian and Equifax are UK examples of companies that provide credit scoring checks. These external systems are needed by the Operational Value Stream so they can’t be ignored, there will be a handful of people maintaining the contract and relationship and making sure that the system is accessible from within the organization, those people will need to be part of a Development Value Stream somewhere at some point and it will need funding.
Shared
The solution identified doesn’t just support the Operational Value Stream that we are assessing, but lots of other Operational Value Streams as well. From the Loans scenario, the example would be Core Banking, do you think it’s unique to the Loans Operational Value Stream? The clue is in its name, Core. It supports Loans but also Credit Cards, Current Accounts, probably more. It’s going to have a different set of stakeholders from the systems that are unique to the Loans Operational Value Stream, and it’s those differences in stakeholders that will inform our decision logic.
People who develop and support the Solutions
Find everyone involved in developing those systems and keeping them running.
Figure 3: Everyone Involved In Developing And Maintaining The Solutions
Get the raw numbers, ignore the size for now.
Ignore existing organisational structures, this exercise is all about who “should” be grouped to keep things working, defer the compromises caused by corporate politics until later.
Don’t double count, if people support multiple systems show them supporting multiple systems.
Suppliers
If the supplier is providing people as Staff Augmentation, their people are embedded in the trains and teams and, from the perspective of the work, they are treated as if they are the organisations employees, then they’re part of these numbers.
Beyond that you need to look at your supplier relationship.
If there is direct control over what the supplier is doing, then they should be included here. The example would be a supplier that is building a bespoke system just for the organisation. Maybe you can persuade them to run as an Agile Release Train in line with the organisational cadence.
If there is no direct control over what the supplier is doing, requests for change can submitted but the requests are competing with the suppliers other customers. Examples here would be CRM Systems like Salesforce, or an Operating System like Windows, they can be configured but customers don’t have the ability to change them directly. These solutions are truly external and the only people that should be listed here for this exercise are the people maintaining the contract and relationship, and making the system visible and present within the organization.
Logic
Raw data gathered, now we can look at some of the decision logic to Group the people into Development Value Streams.
This is where the black magic happens.
The only official advice given is Minimize the Handoffs and Dependencies, Flow Accelerator #3, that can be elaborated on a little more…
- Tightly coupled systems probably want to be in the same Development Value Stream. If they’re together it will be easier to coordinate than if they were in separate Development Value Streams. This minimize Handoffs and Dependencies.
- Can the Development Value Stream own value delivery end to end. If all the systems involved in end-to-end value are within a single development value stream, then this will minimize Handoffs and Dependencies. If it is necessary to break end to end delivery across separate Development Value Streams then look for loose coupling where the Development Value Streams can release independently of each other.
- Systems with similar stakeholders and funding sources might want to be in the same Development Value Stream, conversely systems with dis-similar stakeholders might want to be in separate Development Value Streams. This is where the information about whether the systems are Shared across Operational Value Streams becomes useful.
- It would be useful if the Development Value Streams are large enough to be empowered to self-organize to service the needs of the systems that the Development Value Stream is responsible for. There is a U-Curve style optimization at work here, too big is unmanageable, too small and you have keep reorganizing the budgets, rather than just letting the people reorganize themselves. Does the Development Value Stream make a sensible funding unit, remember that within a SAFe Portfolio it’s the Development Value Streams that get funded.
There might well be others factors that organizations are considering over and above those listed above. There will be no right answer, compromises will need to made to find acceptable groupings.
Patterns
What are some of the patterns that start to emerge?
Top & Tail, Value in the middle
Within the training material Scaled Agile provides a number of examples.
The worked example is Loans from a Financial Company, there is also Vehicle Manufacturing and Software Sales. They’re nice, but actually all of these could be collapsed into a generic “Sales” scenario. Each example uses different words, but there is a step to engage the customer to make the sale, provide the product, then take payment.
The systems supporting that are Customer Relationship Management, The Product and Payment. Different organisations may have different names for these systems, they may have a collection of subsystems rather than a single entity. It doesn’t matter, remember that for the purposes of patterns we want to aggregate, abstract up out of the tiny details.
Figure 4: Pattern: Top and Tail, Value In The Middle
The pattern that regularly emerges is that CRM and Payment are often linked; not necessarily a tight coupling, but information flows between them. The Development Value Stream is a U shape encompassing the top & tail of the Operational Value Stream. When drawn it looks a bit odd, the U shape isn’t what you naturally find in neat ordered pipelines, but it’s arising because those systems are related and their stakeholder sets are often similar.
Sat in the middle is the product, the thing of value that is produced, that the customers desire.
It’s that Product in the middle that can be challenging. This whole process, the Value Stream and ART Identification workshop works best when there is a set of systems to support a process through which the product or service is offered, rather than selling the product directly. The Loans example from the training material; there are a number of systems supporting the issuing of a loan to an end-customer, the systems, the output of the development value streams are not the product. The immediate customer for the systems are the internal staff, the grey shadows above the operational value stream, the branch staff, the call centre operatives, underwriters making eligibility decisions. Which means lots of systems to group people around, lots of opportunities. Minimise those dependencies, keep tight couplings together, common sets of stakeholders, and don’t let the development value streams get so small that self-organisation becomes challenging.
The Monolith
However, if the product is sold directly, it’s not uncommon to end up with a monolith. Typically the product cannot be sub-divided, it’s all or nothing. If you want to build a vehicle you need the design specifications for all the parts of the vehicle that are going to be assembled, having just half of them means an incomplete production line, and the value is only achieved once the vehicle rolls off the end of the production line. A half assembled vehicle without insight into how to finish it, definitely not valuable.
Figure 5: The Product Is A Monolith
This monolith can be quite large. Precise figures for exactly how many people are involved in designing and engineering a vehicle are hard to come by, but having worked with a few vehicle manufacturers in the past, the magnitude of the people involved in the design is going to be in the order of several thousand.
The challenge becomes breaking the monolith apart. There are a couple of things we can try…
Rephrase The Question
Figure 6: Rephrase The Question To Break The Monolith
| Rephasing The Question : Game Engines |
|---|
|
I was running an Implementing SAFe training in Stockholm and some of attendees were from a video games company that produces a game engine utilized by a number of video game development studios that actually produce the games. The game engine provides common technology for getting graphics displayed on the screen, sounds coming out the loudspeakers, so that rather than each game studio having to reinvent the wheel on the underlying common parts, they can instead focus on storyline and gameplay, the things that differentiate their game from the next. We ran the Value Stream exercise using the Game Studios as the customer and it became the “Sales” Value Stream we’ve already seen, a handful of people dealing with CRM and payment and several hundred people producing the product, the game engine in the middle. We started discussing how we could break the monolith up and the conversation pivoted to “what if we change the customer?”.
Instead of treating the Game Studio as the customer, what if we looked at the staff within the game studio, Graphical Artists needing to get three dimensional models and textures into the engine, Sound Designers trying to add sound effects and music. When they became the customers and their needs became the trigger, then we had much more productive conversations. No longer was it “the monolith” that was the game engine, but modules within the game engine that the customers Operational Value Stream impacted. |
Sometimes rephrasing the question, going for a slightly different customer might yield more insight.
Might… it won’t always. Going back to the vehicle example, different personas of end-customer could be considered: commuter drivers, traveling salesmen, mums or dads on the school run. They all utilise the car in roughly the same way, no help what-so-ever for decomposing the monolith.
Architecture
Avoid jumping straight to architecture, try to pursue more customer-centric means before resorting to techno-centric means.
If all other possibilities have been exhausted, then maybe look at Architecture. Are there any sub-systems, components, pieces of the monolith, that are loosely coupled to the rest of the system, that can be split apart and run separately from the rest with minimal Handoffs and Dependencies.
Figure 7: Using Architecture To Break The Monolith
In the vehicle example from earlier, the powerplant can typically be updated separately from steering and suspension, which is independent of interior fittings, which is independent of autonomous driving functionality. If everyone sticks to the agreed space and interfaces, which are bolt-holes in case of mechanical design, then they can make changes as much as they like. Anything that would change the agreed space or interface would become a collaboration between the affected parties to reach sensible agreement.
Often architectural units are coupled with domain expertise:
| Domain Expertise : Operating Systems |
|---|
| In my distant past I used to be part of a thousand strong team that built an operating system for mobile phones. I looked after a team that dealt with the networking stacks, but that expertise in networking isn’t immediately transferrable to other parts of the operating system, you couldn’t drop a networking engineer into one of the teams specialising in the graphics subsystems and expect them to operate at the same level they were when they were in their own domain. Camera, Microphone and Audio processing, File systems and storage, The Snake Game, all domain areas where it takes significant time to gain knowledge and expertise. |
Be wary of Conway’s Law and the inverse of Conway’s Law. Conway’s law is that “architecture follows organisational patterns” the inverse is that “organisations are constructed to mirror the architecture.”. It is necessary to avoid both, put organisational structures and architecture in place that supports the goal of Lean: “Value in the shortest sustainable lead time.”
The Dual Operating System, the network and the hierarchy, and the ability to change the network rapidly means that organisational structures are likely to be ahead of any significant architectural changes. Therefore, consider not just the current architecture but the desired future architecture as part of the value stream discussions otherwise the organisational structures will be constrained by the old architecture.
Do make sure that future architecture is aligned with, and supporting, value delivery in a lean/agile fashion.
System Replacement
The most extreme of these architectural initiatives is System Replacement. It’s not economically viable to continue with the old system, a new, replacement system is necessary.
Figure 8: Pattern: System Replacement
Although internally all the existing engineering might be ripped out and started again in a brave new world, from the perspective of the customer, they don’t care whether it’s old tech, new tech, they just want it to work. Therefore when facing a system replacement, perhaps both the old and new should be owned by the same Development Value Stream.
Consider the old world, a project would have been set up to instigate the new, replacement system, and that project would spend all of its money on the shiny new system and not spend any of its money turning the old system off. Which means there is now a new system running and an old system, and it costs money to keep both running. It’s not uncommon for organisations to have significant numbers of old systems running that nobody turned off and these become a vampiric drain on the organisation sucking away all the available funds just to keep them running.
If a Development Value Stream owns both the old and new systems, then the Development Value Stream can become responsible for coordinating the changeover from old to new. Unlike the Project, the Development Value Stream feels the cost of keeping the old system running and is more likely to turn it off in order to ease that pain.
Because the Development Value Stream funded and then empowered to self-organise, as the old system is turned off, the personnel involved can transfer over to supporting and improving the new system. No need for new budgets, it’s just the individuals concerned are now drawing from the new backlog rather than the old. They are more likely to turn the old system off if they know that there is career continuation after the old system has been shut down.
Shared Services
Shared Services sometimes become their own Development Value Streams; this is because of different sets of stakeholders. Consider the Loans example:
Product Management looking after the Loans specific systems only has to deal with the Loans Operational Value stream as it’s stakeholder.
Core Banking system has Loans, Credit Cards, Current Accounts and more, as stakeholders.
The Loans systems just needs to do the most valuable thing for loans, whereas the Core Banking has to determine what’s most valuable from all of the requests coming in from Loans, Credit Cards or Current Accounts. The prioritisation challenges are different and mixing them together would likely result in conflict amongst the sets of stakeholders because the needs of the local and shared systems are different.
Figure 9: Pattern: Shared Systems, System Aligned
Here comes the compromise.
If shared services become separate Development Value Streams, then to get end to end value delivered there will potentially be collaborations between the Development Value Streams. How frequent are those collaborations? If they’re occasional then maybe they are just managed. But, if the requests from the business always require the Development Value Streams to collaborate maybe it would be better to split the Shared Service Development Value Stream up and distribute the people into the Local Development Value Streams.
Figure 10: Pattern: Shared Systems, Operational Value Stream Aligned
Now we can get value delivered end to end without extra collaborations, but there will need to be something instigated to look after the long-term technical strategy for the shared service, to keep an eye on it’s technical health. Usually, an explicit community of practice around the shared service is given that mandate, the community can create Enabler Features that can then be dropped into one of the Development Value Streams for delivery and the members of that community can champion those Enabler Features when they are back in their Development Value Streams.
The compromise is if one dimension is picked then there will need to be something else in the other dimension to look after it.
Everything Shared
What if everything is shared?
This scenario has been observed in Insurance companies but will be applicable to other organisations. The solutions support all of their Operational Value Streams. The Policy Issuing solution is utilised by Motor, Household and other insurance lines.
The previous discussion still holds, the Development Value Streams could be aligned around the systems at the expense of more collaborations to get value delivered end to end.
Figure 11: Everything Shared, System Aligned
The Development Value Streams could be aligned more closely with the Operational Value streams by having representatives of each system in the Development Value Stream but that comes at the expense of needing explicit communities of practice to look after the technical health.
Figure 12: Everything Shared, Operational Value Stream Aligned
| What are you optimising the organisation for? |
|---|
|
When the Operational Value Streams utilise common shared systems then one of the question to ask the organisation is what are they optimising themselves for?
If the Organisation wants to optimise the Operational Value Streams for speed, adaptability and time-to-market, then the Development Value Streams that support an Operational Value Stream should be aligned with the Operational Value Stream and the Development Value Streams should have full ownership of the solutions that support the Operational Value Stream. The Development Value Streams are then able to make any changes necessary to the solutions to quickly adapt them to support the Operational Value Stream. However, this comes at the expense that each Operational Value Stream can end-up with its own variant of solutions that are replicating common functionality across the Operational Value Streams. If the Organisation wants to optimise the Operational Value Streams for cost and consistency, then the Development Value Streams that support the Operational Value Streams should be aligned with the shared solutions. An Operational Value Stream doesn’t have direct ownership of the solution, its change requests will be competing with changes from the other Operational Value Streams, therefore its requests may be delayed if other requests are perceived to be more important and that delay means that it can’t move as fast as it could if it owned the solutions directly. The cost savings and consistency come from the fact that one solution supports many Operational Value Streams, it minimises the chance of duplicate solutions performing the same function. There is no right answer, neither option is better than the other, it’s case of the organisation understanding what it wants to optimise for and then understand the results of that decision. |
Micro Services
We’ve explored one extreme with the Monolith. The other extreme is Micro Services, every piece of the architecture is its own little thing that can release independently of all the other units. Each of these can be considered a Development Value Stream in its own right.
The training material suggests that you should group these small Development Value Streams together as an Agile Release Train, but that only works if there is some commonality between the Development Value Streams, such that teams within the Agile Release Train can move between the Development Value Streams.
Figure 13: Pattern: Microservices, Group Commonality
If the teams can move then the Agile Release Train can be made responsible for managing the load balancing.
Imagine that one of the small Development Value Streams had a sudden rush of requests, if the teams can move then they can all contribute to getting these important requests done and by swarming on the work they’ll get it done quicker. This is the embodiment of the little bit of logic that was “need to be large enough to be empowered to self-organize”.
Whereas, if only one team can work on the functionality and there is a sudden rush of requests around that functionality then it takes the team as long as it takes because the remaining teams can’t help.
Independent Teams
Sometimes there are a set of small development value streams left over that don’t have anything in common and the teams looking after them can’t easily transfer to another development value stream because specific domain knowledge is involved.
What you shouldn’t do is group these teams into a train. The worst place to be putting together a plan is in a big noisy room full of people that you don’t interact with. Also, one Development Value Streams Business Owners generally aren’t interested in the other Development Value Streams.
PI Planning starts to fall apart.
Not everything has to be a train.
However, if you are the portfolio, you don’t want issuing pocket change funding to individual teams, you want to fund large, sensible lumps.
Fund the group of teams but let them plan independently.
Figure 14: Pattern: Fund The Train, Internally Independent Teams
Each individual team should still be creating a PI Plan, but they don’t need to do it through a big room planning event, they can create it themselves. They should be falling in line with the cadence of the rest of the organisation and be planning at roughly the same time as the real Agile Release Trains, so that collaborations can be negotiated if necessary. They should create objectives so that they communicate what they’re trying to achieve within the PI, and at the end of the PI the loop can be closed on whether they have achieved them, and therefore how predictable they are.
The Interface up to Portfolio looks like a train to provide a sensible funding unit, internally the teams act not as a train but completely independent teams.
Not A Train, Train
Another scenario observed in an Insurance company, but will be applicable elsewhere.
| Not Your Typical Train : Brokerage |
|---|
| There was a group people that dealt with Brokerage, buying and selling of insurance policies through brokers. This group had 8 managers and 5 engineers, yet they consumed a budget equivalent to one of the Agile Release Trains that was 100 people in size. Rather than developing things themselves they bought in external systems and services which the small team of engineers then glued together into a functional whole. |
It is a Development Value Stream, there is a clear trigger, process and value realisation for both customer and organisation at the end. Internally though, it’s not a typical Agile Release Train. Remember that the definition of a Development Value Stream is “all the people, resources, tooling, infrastructure, contracts, and materials to allow it to deliver value”. In this case, the money spent on infrastructure and contracts far outweighed the money spent on the people.
Figure 14: Pattern: External Systems Train
The situation was resolved by turning the managers that managed the contracts and relationships with the suppliers into an agile team and the engineers were already acting as a team. The teams were kept aligned by having a shared Product Owner and Scrum Master. The teams fell in line with the organisations PI and Iteration cadence and did a cut-down version of PI Planning to generate their objectives for the PI.
Validation
How can it be determined whether the proposed Development Value Stream and Train setup makes sense?
Look at the pipeline of work, look for Epics that are specific to the Operational Value Stream.
If the work neatly falls onto individual parts of the proposed structure, then it’s a good structure.
Figure 15: Validation: Work Matches Structure
If the work keeps cutting across the proposed structure, then maybe it’s not such a good structure. Maybe pivot the organisation to align with the flow of value as discussed earlier.
Figure 15: Validation: Work Cuts Across Structure - Pivot
To act as validation the work, the Epics, must be business needs; if you’ve pre-sliced them to fit organisational structures or architecture, then you render the test invalid.
Conclusions
| One last thing… |
|---|
|
This stems from one of my very first consultancy engagements, I was across in Munich working with Drew Jemillo, one of the founders of Scaled Agile, and we had a Development Value Stream of 150 people, too big for the 50 to 125 sweet spot of an Agile Release Train. Two days of discussions cut it this way, cut it that way, still no answer.
Drew placed an overnight call to Dean and the response that came back was “run it as a big train, PI Planning will be painful but manageable and you’ll gather data to make an informed decision next time.” We kept it as single train, PI Planning was painful, Plan Reviews were taking in excess of 2hrs, but we did learn. From the ART Planning Board we learnt which teams worked with which other teams, we could start to see the cut of least resistance through the group. They did one more PI Planning to validate their hypotheses before splitting for the 3rd PI Planning event. |
Do Something
Gather Data
Base Decisions On Insight
Adjust
Adjustment can always be made at the PI Boundaries. Organisations crave stability, it helps with building trust, getting honest metrics, performing systemic improvement, but change must be welcome and for the first few PIs change is likely to happen as organisation iteratively home in on the best structural solution for now2.
Next
Having aligned around value, it is necessary to ensure that those Development Value Streams are doing the right thing. The next topic is therefore Funding and Reporting, the flow of money and understanding whether it has been wisely spent.
#1 Spice Girls : Wannabe
#2 No organisation is static, it will be necessary to revist the setup regularly, as discussed in Part 1 : Aligning Around Value