The definition of 'value stream' changed a bit in SAFe 4.0 to 4.5
Here's the current definition of a value stream from the SAFe site:
Value Streams represent the series of steps that an organization uses to build Solutions that provide a continuous flow of value to a Customer. SAFe value streams are used to define and realize Portfolio-level business objectives and organize Agile Release Trains (ARTs) to deliver value more rapidly.
I see two different ways to interpret this and am wondering how people out there (you) interpret this:
1) There is an order in which you’d like the work to go through your people and you’d like those people the work goes through be Agile Release Trains 2) There is an order in which the work actually goes through your people and those are not always these nicely defined group of people
Which do you think SAFe means when they talk about value streams?
If you saw a new engineer designing a long suspension bridge without attending to the wind would you say "let him figure it out, we're Agile and that means we trust people"? why is it different in software which is even more complex? ------- Many people thought I was making fun of Agile. I wasn't. Let's go through this. Question Would you say "let him figure it out, we're Agile and that means we trust people?" I don't know any Agilist who would say "yes." But I have heard people say this. That means anyone who says this doesn't understand Agile. So, if an Agilist doesn't say this, why is it ok in Agile to see people struggling with unknown principles? I see many people do this. I don't think it's a good idea. A good coach will ask others if they should look at. For example, if I was an engineer seeing someone not attending to wind I would ask "do you think we should attend to wind?' If they said no I'd say - "is it possible to get a harmonic in the structure?" at this point they should realize it is worth looking at.
My point is that "trusting people" is not the same as "trusting they know what to look at"
First, let's get clear. All organizations are complex. So if you're doing software dev you are in a complex system. Aspects of it also have the possibility for chaotic events (eg Martian Lander disaster).
But let's consider something necessary to consider in even simple situations. Take 2 min to watch Lucy in the Chocolate Factory. This is a simple situation. Too much work causes problems. Managing work levels is something necessary to do the job.
Is it sufficient to get quality? Maybe in this situation. But if you take the idea of managing WIP into a complex situation, it's still necessary but no longer sufficient. The point is, while complexity tells us we can't see everything, it doesn't mean that there aren't necessary things to see.
From the moment Scrum became more popular than XP, the sw dev community has been focusing on frameworks more than Lean-Agile principles. It's not surprising this has happened. It's a lot easier to understand a framework than the principles underneath them.
The challenge that occurs is when the framework becomes the goal. They are just proxies of what we're trying to achieve - the quick realization of value predictably, sustainably and with high quality.
We must remember that frameworks are a proxy to what's really important. They provide a way to start & a way to see some of what we need to do. But how do we transcend them as we learn? Lean-Agile principles are, by their very nature, abstract. This is in the same way that gravity, clearly real, is abstract. We know when we drop something it'll fall-but how fast & far & what damage it will do depends on where you are & what the object is & what it is hitting.
What's needed is a way to see what those with expertise see & provide solutions experts would consider. This enables less experienced people make better decisions. This is the purpose of a good tool. Not to follow a framework, but to enable better decisions based on Lean-Agile principles.
Culture is important but it's a reflection of decision & reward policies in a company. To be able to change it you must change the way decisions are made and rewarded. Three foundations of Lean are:
take a systems-thinking point of view & recognize the system causes most of your problems
respect &trust people
management (via servant leadership) improves the system within which people work so that they can work autonomously on a well stated objective
The challenge with software is that it is not visible while it is being built. The greatest diff between Kanban & Scrum is Kanban's insistence on explicit workflow which adds to Scrum's visibility of the work in process
An Agile product management tool's primary purpose is to create visibility of both workflow & of artifacts (epics->stories). One doesn't follow a tool, rather this visibility reflects what people are doing. If one understands lean-flow, the tool assists people in making good decisions
Good frameworks are merely proxies for good Lean-thinking. Tools designed around frameworks miss the opportunity to teach Lean-thinking. Frameworks can be good "tools" in the sense they give a good starting point - but you should outgrow them. A good tool will always be useful
Alignment is critical for Agile. The more you have the more autonomy people can have. It's what teamwork is really about. At the team level people align around the team's backlog. But what do people align around at scale?
I like Don Reinertsen suggestion "There is more value created with overall alignment than with local excellence."
All too many align around the framework itself. But they should be aligning around the objective of their framework- the quick realization of business value predictably, sustainably and with high quality. While frameworks are useful, they should be considered to be tools to get to our objectives.
So how do we align at scale? To determine that we must ask - "what are we investing in?" and "how do we best achieve that?" Many companies have already figured out the first question, but the answer is not well known to the dev teams. For example, a financial company may want to invest in:
A key tenet of Lean-thinking is that we must adopt systems thinking and acknowledge that most of the errors we encounter are due to the system. For example, consider how the geographic arrangement of dev and testers affect their work.
How to create good ecosystems is critical. How the ecosystem provides guidance to the people doing the work is often ignored. In the software world, seeing the work being done is difficult. Creating visibility of the workflow itself is critical.
What are the right transition steps to go from say an epic to a feature? How do we get consistency in this and other actions across an organization without requiring a one-size-fits all approach? A tool can readily accomplish this if it is designed to reflect the process being used and that this process is a reflection of what people consider to be the best way of working.
This requires a mindset shift combined with flexibility of the tool. The challenge is not in the tool's flexibility but in the people using the tool understanding lean workflow & setting the tool properly.
A criteria for such a tool is that their first recommended step is to understand the value stream of the organization using the tool. This is the correct focus.
Many Agile folks think of tools as a necessary evil. But they have a definite purpose and done well are essential.
Any Lean-Agile approach should start with getting an understanding of where the company is. Mapping the value streams of an organization is usually a good start. Identifying challenges in workflow and team structure is another. Only then should an adoption of a new workflow or company re-structuring take place. While it is often tempting to take solutions off the shelf it must be kept in mind that no one-size-fits all.
It is at this point, at the beginning of a tailored adoption, that tools can be used to reflect the workflow thought to be the best to be used. Here are three aspects.
How data is decomposed from strategy to stories
How the company is organized (such as SAFe with Agile Release Trains)
Improving the value stream (the work through the organization)
A good tool will enable views of all of these aspects. Examples are tailoring the tracking of data to the size of the organization, letting each level and role see their responsibilities, making visible the workflow of the value stream and the work going through it. These are ways tools provide a basis for learning how to improve.
I am often asked how to do Lean Portfolio Management. Let's consider what's needed to do this effectively. The real issue is when different programs require the same limited capabilities. How do you decide which one is more important? Weighted Shortest Job First (WSJF) is commonly used. But 'business value', a key component of WSJF, means different things to different groups.
How can we decide what the business value is when people in different divisions have different views? This is where business leadership is needed: an explicit statement of what value the company wants from its investments. If multiple portfolios are present then an explicit statement of what we're attempting to accomplish is critically needed.
Another essential aspect is what to do WSJF on. Cost of Delay needs to be on something that can actually provide value. Very often individual features are too small to do that. But doing WSJF on epics is not the right answer either. Epics are too large and virtually always have some subset of functionality that can be delivered and realize value. CoD should be on these.
We call this subset a Minimum Business Increment (or a Minimum Business Epic for those doing SAFe). These MBIs or MBEs must be tied back to the business value to be realized.
Ultimately, Agile is a mindset. But how do we get there? Consider these two alternatives:
Learning a framework A team does the following: * daily standups * has a product backlog * breaks work up into 2 week chunks and plans what they will do * attempts to build entire chunk * stops working after 2 weeks to inspect & adapt & demo what they have * has a product owner and scrum master
Learning the actual work A team knows how to take their work and slice it into small pieces with acceptance criteria they got working with their product owner. They focus on finishing Every two weeks they see where they are, demo it and do a retro. Then they plan out two more weeks of work.
Which will be more effective? Which approach will help them start operating more as a team? Which will create more resistance to having more ceremonies and more meetings? (I suggest the second will have them embrace the ceremonies of the first as supportive).
BTW- this is not a thought experiment. We've done both (but only do the 2nd one now). If you also think the 2nd is better, it's nice that it's also less expensive in time & money. Drop me a line.