You've heard a lot of opinions about 'the most critical' or the 'core' challenge of digital transformation, innovation and agility.
You'll hear a lot more in the coming years.
Data.
Automation.
Culture.
Security.
Regulation.
Code.
Infrastructure.
They're all wrong.
They're all missing the real factor that drives change. They're missing the most important piece of the puzzle.
This is a system challenge. Your system, and the systems you collide with are always the challenge. Your system is the confluence of all those things and more.
Well, great. What do we do with that?
Shift your focus to process. The ways you do what you do are the levers you can pull. Process is the engine of your system.
What is the flow? Where is the friction?
What are the inputs and outputs? Incentives? Dependencies?
Everything else is a symptom or a byproduct.
Focus on symptoms and byproducts without acknowledging causes and systems is how we fail to build the puzzle. We'll wonder for ages why we can't complete the puzzle.
"Having a strategy suggests an ability to look up from the short term and the trivial to view the long term and the essential, to address causes rather than symptoms, to see woods rather than trees."
— Lawrence Freedman
You can build a better system by designing better processes, and the step to begin is a small one.
When was the last time you took a look at your process? Shouldn't it be something you invest in?
Why do I spend all my time on Value Streams instead of #DevOps in 2020?
I get this question often, especially since I've been closely involved in DevOps since 2011 (and before the term arose).
Don't get me wrong: DevOps isn't done, solved, or finished growing by any means!
The truth is: I have a bad habit of skating to where the puck will be, before the game has even started 😅
From tech support in my teens
To agile development
To release engineering
To infrastructure automation
To DevOps
and now, Value Streams
At each stage, the scope, complexity, and perspective has grown.
That's what I chase.
DevOps covers a broad range of complex, interesting, and valuable facets, and the community is unlike any I've ever found.
DevOps is a fraction of a business, Value Streams are the entire business. Value Streams are a fraction of the conversation, and I want to fix that.
I can't resist. 😬
I'm not leaving DevOps, but I aim to bring it further towards Value Stream thinking.
I want to raise the value, performance, and outcomes of our efforts. The big picture view provided by Value Stream thinking is where I'm putting all my chips.
For the first time in my career, I'm not looking for anything bigger.
I had the great privilege of joining a conversation yesterday about Value Stream Flow and wanted to share it here with a quick summary. We talk about Flow, Mapping and Management, as well as what's happening in the industry and coming soon
Thanks Julian for cracking us up 😂
Some key highlights:
You can start wherever you are, waiting for DevOps, agile, transformation goals to be complete first is just delaying those goals! Value Stream mapping and improvements make all of it clearer and easier
Understanding VSM is easier by understanding what it's not:
A process is just a series of steps and activities (no measurement involved, no value captured)
Process mapping doesn't show you the most valuable next action
A value stream consists of several processes, but much more detail and value
A CI/CD pipeline is just one automated process inside a value stream
Since it's already highly automated, there's little opportunity for improvement compared to elsewhere
Your biggest problems and opportunities are probably upstream and downstream from your pipeline
Flow is easy to understand if you think of a series of pipes. Pushing too much material through too small a pipe will slow it down. In a series of pipes, the tightest, most clogged or leaky ones are the problem. You have to find where the pipes are constrained in order to improve flow. You can:
widen pipes (eliminate constraints)
unclog them (remove blocks/approvals/delays)
fix leaks (distractions, handoffs, waste) in order to improve flow
among many other tactics!
Value Stream Mapping is a periodic activity (once per quarter) and Value Stream Management is continuous. You always need both.
Mapping to quickly illustrate what's happening, share visibility, highlight quick wins and define a future strategy
Management to ensure progress towards goals
Mapping is a few hours and can be facilitated by a consultant
Management can take significant time to set up and needs to be managed once installed
Mapping without management is missing that continuous monitoring ability
Management without mapping is like collecting data without any goal or strategy in place, mapping is a much easier activity that informs management strategy and reveals issues that will affect management
Management can also lack detail in manual tasks since it relies on data integration and manual activities are not often tracked
Value Stream Management in a nutshell: continuous flow optimization, allowing you to visualize, plan and respond to stream changes
We don't really have value stream managers in many organizations, but flow and productivity responsibilities are often found in Product Owners and Scrum Masters
Because this isn't their focus, it's hard for them to do a great job
Valuable metrics include:
Deployment Frequency (DF)
Mean Lead Time for changes (MLT)
Cycle Time: Time to complete a given step (CT)
Mean Time To Recover (MTTR)
Change Failure Rate (CFR)
Quality: % Complete and Accurate (%C/A)
Non-value Added Time (NVA)
What's next? Awareness and adoption
Other thoughts: Most teams struggle with alignment, recruiting, coordination and retention of staff. Value stream thinking and improvement allows you to get more from less, while keeping everyone happy and productive. Most developers spend a small fraction of their time adding value, and can’t see how friction/complexity/improvement actually affects business metrics. The value stream brings you and your whole organization valuable context you can’t get anywhere else.
I believe there is a great reason Lean and Metrics (measurement) are the only two sections in the promising Dojo Consortium playbooks that have significant progress.
If you're starting, growing or correcting a transformation effort (dojo-led or otherwise), you need to use a lean, measurement-based approach to begin a successful effort. These two: L + M are often the least discussed and understood, though they provide a foundation for everything else in the transformation. Even worse; they're the easiest ones to understand and start with!
The interesting thing about CALMS is that beyond being a helpful acronym, each focus area actually builds on the previous, if you rearrange the order.
Start small, observe, experiment, learn and iterate (Lean)
Measure your baseline and progress (Measurement)
Share ideas, progress, work, learning and success (Sharing)
Develop behaviours, patterns, incentives and capabilities for improvement (Culture)
Implement and improve systems and operations (Automate)
LMSCA
By this order, each item in the list feeds the nextdirectly and increases the odds of success.
This is incredibly valuable because it offers an opportunity for focus and direction in the effort, and provides a playbook itself. I'm giving you permission to ignore a lot of very important things. Ignore automation until you have behaviours worth automating. Collect data before you worry about what and how to improve sharing. Forget about culture until you have some behaviour and results you want to spread. Crawl, walk, run. We don't learn to crawl by agonizing over how we can go from lying around to suddenly crawling, walking and running. We iterate. Effective learning, growth and improvement is a lean practice.
The 2019 State of DevOps Report says it beautifully: "For organizations seeking guidance on how to improve, we point to the only real path forward: Start with foundations, and then adopt a continuous improvement mindset by identifying your unique constraint (or set of constraints). Once those constraints no longer hold you back, repeat the process."
Don't We Need the Right Culture to Do Anything?
I tend to define culture as 'how your organization behaves', not general values and beliefs (ethos). Believing in the change is truly the first requirement. Many organizational transformations occur despite a legacy culture. After all, we're trying to change culture as part of this effort. It's important to examine and leverage the organizational environment before embarking on this journey to ensure odds of success are maximized. If your organization is:
Hostile to change
Not incentivized to change
or otherwise hampered
Addressing and improving those conditions will take time. This is why we start small and iterate. We collect data to share success and build momentum. Even though it seems we're ignoring culture when it has such a major impact on our progress, to influence culture we need more than just ideas and plans. By starting with a lean approach and sharing measurement, we can build and direct culture intentionally through a sustainable practice.
LMSCA defines a clear path forward. The only problem is that it rolls off the tongue like bricks roll down a hill. So CALMS still has its use. 😁
If you'd like to talk further about this or otherwise maximizing your transformation efforts, I'd love to hear from you! Book a free chat with me here
When I help companies improve their value streams, the target team and I start high and dig as deep as we need to in order to reveal their unique bottlenecks, risks and opportunities. That usually leads us to examining where dependencies lie, identifying handoffs, and how teams are structured. We start with dependencies and handoffs, as two of the worst offenders when it comes to team performance and happiness. Conducting a Value Stream Mappingexercise allows us to reveal problems. From there, one of the most impactful changes we can make towards improvement is in adopting a stream-aligned, flow-focused team structure.
What I’ll be writing about can be simplified in three main points, in case you love a good gist:
Optimizing flow requires organizing work and teams to minimize friction
Reorganizing your teams is expensive, if you’re going to change, you might as well do it as clearly, seldom and simply as possible
There is a single model that can work for every team in your organization
In this series, I want to dig into various team structures with an aim towards illustrating how they provide value and flow. I’ll describe different team models, pros and cons, trends and pitfalls. To do this I will start by talking about Project-to-Product migration, a major trend that is driving these new team structures. Those structures are:
Product Teams
DevOps Teams
Platform Teams
Adopting these structures is a topic many companies are grappling with as we look to improve agility, resilience and performance. I’ll share some common pitfalls and advice to avoid common mistakes. I’ll conclude the series by looking at how to change and improve your team structure to facilitate sustained flow of value.
First, let’s look at why we’re doing this realignment towards products, and why projects are increasingly becoming obsolete in many value delivery contexts.
Project-to-Product Migration
There has been a steady shift in most organizations building software, away from project based development and towards product based development. A major turning point in common thinking was signaled by the release of The Lean Startup and it’s focus on minimal investment for maximum value and learning via continuous iteration. The topic was further analyzed in depth in Mik Kersten's book Project to Product from an enterprise perspective if you’re interested in that perspective.
Here’s a quick recap of my learning on the subject to bring us up to speed:
Projects focus on creating an outcome based on a prediction of value often far beyond our ability to forecast, and aim to deliver that outcome based on fixed costs, resources and time. This is incredibly challenging unless you have lots of prior experience with an identical effort
Projects aim to deliver their requirements, where products exist to satisfy their customers
Customers are demanding value on a more continuous basis (SaaS, subscription, cloud services, rental) rather than finite deliverables, something which iterative, sustained products are better suited to deliver
Increasing complexity and demand has diminished returns of large-scale planning in favour of just-in-time, highly contextual planning as we learn
Product development thrives in teams with high psychological safety
Psychological safety requires growth of trust, respect, comfort, domain expertise and confidence, and suffers with disruption
This is challenging in cross-functional teams as individuals come from separate disciplines and have varied incentives within the team
Project teams
Project teams are assembled and disassembled based on a single major deliverable [product/feature release, event etc]
Project teams tend to organize around functional silos which are active based on the project's phase of completion [planning, testing]
There is significant overhead and disruption incurred by assembling, changing and reassembling teams for each project (often involving the same product repeatedly)
Commonly known as Forming, Storming, Norming, and Performing
Product teams
Product teams are formed to develop and serve a product line (or distinct feature) continuously over the sustained life of the product beyond it's initial release and between milestones
Product teams tend to be cross-functional and incorporate as many functions contributing to end-to-end value creation as possible (potentially including marketing, success, operations etc)
Product teams can react to incoming customer demands more rapidly, collect learning and retain knowledge and experience within the team beyond any single delivery
Product teams benefit from increased autonomy and capability by being cross-functional and requiring fewer external dependencies and handoffs
Modern approaches
Modern software practices and environments create and foster sustained flow of value to customers and benefit from the sustained attention and support of product teams
Rather than presenting work to an assembled development team and pushing them to complete it based on an arbitrary date, a product team:
Develops customer knowledge
Product and competitive awareness
Assembles and develops capabilities
Creates and delivers value
As quickly and often as is sustainable over the long term
New thinking and practices are required to migrate from fixed price/time/staff to a focus on allocating sufficient resources to facilitate a sustained flow of value to customers indefinitely
There is of course much more to examine and explore there but hopefully that brings us to a problem of what we should aim for with product teams, how they should look and behave. More on that in a few days!
Quarterly Cycles for Value Stream Improvement: Visibility, Improvement, Acceleration
How do we get from where we are to better with Value Stream Mapping?
I saw an example recently showing how using a Plan-Do-Check-Act (PDCA) cycle can drive improvement by iterating from a current state to a future state, but what I always find missing from PDCA when it's mentioned is useful strategies for actually implementing the process.
Sure, we'd all like to Plan, Do, Check, Act as everyone recommends but tactically, what is involved? How do we plan? What's the right way to do? What should we check? How should we act to improve?
Value Stream thinking can provide a framework for putting this process on autopilot and consistently leveling us up.
Let's look at the example graph above in simpler terms to break down the process by looking at each iteration step-by-step.
Baseline
Iteration 0 - Starting with Visibility
We start with a current state assessment in the form of a Value Stream Map (VSM). Starting with a current state assessment, we can see:
Our value stream performance baseline
Risks and opportunities
From there we can form a future state value stream map (detail coming soon!) to set our vision and align on a future state target.
Compared to a typical roadmap, our future state target is directly based on our current state, and focused on what we can confidently achieve. As a result, our odds of success are extremely high.
Progress
As we progress, we can see and share improvement
As we make progress towards the future state, we can adjust tactics. Our priorities will change as we remove blockers and bottlenecks highlighted in our current state map. We stay on track by taking intermittent measurements and adjusting as we go. To further increase value, we show and share these measurements to track improvement.
Iteration
At 3 months, we remeasure and adjust
After a quarter, the team has made so much progress, we have new constraints to address. We can quickly create a new Value Stream Map to find our current issues and opportunities. Since we're familiar with the process, it goes much quicker. We're focused more on finding our next opportunity than understanding what's happening.
Improvement as a Habit
Continuous Improvement
We continue to see and share continuous improvement in the value stream, and see steady progress. If we see challenges, bottlenecks or friction arise, we know where to look based on our continual awareness of the value stream (we'll dig into that further in a later post!).
Our team grows more and more confident. Leadership and other teams can always see progress and understand the needs of the team. New members joining the team can always see where they are needed and where the team's focus and challenges lie. Team members moving on can share clear learning with other teams based on the measurable results seen in their value stream.
Life is good!
Stay tuned for a post about how Capability Mapping can highlight and address gaps in team skills that can dramatically improve performance along with your Value Stream Map.
What do you find most challenging about performance improvement? I'd love to hear more about your plans and challenges on a video call - grab some time with me at meet.visible.is and let's talk value streams!
You may wonder when it's worthwhile to examine or improve a value stream if it hasn't become a regular (quarterly) practice in your organization. Should we just do it? How can we convince everyone involved to take the time? What value stream should we look at?
Where should we dig in?
It helps to think of specific qualifiers that we can easily relate to in order to quickly get a sense for ROI, and where to start hunting for bottlenecks. One that was recently mentioned in 'the Unicorn Project' was the idea of a 'lunch factor'.
What's a lunch factor?
In short, a lunch factor is the result of asking: Who do I need to take to lunch to make this happen?
If you've had a long and storied career in business, this might resonate deeper with you than if you're new to the game, but the analogy carries to meetings, phone calls, emails, documents, slide decks, approvals etc. What hurdles stand between you and a desired outcome?
You might think this is tough to measure because, as with most things; it depends. It helps to examine specifics when doing this kind of thinking, so take each of these for a spin and see how you do:
Deploying a change to production
Adding a new test environment
Doubling your platform resources
Rotating credentials
Abandoning daily standups
In an agile, cross-functional, empowered team these activities may not require any special approvals, they may either be self-service or require a quick slack message with some context. In larger, more complex environments with departmental silos, change management overhead, etc you may have to take a few people out to lunch just to find out who to take to lunch!
Rotating credentials
If we take #4 for example: If I don't have automation around my security credentials, and I want to change a database password for instance, I may be affecting many teams/products/services with that change. I may have to convince a lot of people that this needs to be done, and now, and at higher priority than everything they were planning to do before I dropped this on them. I may end up taking 3 product owners to lunch to catch up, find out what they're working on, and somehow squeeze in my request for the change. Then I have to convince them to accept it! Add to that the time to schedule lunch, and the follow-through, and you can see how this all adds up. Doing the mental exercise (or the actual measurement) helps reveal the friction in very real and tangible terms. We now have some data to identify the value we might see from credential automation. To more clearly measure the ROI, we can now map the value stream and find out in real terms where the challenges and waste are.
I hope this test helps quickly focus your thinking on some key opportunity or risk areas. It certainly helps me! Before I dive into a complex process I first try to visualize the path to anticipate challenges, friction or where I may find a shortcut. If it seems complicated, I often start with a rough value stream map just to record my understanding, and have something to share with others.
Cheap, Quick Measurements
What other measures can we reference to see what we might find in our value streams? Emails are another great, quick data point, as are meetings, and if you're using Jira (or a similar tool) it can allow you to trace a task, story or epic from start to finish.
With that, I'll leave you with a fun thought experiment for this week: Find out how much lunch one of your critical value streams costs.
You may just find a worthy bottleneck for your next dramatic improvement.
I wanted to share an illustration of how common challenges in business, tech and the business of tech map to positive outcomes via Value Stream Definition and Design.
For many people they may either be aware of Value Streams as a concept or how they fit into improvement efforts, and this provides a high level review. At some point I'll add the 'how' - but in the meantime check out my other posts for that information.
3 factors affecting all of us right now make it a perfect time to define and improve your value streams:
It's easier than ever to get everyone in the same room and on the same page. All the circumstances and tooling are ready for remote-first value stream improvement
Your value streams are affected by what's happening with COVID-19. A map and management strategy will align your teams and boost confidence
We're all trying to eliminate waste, examine our priorities and set a data-driven course to improvement. Value stream definition and management is the highest ROI path forward to tackle those concerns
The cost of delay has also never been higher, but it's easier than you think to get started
I'd love to hear your challenges, questions, and concerns around your value streams. Grab a chat spot with me at https://meet.visible.is
Below I'm linking to 3 example templates I use with distributed teams or when time is scarce and getting everyone in a room is a challenge. These can easily be used over a conference call, slack or totally asynchronously whenever you have the time, to collect and share data about where you are, and what to do next.
WARNING: Assessment can be challenging, stressful and damaging if done without care or experience. We're evaluating and measuring here, so please be careful to frame the effort in a positive and safe context. If you'd like help facilitating one of these exercises please don't hesitate to reach out here!
Over the next few weeks, I'll be adding more content to help you use these templates yourself, but if you've got any questions please toss them in comments below or reach out to me at the link above.
Map out a process including each manual and automated step, wait, handoff and stakeholder to expose opportunities for improvement
Goal:
Automate the stream completely with minimal variation in flow - the dream is to have a process that starts, runs and finishes automatically, the same way every time
Value:
Improves visualization, accountability and collaboration - each of these can be used as assets in regulatory compliance as well as training
Consider:
Don't aim for exact science (spend less than 2% of process time on measurement, and estimate where confidence is high)
Stakeholders from every team and/or role affected by the stream should be included at least in the kickoff stage to ensure voices are heard and awareness is raised
Complete the sheet with your team or individually to get a sense of where potential issues could arise, and opportunities for improvement
Goal:
Ensure critical team functions are known, owned and supported, and team operations and responsibilities can be easily communicated to others
Value:
Improves visualization, accountability and collaboration - each of these can be used as assets in regulatory compliance as well as onboarding or
Consider:
This exercise is intended as positive transparency to engender trust and acknowledge reality in the spirit of improvement, not to scare team members or highlight failure or inadequacy
Team members may object if their full contribution isn't captured in the function list - acknowledge that this catalogue is a team learning effort and that they should add whatever they feel is missing
This exercise can be done individually or as a team - individual measurements can reveal misunderstandings or 'misplaced optimism' that could be addressed
Complete the sheet with your team or individually to get a sense of where you are relative to common high-performing patterns, and highlight opportunities for improvement
Goal:
Reveal gaps and opportunities for targeted improvement within a holistic view of your team's health and progress
Value:
Improves visibility, confidence and measurability - which can each can be used as assets in regulatory compliance as well as training
Consider:
Don't worry about where you are now! Today is your baseline, and progress will be the true measurement
This exercise can be done individually or as a team - individual measurements can reveal misunderstandings or different views that could align the team once addressed
