The first article in this series looked at Aligning Around Value and the challenges that presents, the last article looked at the practical aspects of Patterns For Development Value Streams, this final blog will look at “Funding and Reporting”.
The material in these articles was first presented as a series of webinars available here.
Empowerment
Why? Why empowerment?
Empowerment means the organization losses direct control of the workforce but empowerment is one of the mechanisms through which the organization can deliver faster, better, cheaper and happier because the employees can make decisions for themselves quickly rather than patiently waiting for someone of appropriate seniority to decide for them.
Back to first principles
Which principles influence Empowerment?
Principle #8 Unlock the intrinsic motivation of knowledge workers and if you’re subscribing to Dan Pink’s theories from his book Drive then it’s Autonomy, Mastery and Purpose. Autonomy, empowerment to work out how to do things for yourself. Mastery, to be getting better at the things you do. Purpose, that you’re doing things for a reason.
Principle #9 Decentralise Decision making. If you cast your mind back to David Marquet’s video shown in the Leading SAFe trainings, he had two pillars, Competence & Clarity. Competence, that people have the skill they need to be able to decide how they do what they do, which ties in with the Mastery part of Principle #8. Clarity, that everyone knows what they’re trying to achieve, which ties in with the Purpose part of Principle #8.
From the perspective of ensuring that the organisation is doing the right thing, the interesting part of Principle #9 is that not everything should be decentralised. Decentralise everything that’s frequent, urgent and where the local information is going to be better and only centralise infrequent, long-lasting decisions where everyone must abide by the decision once made. The tagline on the card expresses this quite nicely. Centralise Strategy, Localise Execution. Strategic decisions tend to be infrequent, long lasting and everyone should be following the strategy. The Strategy provides Clarity and Purpose.
But, Decentralisation isn’t a Fire and Forget mechanic, it is necessary to close the accountability loop. To check that the localised execution decisions being made are moving the organisation towards whatever has been outline in the strategy.
How do you know whether you’re moving in the right direction? Metrics, Measurement.
Principle #5 Base Milestones on Objective Evaluation of Working Systems. Every PI the metrics should be gathered to inform the organisation of the progress that has been made. Real metrics, business measures, cold hard cash or whatever passes for value in your organisation.
Which leads us to economics.
Principle #1 Take an Economic View. Metrics, measures are driving the decision-making process. You should have an economic framework from decision making. An economic framework for decision making is a strategy for decision making. Strategy is something we might want to centralise. Provide an economic framework for how to make decisions, then empower the edges of the organisation to gather the local information to feed the economic framework.
To enable empowerment organisations should be Unlocking the Intrinsic Motivation of Knowledge Workers and Decentralizing Decision Making, to do that they need people Competent at making decisions about the things they are experts on, and they need Clarity of Vision on what it is they are trying to achieve. Through Basing Milestone on Objective Evaluation of Working systems we can measure progress towards the Vision and by Basing Decisions On Economics and providing an economic strategy for making decisions we can influence decentralized decision making whilst still empowering them to make the decision.
The Principle Cards are available free from the IJI website.
Frameworks
Figure 1: Definition Of A Framework
Framework, noun. A basic conceptional structure, as of ideas.
What do you want from your framework?
Figure 2: What Do You Want From Your Framework?
Images adapted from “Inno-Versity Presents: Greatness by David Marquet”
Innovation and collaboration with less bureaucracy or Instructions and Compliance with more bureaucracy?
If you want your people to think, replace instructions with intent.
You give intent to them; they give you intent back.
Keep One Thing
Not everything should be decentralized out. For David Marquet, the submarine captain, there was one thing that he alone had to have authority over; for him it was the decision to launch a weapon. The point where other human lives are stake, his moral and ethical responsibility.
What does your organization need to retain control over? What can’t be negotiated, can’t be decentralized. Every organization needs just enough common practice and structure to make things work and provide alignment, transparency, flow and frictionless governance.
Image from Henrik Kniberg
Scaling Agile, Lego and Spotfiy
A Minimum Viable Bureaucracy
I can imagine that some of you are already bristling at the mention of the B word, Bureaucracy.
“Bureaucracy is bad,
we don’t want no stinkin’ bureaucracy.”
Fine. No bureaucracy, no structure. No problem, the wage bill will be paid when someone gets around to paying the wage bill…
Oh, you wanted to be paid at the end of the month, did you? You want that little bit of bureaucracy?
Bureaucracy, process, of itself isn’t bad.
Too much bureaucracy is bad because it constrains things such that there is little time for doing the work and no scope for evolution or change.
Too little bureaucracy results in chaos, nobody has a clue what’s being done, how it’s being done or what anything actually means.
There is a precarious balancing act that organizations face, hovering between chaos and constraint. It’s another U-Curve style optimization, neither extreme is right, you, your organizations, have to find the sweet spot in the middle that is right for you.
Ideally any Minimum Viable Bureaucracy needs to promote your intended culture, i.e., lean and agile, provide focus to allow people to made decisions quickly thus reducing latency. Enable experiments and empiricism, allow us to eliminate waste. It should implement a common language so that when we talk, we all know what we’re talking about and it needs to encompass the whole organisation.
Figure 3: Minimum Viable Bureaucracy : Scaling Up Means Scaling Back
For most organisations the bureaucracy that is currently running the organization isn’t the absolute minimum necessary to keep the organization viable and functioning.
If you want to scale up whilst empowering your organization to move fast, you need to scale back on the bureaucracy. Replace centralized control with intent and close the accountability loop to ensure that everyone is moving in the right direction.
Regulatory, compliance concerns. Centrally all you need do is to say “don’t forget about it!”, which empowers the pieces of the organization to work out how they’re going to address the relevant concerns, then close the accountability loop and check that they have.
Within an organisation are a set of non-negotiable, universally applicable things.
Figure 4: Minimum Viable Bureaucracy : Less Than The Frameworks
Values and Principles are always greater than Practices. The Principles are fundamental truths, universally applicable, regardless of framework or practice.
A common vocabulary and the Minimum Viable Bureaucracy also need to be part of that set.
SAFe is huge collection of suggested processes and practices that you could potentially do, dependent upon circumstances. It hugely beneficial because it gives organisations a starting point for adoption so that they don’t have to evolve the understanding and ways-of-working for themselves from first principles; a task potentially beyond the expertise of organisations that are steeped in historic management practices.
The Minimum Viable Bureaucracy is less than Essential SAFe.
It has to be. The Minimum Viable Bureaucracy is the things that cannot be changed, where teams are not empowered to evolve and adapt, it has to be as small as it possibly can be. Within Essential SAFe, whilst Scaled Agile would assert that you have to be doing all of it to claim that you’re doing SAFe, there is still plenty of scope for evolution and customisation. You can even evolve away from Essential SAFe, just don’t claim you’re doing SAFe when you’ve now moved onto something of your own invention and don’t blame SAFe if what you’ve invented goes wrong.
Through all of that evolution, this way and that, the Minimum Viable Bureaucracy must still hold.
So what is the Minimum?
Establishing A Minimum Viable Bureaucracy
Every organisation is going to be unique, but there are some basics that need elaborating upon to describe any given organisation.
- Alignment through Time-Boxes and Shared Goals: Alignment is a Core Value, Time-Boxes are Principle #7 Cadence and Synchronisation, and Shared Goals are the Intent from SAFe Principle #9 Decentralise Decision Making.
- Transparency through Standard Backlogs and Practice Independent Measures: Transparency is another Core Value
- Collaboration through common roles and responsibilities: Collaboration is a fundamental part of working as part of a team, be it a single agile team, or as part of a massive corporate entity.
- Empowerment through Autonomy and Experimentation: Autonomy is contributor to SAFe Principle #8 Unlock the Intrinsic Motivation of Knowledge Workers and comes from adopting SAFe Principle #9 Decentralise Decision Making. Experimentation is SAFe Principle #3 Assume Variability, Preserve Options, which needs SAFe Principles #4 and #5 to make it work and allows SAFe Principle #2 : Apply Systems Thinking.
It’s all very well to say that it enshrines the Values and Principles but what does this look like in real world terms:
Alignment through time-boxes and shared goals
Figure 5: Alignment through time-boxes and shared goals
Everyone in the organisation is operating to the same synchronised cadence.
Line up the Planning Intervals and Iterations within them.
Every team or train produces a set of objectives for the Program Increment. Agile Release Trains do this through PI Planning, smaller independent teams won’t need the large formal ceremonies but they do need to produce the objectives.
The objectives allow every team or train to assess themselves at the end, did they meet their commitments, and from that retrospectives can inspect and adapt.
Transparency with Standard Backlogs
Figure 6: Transparency with Standard Backlogs
Common artefacts, in standard backlogs.
Everyone knows what a Feature is, everyone knows how to format one so that they can get a request into a team or train. If every team had different backlog items would anyone know what item had to be created in order to negotiate work into a team?
Standardising the representation of the work isn’t standardising the process by which a team or train does the work; teams and trains must have freedom over how they do the work because different teams and trains face different challenges and will need different processes and tools to address those challenges. A data analytics team is going to have a very different process from embedded software development which is going to be different from a marketing team.
Even single team setups can benefit from Features describing the releasable points and Epics describing the over-arching business change and how it is being measured.
Transparency through Practice Independent Measures
Whatever measures the Minimum Viable Bureaucracy is tracking, they need to be independent of the practices because as we’ve just described different teams could be using wildly different practices and processes.
Release of Value tends to be universally applicable, software, hardware, even more business orientated teams. That would be the first thing to track and it’s in line with the goal of lean “Value in the shortest sustainable lead time” because it’s tracking value. Deployment, Completion, tend to be fairly universal, but they’re further away from the goal.
Release of Value checks that it’s been produced, it doesn’t validate whether what’s been released is actually valuable, so track the Business Outcomes and KPIs. Business Outcomes of Epics or related to Strategic Themes, these are true measures of the business therefore universally applicable.
The tooling can help track contributions from one item to another, Stories to Feature, Features to Epics, progress being made. Insight into what is being worked on. It requires discipline to ensure that data within the tooling is consistent, inconsistent data and your governance is based on lies.
Focus on the right level. We’re discussing Organisational Governance, we care about Business Outcomes on Epics and the metrics attached to Strategic Themes, they are affected by Release of Value so metrics around released Features can be useful. The rest is for the levels to use for their own understanding and improvement.
Collaboration through Common Roles and Responsibilities
Common roles so that we know who to talk to to get information or to get things done.
Who do we need to talk to to negotiate work into the team, or train, through standard backlogs?
Who do we need to talk to to find out what the team, or train, has been doing through practice independent measures?
Consistency across the organization reduces frustration, misunderstanding and delays.
Common Language
Most underlying artefacts within the scaling methodologies are similar, but some people are going to have to accept that their methodologies preferred choice of name might not be the one chosen.
SAFe’s Definition are arguably the most well defined and described, particularly with respect to how they interact with each other at Scale. For the Work Items it’s Epics, Features Stories, for the Agile Team roles and responsibilities it’s Product Owner, ScrumMaster and Team Members, for the Agile Release Train roles and responsibilities it’s Product Manager, System Architect and Release Train Engineer.
A rose by any other name would smell as sweetRomeo and Juliet,
William Shakespeare
It is tempting for organisations to invent their own words, but latching onto one of the methodologies is preferable since when staff search the internet they’ll get a reference page, whereas if it’s an organisations own words they find anything, or they’ll find a page that matches the organisations chosen name but then describes completely the wrong thing.
Funding
The principles and minimum viable bureaucracy are all very interesting out what about Funding and Reporting?
Fund Development Value Streams
Fund Development Value Streams. They get the cash, they use it to employ people to create capacity to do work.
Figure 7: Fund the Development Value Streams
The challenges of changing to Funding Development Value stream have already been discussed in the first article. In summary…
Changing the financial processes might only be possible at the point where the funding is decided for another year, so make sure it goes to the Development Value Streams rather than the work.
Transferring the funding away from the work means that those accountable for the work, lose the authority that the money granted them. They now have to argue each piece of work, each Epic, each Feature, in terms of how valuable it is to the organization as a whole and will have to accept that not everything is necessarily going to be done, other work might be more important, more valuable.
Intent
If you want your people to think, replace instruction with intent.
You give intent to them, they give you intent back.
Vision
Providing the intent to enable empowerment is the Portfolio vision. Only an organization, will know exactly what it’s vision is, but it is possible to illustrate some of the qualities of what makes a useful vision from a general perspective.
Figure 8: Set the Destination, not just a Direction
Southern England, London.
There is a vision, and that vision is Go West, where the skies are blue.
However, direction alone is not enough.
“We want to be better”, “We want to be more profitable”, Whilst they provide insight into the direction that the organization wants go, it’s not enough, how do we know when we have got there?
Go West doesn’t provide a destination.
Reading, Swindon, Bristol, these are destinations indicated by the flags. They’re all in the right direction, they’re all West of London. They give us a target point to aim for, a target that we can measure how close we are getting to. They are more concrete.
Be ambitious, the target is Bristol, shown by the yellow flag.
Is that enough for a vision? Maybe the target point is enough, but maybe how Bristol is reached is important. What are the qualities of the solution the organization is empowered to come up with?
If the quality desired was speed, then the fastest driving route from London to Bristol is the M4 Motorway1 shown in red.
If the quality desired was picturesque towns and villages, passing through several millennia of history, then the old trunk road, the A4 might be more appropriate. It might not be as fast, but with the top down on a convertible and a warm sunny day, it’s a lovely drive.
If you didn’t care for driving you could take the train; 150 years ago a man in a stovepipe hat neatly took care of that2.
There is a set of options3.
Don’t impose a solution through the vision, but provide the insight to empower people to make sensible decisions.
| Set the target, the destination : Real World Example |
|---|
|
A colleague has been working with a global food packaging manufacturer. The direction they’re heading: less plastic. To become a target that needs to be quantifiable, the direction turned into a destination: Zero plastic in their packaging by 2030. The destination is a target that can be measured and progress towards tracked. |
Epics
If an organisation knows where it is and where it wants to be, as defined by the current and future vision, then there is a delta. The work item, the change requests to change the business, is an Epic. It provides the Intent for the change, it enables empowerment not specifying a solution, but instead providing a set of measures in the form of Business Outcomes and Leading Indicators, to allow everyone to assess whether the change being enacted is successful. The Business Outcomes are true business measures; they should be independent of any development practices.
Figure 9: Epic Feedback Cycle
The staff within the Development Value Streams negotiate with the Epics Owners and create Features in their backlogs that they think will move the Business Outcomes on the Epic in the desired direction. Features are change requests for the system or solution. These should be problems for the team to solve, if they are then you create empowerment at the team level for them to decide how to solve the problems.
Standard Backlogs containing Features, Common Roles such as Product Manager, everyone knows who to talk to and what they’re talking about. As Features are released the changes made to the products, the solutions, should influence the Business Outcomes within the Epic and that informs the Epic what features it should be negotiating next to keep the Business Outcomes moving in the right direction.
Guardrails
We Empower Teams and Trains to put their own work onto their backlogs. Guiding them are the Guardrails, rules about where their time, effort, money should be spent.
The guardrails are great, but they are just guidelines. How do we close the accountability loop? How do we know what the teams and trains are doing?
The Investment Horizons Guardrail is better applied across the Portfolio as a whole, the two that can apply directly to trains and teams are Capacity Allocation and Approve Significant Initiatives (Epics). You’ll need insight back from the Trains and Teams after each PI Planning about how close to the agreed allocation they were. Don’t expect perfection, if you get a 28/72 ratio back when you requested 30/70 ratio, then I would suggest that they’re honoring the intent of the guardrail and be done, be sensible. Teams and Trains also need to reserve some capacity to do their own work, don’t expect absolutely everything in the plan to be linked to Approved Significant Initiatives, the approved Epics, again have they been sensible have they honored the intent.
Management Engagement isn’t really a guardrail at all, but a reminder to the leaders of the organization to get involved…
Reporting
Through the vision we’ve set a target that we’re aiming for, now we need metrics and measurements to give us insight into how close to that target we are. From our discussion about Minimum Viable Bureaucracy, we know these want to be practice independent measures, to allow the teams and trains freedom of choice to evolve their own processes.
Practice Independent Measures
Which brings us to the subject of OKRs, we have to talk about OKRs because everyone is talking about OKRs. Google does OKRs and Google are successful, therefore if we do OKRs we will be successful too! No.
Google are successful because they discovered they could monetize Web Searching by selling Advertising Space in amongst the search results. That money pump funds the rest of the organization to continually explore and experiment, searching for “the next big thing”. Most experiments aren’t successful, some make it to be products, but I’ve not yet seen anything that matches the advertising revenue.
OKRs are useful, but they are not a magic bullet, they won’t make you successful they are just a tool for conveying what the organization is trying to achieve. What makes OKRs better than the Management By Objective that came before is twofold, firstly the Key Results provide insight into how the Objective will be measured, therefore both parties can see how close the Objective is to being achieved. Secondly the Objective and the Key Results should be negotiated, there is discussion over what they should be. That the recipient of the objective is involved in the setting of the objective, rather than just have things imposed upon them, means that they will be more likely to accept the objective and attempt to complete it and that the objective is sensible and achievable. OKRs should be pushing at the boundaries of what’s possible, aspirational, but they still need to be sensible, there needs to be some route to achieving them. If they aren’t sensible, if there is not a route to achievement then they’ll be rejected at the outset and won’t even be attempted, individuals quickly work out why bother investing effort into something that can’t be done.
When President John F Kennedy set out his vision “We choose to go to the moon.” the underlying rocketry technology was sufficiently advanced that is should be possible. Easy? Hell no. President Kennedy even said “We choose to go to the moon in this decade and do the other things not because they are easy, but because they are hard. Because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we’re willing to accept.” The vision set gave purpose to the work of thousands of engineers and scientists across the United States of America and beyond. OKRs are there to measure the changes you wish to enact. The measurements give insight into progress towards the target. The measurements need to be gathered continually, maybe Iteration by Iteration, certainly every PI to inform and steer the work being done within the PIs.
KPIs, Key Performance Indicators, are there to measure whether the system, in our case the organizational system of people and processes, is running within acceptable bounds. These need to be measured continually to track changes in the KPIs and if they are getting too close to those acceptable bounds then changes need to be initiated to bring them back within bounds. KPIs are measured continually, probably not millisecond by millisecond, but Iteration by Iteration, certainly every PI since it’s the PI cadence that allows us to enact any necessary changes. Outcomes, business outcomes, are Practice Independent
Practice Independent Measures - Flow
Figure 10: Feature Lifecycle
Flow. But…
How can you measure if the processes are evolving?
How can you measure when teams use different processes?
Separate the state of an item from the processes used to change the state of the item. The states are stable, they are universally applicable, they don’t evolve. Different teams or trains might choose different processes to move the item through its states. Some state changes might require several processes, in your world maybe Accepted to Released requires testing locally, testing on staging environment, testing on another staging environment because we didn’t trust the first, testing in pre-release because someone else didn’t trust the preceding two tests, then a review board can give the final all clear to release because they don’t trust us to make decisions, then we get to release. Some of those steps are ripe for a little bit of Principle #2, Systems Thinking, and the optimization might well be to remove them. The steps might be changing but the states remain the same and the time between Accepted and Released can be tracked and the process changes should be bringing it down.
The Feature State cards you see on the slide are described in a blog post from SAFe Fellow Ian Spence, link on the slide. They’re structured according to the Essence Standard from the Object Modelling Group that provides a lightweight, visual way of describing practices so that they can be composited into bigger methods.
Practice Independent Measures – Competency
Competency – has the organization got the required skills.
This has to be Practice Independent as well. Thankfully you don’t need to reinvent the wheel, Scaled Agile has over the last few years before developing the concept of the 7 Core Competencies and the measurements around them. The Business Agility Assessments. Scaled Agile evolved the assessments to be practice independent so organizations could benchmark themselves using their old processes to be able to compare with the results after transforming. Practice Independence works for us in that it empowers the teams and trains to evolve their own processes but still be held accountable to consistent organization wide measures.
Conclusions
Figure 11: Feedback Loop
To get the best out of teams empower them to make decisions themselves, but it can’t be a free for all there are some procedural aspects the organization has to retain control over that are non-negotiable, but keep them to the minimum.
Provide the teams with a vision, a destination to aim for, and they can be empowered to work out how to get there.
Close the loop through practice independent measures, measure how close the organization is to the destination given in the vision.
If you’re interested in a deep dive into the practicalities of Lean Portfolio Management, enter the rabbit hole here.
Acknowledgments
I do need to thank a couple of people.
From Ivar Jacobson; my regular co-trainers, Ian, Keith and Marika who’ve all facilitated the value stream mapping activities as much as I have. It’s their insight and experience as much as mine that has been distilled down into these webinars.
From Scaled Agile; Rune, Odile and Beverley for hosting the webinar sessions that these articles have been developed from and Leticia in the background organizing.
#1 Interstate, Autobahn, the fast road, whatever your local translation is.
#2 Isambard Kingdom Brunel
#3 Those of you that realized that that’s a reference to SAFe Principle #3 extra points for you!