The first article in a series of three looking at Organizing Around Value. This article will look at why we organize around value and some of the challenges that re-organizing presents. Subsequent articles will look at the practicalities of how organisations Organize around Value with the Develelopment Value Stream Patterns that arise and, finally, at how reporting changes once organized around value.
The material in these articles was first presented as a series of webinars available here.
What is value?
Value is very subjective, different organizations will assess what’s valuable to them differently.
For many organizations it will be money, profits, but not all.
|Example: NHS Blood & Transplants|
|For the British National Health Service’s Blood & Transplant Division the measure of value is maximising the number of people whose lives are improved when someone graciously donates blood or organs. The money can’t be ignored, they’re expected to have balanced the books by the end of the year, but it’s not their primary measure of value.|
Each organization must work out what’s valuable in its context.
What should be said is that: The value is already there, and it is flowing. You already have Value Streams, you just need to uncover them, make them visible. For value flows, it flows like water and just like water, value always finds a way to get through.
Organizations find a way to get to the value they want, despite the blocks that many organizations inadvertently put in front of themselves. Because, if that value isn’t flowing then the organization is dead.
It’s really a question of efficiency: how efficient is your organization at generating value? The more efficient you are at generating value and the more rapidly you can reorganize how you generate value, should such reorganization be required, then the more likely you are to survive.
Always remember that survival isn’t a given; you have to earn it!
Why align around value?
This blog could just recite the words from SAFe Principle #10, Organize around value and talk about better communication, faster time to market, automatic alignment with the business, but rather than repeat what has already been said it might be more useful to try to illustrate it visually.
Think of the water in the following images as value flowing through your organization.
Figure 1: Turbulent Flow
Images courtesy of dreamtimes.com, Royalty-Free and public domain (CC0) images
In the above image the value is flowing, it’s getting there, but it’s got to work its way around all the rocks. The rocks represent the processes that don’t quite work right, the departments fighting each other. All that turbulence is the noise of managers in meetings arguing, the roar of people just trying to get stuff done, the thunder of work continually crashing up against blockages and having to navigate around.
Figure 2: Smooth Flow
Images courtesy of dreamtimes.com, Royalty-Free and public domain (CC0) images
In the above image the value is flowing un-impeded. The structures around it supporting it to get to where it needs to be, smoothly, efficiently. Lean/Agile ways of working aren’t a magic bullet; they don’t suddenly make the engineering staff directly faster or better, the engineers can become faster because the organization becomes more efficient, less effort is being wasted on the turbulence.
Aligning around Value also gives the organization more control. Control in this sense is not dictating to individual engineers the minutiae of their day to day work, but control of the organization as a holistic whole. The more turbulent an organization is, the more that people have to fight the system, the more likely the organization will try to cheat the system. Subcontract out, develop the system with off-the-books developers; the organization gets the value flowing through informal means since the formal means aren’t fit for purpose. Just do it in an Excel spreadsheet… except because you’re a bank, and those cells in the that spreadsheet are money, all it takes is an accidental slip and an extra zero here or there can mean big problems. The auditors don’t like the fact that there’s precious little in the way of audit trails to track who changed what, and what went where. If you’re aligned around value, you’ve got much greater control around getting things done right, because there won’t be a need to cheat the system.
The water metaphor can be pushed a little bit further as well. How consistently is value flowing? Is it flowing as a steady stream, every day, week or month the organization gains value, a good example of steady flow: consumer products continually being sold.
Or is the value flow a flood surge? Everything at once and then nothing for ages. The example of flood flow would be: the once a decade government defense contract. I know which scenario I would prefer; the predictability of a steady flow of value is a lot easier to deal with. Turning flood surges into steady flow requires a lot of infrastructure; that has to happen because the consumption of value tends to be a steady flow. How is the value consumed: it’s the operating expenses of your company, the wages, the rent, raw material costs, they get paid out in a steady flow. To manage the flood surge and turn it into a steady flow in the physical world dealing water it’s dams and holding reservoirs; in the world of business the accountants have to put the value, money aside, for use in the future. It’s a lot easier to match things together if both the generation and consumption are both flowing.
Water metaphors over.
Starting point to reorganizing
It’s not enough to know where the organization wants to get to, that’s “aligned around value”, but to plot a sensible route to that destination also requires knowing where you are starting from.
There are obviously many different starting points, but there are common themes; either organizations weren’t aligned around value in the first place, or the value that they were aligned around has changed.
You don’t have to align around value.
You should, in order to get the benefits that come with aligning around value, but it doesn’t have to be the first thing you do.
It’s not uncommon when transforming organizations, that a group of people that want to be more Agile than they were present themselves and want to start running as an Agile Release Train. As a coach are you going send them away saying “don’t come back until you’ve organized around value!” or are you going to help them?
Even if you’re not aligned around value the act of planning together collaboratively as a train and taking ownership of the tools and process to get flow going, it’s going to be better than the old world.
The act of collaboratively planning together, well that generates so much information that can then feed into the conversations about who needs to work with who both across the teams but also out towards the business, and it’s those latter observations that can feed into alignment around value conversations and the structures put in place now can be evolved to align around value over time and they will need to continue evolving because value for our organizations typically changes over time.
Value Has Changed
The second scenario: the organization had been structured around some value, but that value has now changed.
Organizations are not static, they are continually experimenting, trying new things to see if they are more valuable than what they are currently doing.
When Amazon first started almost 30 years ago its primary revenue stream, how it generated value, was selling books.
Within 2 years they’d expanded that to CDs and DVDs and other cuboid objects that can be boxed easily.
What is Amazon’s primary value earner now?
Amazon Web Services.
It started as the infrastructure team for the webstore and the need to have a scalable infrastructure to cope with the demands of Black Friday and the Holiday periods. Then someone had the bright idea that… “this could be sold in its own right!”
That evolution in value hasn’t just affected Amazon, it’s caused others to evolve their value offerings as well, Microsoft with Azure, Google with Google Cloud amongst others.
The activities to align an organization around value aren’t just done once at the beginning of an Agile Transformation, they need to be revisited regularly. Not sprint by sprint, annually perhaps? Maybe a decision, like Amazon’s “let’s start selling the infrastructure”, is the trigger to revisit.
When revisiting it’s easier than the first time around, you’ve already got the information from last time as a starting point and the participants know what to expect and what to look for.
The organization has identified that there is a need to reorganize; now it has to go on the journey of reorganizing and that journey is never an easy journey.
To change the culture, you have to change the organization.
To adopt a Lean-Agile culture the organization is going to have to change. It will be necessary to reorganize the people, to put new structures, new roles, new responsibilities in place.
If you don’t then you won’t see any change other than adoption of a few agile buzzwords, because the old organization persists. Just using agile buzzwords doesn’t make you agile!
However, if the old world is torn up and a brave new agile world instigated in its place, then the agile world will become the new hierarchy. Every revolution soon becomes the establishment and becomes fixed in place.
The solution is not to trash what we know and start over but instead to reintroduce a second system.
This is where the dual operating system becomes useful.
The Dual Operating System, it’s that little bit in the first section of Leading SAFe, where everyone hears that SAFe is for forming the network, very little is said about the hierarchy, and everyone moves swiftly on to the practical stuff in the competencies, the principles and eventually the practices and processes to get work done. However, if you want to be Agile, to be able to reorganize rapidly to meet future challenges, then the Dual Operating System is a very important piece of the Business Agility puzzle. Don’t jump over it, understand it.
Figure 3: Dual Operating System
The hierarchy is permanence and it’s there for things like line management, contracts, pay and rations, rewards and discipline, things which need stability and some degree of permanence.
Understand that it’s not an exclusive placement one or the other, the workforce is in both the hierarchy and the network. Hierarchy for the stable things like contracts and pay, Network for the transient things like: “what are we working on today?”
When the network is adjusted, there is no need to change line management, there is no need to change contracts or pay, it’s just that the people being worked with and the backlog that work is drawn from may change. Reorganizing around value is about setting up the network of Development Value Streams and making sure that the network is aligned around delivering value. If value changes, the network can be adjusted.
What will need to happen as part of the reorganization is make sure that everyone understands their new responsibilities. In particular Line Management is now solely concerned with the pastoral care of the workforce, they are not responsible for the flow of value that comes through the network that responsibility lies with the roles within the network. Check that the individuals concerned want to be Line Managers, people persons. If they got into management to direct the work then it may be necessary to remove their line management responsibilities and steer them towards one of the other SAFe roles such as Product Management, System Architect or Release Train Engineer, or perhaps their Solution Train equivalents if you’re operating at that scale, since it’s those roles that have joint responsibility for the work.
This is the instigation of new roles, new responsibilities, the changing of the organization, and it’s the middle management level that undergoes the biggest change in any Scaled Agile transformation. It’s not uncommon to meet some resistance to this, over the years that middle management layer has been referred to as the permafrost, the sticky middle, amongst many other, usually derogatory, names. Sell it to them this way: due to SAFe’s separation of responsibilities, work is separate from technical and architecture which is separate from facilitation which is separate from people and line management, whatever you as a middle manager enjoy doing, SAFe can get you more of it and will try to move the responsibilities for the things you don’t enjoy to someone that does enjoy doing them. Phrased that way, making their lives easier, hopefully there will be less resistance to change.
When reorganization is discussed everyone immediately thinks about the people: Who’s working with who? What they are working on?
Allowing all of that to happen is the money. How an organization is funded and how it perceives the money to flow has a huge impact on how agile the organization can be.
To give organizations the best chance of achieving Business Agility then it is the Flow of Value that should be funded, not the work.
If the work is funded then the money will be spent on doing that work, the people can’t decide to go and do something else. They have to do the work that has the funding, even if something else is potentially more valuable. That means they’re doing something less valuable, that is never a good thing. That loss of freedom also limits the ability to be Agile, it’s stopping you from achieving the goal of Lean which is “Value in The Sustainably Shortest Lead Time.”
Changing the money can be hard.
Why is all of this so hard?
Because it’s a people problem, it’s all about authority:
“This is my money, you do wot I say!”
When you take the money away, they lose their authority, their power.
Agility is about “moving the authority for the decision to where the knowledge is”, SAFe Principle #9, Decentralize Decision Making. Direct control is replaced with Intent, a Vision for what the organization should be doing and then empowering the teams to work out how to achieve that vision. Those people responsible for setting the vision will have to argue each piece of work, each Epic, each Feature, justify its value for the organization as a whole, and they will be competing with each other for space on the Agile Release Train Backlogs. Their work might not get done, this will be frustrating for them, but it’s because something else is more valuable to the organization as a whole. That frustration will be amplified if they’ve been incentivized to deliver their bit, they’ll become “selfish, competitive and thus destroy the system”, to quote W. Edwards Deming. You need to ensure that they’re incentivized around the success of the system as a whole, so that they are encouraged to collaborate, one can sacrifice their work for another for the benefit of the system as a whole and they will be rewarded for that.
Internal competition is madness, it’s the organisation destroying itself, you should be competing against your competitors, the clue is in the words!
This is also hard because if you are a team level agile coach then this all takes place several pay grades above your experience. If you want to coach at this level, you need to learn the language of the executives and empathize with their worries and their concerns.
It is different to coaching engineers. Most executive are not suffering from the empowerment problem that engineering teams face, the regaining of empowerment to be engineers again; at the top they have all the empowerment in the world, if they say “make it so”, it will be done. What they need at the top is to be able to see the problems that they are facing and to understand how they can influence the new Lean/Agile processes to solve those problems. Processes they probably have no prior knowledge of and will need guiding through. Coaches should never be doing the executives job for them, the Executives need to decide on things for themselves. The coaches job is to steer them towards using those decisions to influence the Lean/Agile processes and helping them interpret the information coming up from the Lean/Agile processes to close the accountability loop and ensure that the decisions made did the right thing.
Anti-patterns to organizing around value
There is only one anti-pattern and that is “not aligning around value” it really is that black and white, you’re either aligned or you you’re not.
To gain insight you need to drill down at least more level and ask: “Why hasn’t an organization aligned around value?”
That is when more interesting information starts to emerge.
Every scenario is going to be different, but there are common themes that regularly occur. These can be broadly grouped into Internal Factors that the Development Value Stream has control over, and External Factors that are beyond the Development Value Stream.
The scenarios that outlined here aren’t all-encompassing, organizations may well encounter something beyond these themes.
Consider Internal Factors first.
- Roles, Responsibilities – The Roles and Responsibilities need to be aligned with Value and the people need to adopt the right behaviors. Why aren’t the people willing to adopt the new roles? There is no magic fix for this, it’s people change, it’s listening to their concerns, demonstrating how the new system of working interacts with their concerns and then guiding and coaching them to help them do what they need to do using the new system of working. Behavioral change is hard, it takes time and a lot of support.
- Work – Work created for a different system of working doesn’t always fit neatly with the new system of working. Sometimes is is necessary to ignore sunk costs; all the time and effort that had been expended in creating a massive work-breakdown structure, let it go. For Agile Trains and Teams to work effectively, the work needs to be problems to solve, not solutions to enact. It’s the posing of problems that allows us to empower the Trains and Teams to self-organize to solve those problems and it’s through empowerment and self-organization that you start Unlocking the Intrinsic Motivation of Knowledge Workers, SAFe Principle #8, The organization is doing this in order to start realizing the full potential of its employees. Preparing good Features is an art (pun not intended), it’s a real skill, there’s not a lot written about it, the framework favors keeping it an open topic which does mean that organizations can evolve bad practices as much as good practices; SAFe Fellow and colleague Ian Spence has written about Feature preparation.
Sometimes the Bigger organization doesn’t care.
|Example: Investment Bank - The tail can’t wag the dog.|
A few years back working with a group of just under a hundred engineers located in the middle of a major investment bank of a hundred thousand staff.
If this small group had demanded that the investment bank change its way of working in order to allow the group’s 100 engineers to be Agile, they would have been thrown out of the building, forcibly. Thankfully the 100 engineers were given enough freedom by the bank that they could operate any way they wanted, so they set themselves up as an Agile Release Train working in a Lean-Agile Fashion and aligned around improving the value in the solution that they were responsible for.
They got quite good, award winning even, other parts of the bank took notice and Agility started to spread. There are still limits, alignment across systems is hard, analysis across systems to improve the true end-to-end flow of value is hard, and it might always be hard because the Bank might never change, but at least within their sphere of influence they’ve made things better for themselves and their immediate customers.
Finance has been touched on as well. That investment bank from the earlier example is always going to be thinking in terms of Projects, it’s how they finance change within the bank, and that is unlikely to change in the immediate future. Thankfully, these projects are bank scale projects, significant sums of money, enough to fund a sizeable fraction of the Development Value Stream for a year. The Agile Release Train, the value stream, gets funding from two or three of these bank scaled projects alongside a block of funding to “run the system”. The sources of funding mean there are constraints, any project putting funding into the Agile Release Train expects the train to be working on the sort of functionality that it wants, rather than whatever the train want to do, but even within those constraints there is negotiation and choice. The key here is that the funding blocks are significant and they are funding outcomes, which allows freedom in the work that is done to achieve those outcomes. If it were the work being funded, individual Features, then that freedom is lost and the benefits that come from freedom, autonomy and self-organization are lost too.
Internal compromises are tactical, short term. Ultimately, organisations are going to want to change, to do the right thing, and because the factors are internal they can. Sometimes the right thing takes time, the compromise is being made now so that the organisation can start moving towards doing the right thing.
With the external factors the compromises may be more permanent since organisations are not in control of the external factors ourselves. Keep an eye on the goal “Value in the shortest sustainable lead time”, hold your compromises up to that goal and minimize the deviation from that goal as much as possible. Always keep pushing for external change, long term.
This blog has shown that organizations get the best chance of success if they align around how they deliver value and if the organizational structures, processes and decision making are aligned to support the delivery of value.
It isn’t easy, there is a journey to get there because it takes time to change structures and processes, and because, ultimately, it’s a people problem. It requires convincing people that this new system of working will get better results and showing them how they can influence the system of working to get what they are after without breaking the system.
The “SAFe 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.” There’s not really a lot written down, there’s not a lot of advice on how to group, who should work together, what logic drives those decisions, it really is a bit of a black art. Whilst each scenario is going unique, there will be similarities and given enough data common patterns emerge.
The next blog will explore the workshop and look at Patterns for Development Value Streams.