Don’t Blame the System!

W. Edwards Deming's taught us that, in his experience, 94% of the problems are with the system [1].  Because of this and other experience, a vast majority of the time our reaction is to blame the system. Here is the problem; systems are neither good nor bad. We utilize systems that give the output we want, we change the systems that do not give the output we want. Systems do not have feelings, they do not try to trick us, they just exist and operate. Our job is to review the systems we work within and determine if it is giving the desired output.  If not, what is the right adjustment.

Let's use the example of controlling traffic flow. Traffic lights or semaphores are traditionally used, especially in the US, to control the flow of traffic. Drivers responding to the lights and surrounding traffic conditions to control traffic flow is a system. We know how to work within the system based on the lights, we can either proceed, proceed with caution, or stop and wait for the light to change. But when we look at that system we realize that it's not giving us the output we want.   The current system has cars sitting at a red light while there's no traffic coming from the other direction, slows us down, increases potential for accidents, and (potentially) increasing our carbon output. Rather than blame the traffic light system, we need to change the system.  If the output we want from the system is improved traffic flow, improved safety, and decreased impact on the environment then we change the system accordingly.  By understanding the system’s current output, and the delta to the desired output, we can choose to change the system.

In many cases a traffic circle (in some regions called a roundabout) does make sense, so we change the system. Now we have moved the decision making to where the information is by allowing the driver to respond to feedback loops and proceed accordingly.  Approaching a traffic circle you are not looking at your gas or brake pedal, you are instead using your vision to determine how to enter the circle, and adjusting your controls (steering, gas, brakes) as you proceed.  But the reason you are doing that is because your vision is telling you what's happening in the traffic circle. Should I proceed, therefore applying gas? Should I slow down, therefore applying the brakes. This is all dictated by what we see and what's occurring within the traffic circle. We utilize these feedback loops and adjust our driving, resulting in improved traffic flow.  By changing the system, we have improved the ability to use the feedback loops that are already in place. 

In our organizations it is far too common to simply blame the system, thereby missing opportunities to improve the system.  If your organization is struggling with adapting to major changes (COVID-19 anyone?), remaining competitive, or changing the culture, be careful to not blame the system.  Blaming the system makes it too easy to say there is nothing we can do about it, that's just the way it works here. I love the phrase I learned from my friend Dan James that the 8 most expensive words in business are “because that's the way we've always done it”.  Realize that your current organizational system is not delivering the optimal value you want, understand the feedback loops that already exist within the system, and change the system to take advantage of these feedback loops for improved outcomes.  Again, systems are neither good nor bad, but it is our job to adjust systems when they are not producing the outcomes we want.

[1]“I should estimate that in my experience most troubles and most possibilities for improvement add up to the proportions something like this:
94% belongs to the system (responsibility of management).  6% special”,  W. Edwards Deming

---

The RTE As Coach

Starting your career as an RTE?  The Release Train Engineer (RTE) in the Scaled Agile Framework (SAFe®) is unlike any role you have taken on in the past.  Part facilitator extraordinaire, part process improvement guru, and part coach, the role will require you to bring out the best of these skills to serve the Agile Release Train (ART).  Many fledgling RTE’s I coach are quite good at the facilitation role, and many have the process measurement and improvement skills needed to support the pillar of Relentless Improvement.  Where many may struggle is in how to become the chief coach to the ART.  This article will try to give you a foundation to get started on that coaching journey.

Definition of Coach

According to Wikipedia (courtesy of Jonathan Passmore[1]) coaching is “…a form of development in which an experienced person, called a coach, supports a learner or client in achieving a specific personal or professional goal by providing training and guidance”. But, you say, I am not an ‘experienced person’ in Lean-Agile! That’s OK, all great coaches are students of Lean-Agile also, they just spend more time learning how to coach than their ‘coachees’. Coaching is a learned skill, especially when it comes to the Lean-Agile mindset. Many people call me an expert, which usually makes me uncomfortable. I always respond with “I just have more scar tissue than you do“. The most important aspects you will need to cultivate in yourself is a hunger to keep learning, a desire to use that learning to help others, and a transparency that says “yes, even though I’m coaching you, I won’t always have the right answer”.

Here are a couple of areas that can help you cultivate the coaching side of the RTE role:

Empathy

Understanding where people are coming from and their perspective. Do not mistake empathy with sympathy. Sympathy is feeling sorry for someone, empathy is getting down into the trenches with them to share the experience.

Servant Leadership

Servant Leadership is not meek and mild, it is bold and courageous. It is putting others first, not because of (false) humility, but because that is how you build winning teams.

Ability to find the WIIFM (What’s In It For Me)

Every person has intrinsic motivation, that built in desire to ‘do cool things’ Discovering what frightens, concerns, excites, and motivates each person is critical to engaging their intrinsic motivation and creating an environment where they can use that motivation to be successful in their own eyes as well as helping the ART move forward.

Reserving time for the Teams

You cannot coach if you don’t have time to be on the field with the teams. A good rule of thumb for an RTE is to have 50% of their schedule open (yes, block out on your calendar 50% of each day) to do Gemba walks, listen in to team activities, etc. This cannot be “when I get time”, it must be dedicated time committed to the ART.

Analogies/metaphors that matter

Many RTE’s find their ‘superpower’ is to use analogies, metaphors, or stories to help the principles and practices meaningful to the ART. Practice this skill by taking everyday life events and determining if there is a correlation to the principles or practices of SAFe ®. For example, I use the way that Google or Waze show you multiple routes to a given destination to teach Principle #3: Assume Variability; Preserve Options.

Exemplifying Lifelong Learning

You must practice what you preach. Create your own learning plan to increase your skills an RTE and make it transparent to the ART. Reading, studying, researching, experimenting, Communities of Practice, etc. are all parts of an RTE’s learning plan. Share your learning plan with others on the ART and encourage them to do the same. This is a big step towards supporting the Core Competency of a Continuous Learning Culture

Meet them close to where they are at

Many people, coaches included, state you have to “meet people where they are at”. I have found that you need to meet them close to where they are at, but there has to be some level of reaching out done by the person or group you are coaching. Think of a rope bridge across a deep chasm. The team is on the other side, apprehensive to cross. You need to meet the team at the edge of the chasm and reach your hand out to them, but they need to take the action to at least reach out to you to get their own engagement started.

Facilitate removal of impediments, don’t remove them yourself

This is a common misconception for a Scrum Master or RTE. Scrum Masters, or RTE’s as the uber Scrum Master, rarely can remove impediments themselves. What they can do is facilitate, manage, guide, steer, or otherwise encourage the removal of the impediment. Most impediments that cannot be solved at the team level require leadership or management to get involved; facilitate this removal rather than trying to become the manager to remove it yourself.

Focus Areas

The RTE as a coach will focus on four key categories, or Focus Areas:

Program

The RTE has a key role in directly coaching the Product Manager, System Architect, Business Owners and Stakeholders. The RTE should use a combination of these key aspects of the Program Team

Measurements

See the “Measurements” section of Relentless Improvement below, but the RTE is also key in finding Program Team specific measurements. Think outside the box to elements such as: effectiveness of the Backlog Refinement activities (do customer and business metrics tell us we are focusing on the right things?), engagement with the ART vision (do the teams view the vision as their own vision?) and others that help the Program Team focus on what matters, and minimize focus on non-essential elements.

Process

Process improvement is another key aspect of RTE coaching, Viewing the surrounding system in which the ART is working (the culture, practices, and expected behavior, not the products and solutions the ART is building) is a key first step. Stepping back to see the big picture is a start, but learning and applying tr

33ue systems thinking is needed to help understand the system that creates the actions and behaviors of those working within the ART. Only then can true process improvement be successfully engaged.

Roles

The RTE needs to gain a deeper understanding of each of the roles on the Program Team, from a standpoint of both the practices and process they utilize as well as the challenges and difficulties of each role. See the role through the other persons lens to better understand how best to coach them. You do not have to be an expert Product Manager or System Architect to coach them in vision, road mapping and architectural runway, you just need to help them articulate what they want and need to the ART and stakeholders.

Teams

Coaching the teams is a vital aspect of the RTE role, but it is almost always best done through other roles on the ART.

Scrum Masters

Scrum Masters are an RTE’s key vehicle for coaching the teams. Help the Scrum Master to step back and see the system they are working in and ask powerful questions to help them find improvement or coaching opportunities. A chief concern of an RTE is that they enable the Scrum Master to be seen as the coach of the team, and that the team begins to trust the Scrum Master as an ally in delivering value.  Many (most) process improvements led by the RTE are directly supported within the teams by the Scrum Masters.

Team and Technical Agility

You don’t need to be a technical wiz to coach the ART on Team and Technical Agility, but you will need to learn the basics to be effective. If you do not have a technical background search for beginner level blogs, books, etc. to learn the overview of how the technical domain operates. This is valuable to allow you to challenge the team when they are stuck on a particular mental model. Sometimes, just by throwing out “Hey, I read this article the other day about Continuous Integration when working with a monolithic application, maybe that applies here?” can break down those walls that teams create around what is and isn’t possible. If you do have a deep technical background, be careful not to give the answer to the teams, but rather use powerful questions and suggestions to gain the same objective of breaking down their current mental models or beliefs of what is and isn't possible.

DevOps

DevOps is a culture, first and foremost. Coach (through the Scrum Masters in most cases) that DevOps is not simply adding automation and CI/CD tools, but is really a culture of shared responsibility, transparency, quality and measurement. For example, the RTE can have a significant impact on the ART’s embracing DevOps by facilitating and teaching the mapping of the deployment pipeline and teaching the various aspects of the SAFe ® Continuous Delivery Pipeline. See the Value Streams” section of Relentless Improvement for more information.

Relentless Improvement

The key term here is relentless. A successful RTE is always happy, yet never satisfied. They call out and congratulate the ART on progress, but then help the ART discover that behind every Kaizen opportunity lies 2-3 more.

Measurements

RTE’s need to suggest or create measurements that will help the ART move forward, in both value delivery as well as process improvement. The RTE must help to find measurements that will help the ART improve while avoiding vanity metrics. Remember the phrase “Measure what matters”, or my preferred version “Measure what hurts”. If you are driving your car with a full tank of gas, the gas gauge is not the most important metric. However, if you are running on fumes and hoping you can make it to a gas station, the gas gauge becomes a critical measurement.

Value Streams

Key among an RTE’s skillets is facilitation and usage of Value Stream Mapping. An RTE must understand and be able to facilitate the 3 key reasons for value stream mapping (Identification, Organization and Optimization), but key among those is the Optimization. When launching an ART we use the Identification and Organization capabilities to get the ART started, and an RTE will need to continue to use these steps to optimize the makeup of the ART. But for true process improvement an RTE needs to learn how to facilitate Value Stream Mapping and learn to read the map to identify and help eliminate systemic and flow issues. This skill is critical to supporting a culture of Relentless Improvement.

Leadership

Coaching leadership at all levels of the ART is a big part of the RTE role. Remember to separate Leadership from Management. Management maintains systems, which is an important aspect of any organization, but Leadership changes systems. You will find leadership in all levels of the ART, you are essentially coaching the leadership part of the various roles in the ART

Influence to create a Lean Agile environment

A key role of a leader in SAFe ® is to create an environment where the lean-agile mindset can thrive. As an RTE you are instrumental in helping leaders see the opportunities and to influence their behavior and interactions with the ART to further this goal.

Leaders “must know what it is they must do”

An RTE must help leaders learn the basics of “what it is they must do”. Teach the principles and values, demonstrate them in your own behavior, and hold up a mirror for leaders to clearly see past their own mental models to see how they are really interacting.

RTE Focuses on the Process

The RTE should focus on the flow of value part of SAFe ®, not what value is delivered. Without this focus on Principles, Process and Practices, continuous improvement will suffer.

When an RTE becomes too involved in the actual product or solution delivered by the ART they lose focus on the process, and the process suffers accordingly. Think of a real train, it doesn’t have a steering wheel but is guided by the tracks. The RTE also does not have a steering wheel, but instead guides the ART by improving the ‘rails’ of process, supported by the principles and practices. An RTE should view their role as similar to a real train engineer who does not really focus on the actual cargo on the train but instead focuses on the predictable delivery of the cargo. An RTE encourages and inspires the Program Team to take ownership of the cargo. This does not mean that an RTE does not care about solving real business problems, it’s just that they realize their best influence on this delivery is focusing on the relentless improvement of the train itself.

Footnotes:

[1] Passmore, Jonathan, ed. (2016) [2006]. Excellence in Coaching: The Industry Guide (3rd ed.). London; Philadelphia: Kogan Page. ISBN 9780749474461. OCLC 927192333.

The Measurement Paradox

John Miller, SPCT

What is the Measurement Paradox? 

We measure what is not valuable.

We do not measure that which is valuable.

Seems kind of odd – doesn’t it.

Douglas Hubbard states this (and I paraphrase):

We measure what is simple to measure, but valueless in that it does not provide us with information having a high decision analysis value.  We choose to not measure what is valuable (it has a high decision analysis value), but is difficult to measure.  (How to Measure Anything: Finding the Value of Intangibles in Business, Douglas Hubbard)

In addition, when we have no information, we believe we need much information to make a better-informed decision.

Turns out the opposite is true. When we know little, we only need a little information to be better informed. When we know much (or we think we do) we need much more information to make a more informed decision. Read what he says about Emily and Fermi.

These are all part of the Measurement Paradox.

In addition, to me, his discussions on measurement also help me describe how this is a key factor on why 1) teams can get really good at estimating stories in 3-5 sprints (iterations); and 2) why Product Managers (along with the Program Team) can get really good at estimating Features (SAFe® usage of the word) in 3-5 PIs. Noticed I said can. They have to choose to do the estimation technique! They have to care. Or, as Yoda states, "or not".

Hubbard also states, when the estimator chooses not to care, their estimation never gets better!

Does this sound like any teams you know regarding story estimates?

When there is a team whose GACM is permanently set to zero or near zero they will claim they can not estimate.

In Hubbard's workshops he helps people learn how to estimate in the 100's of millions of dollars.

And the teams you are coaching are pushing back with

"We can't estimate this" 

"We don't know"

OR WHATEVER!

(btw - do the above with a very whiny voice and you'll hear your teams and their reasons).

In his book “How to Measure Anything” Hubbard describes how we get much better at estimating (his word is calibrated) after just 5 exercises (uses) of the same estimation system.

Kind of interesting isn’t it.

Yet, in my experience, talking about estimation of stories always gets someone riled up. Kind of like a religious war.

The Leadership you are coaching will want to understand this. Talk to them, help them understand.

Some managers just want hundreds of measures so they feel good having meetings and managing. Let them self-select out.

Want to learn more? Read Hubbard’s book “How to Measure Anything”.

Need to talk about it? Let me know, drop me a note.  John@LeaningAgile.com

Mentoring for a beer.

Kind of like me listening like a bartender does while you commiserate about things!

jm

The 3 Reasons for Value Stream Mapping

The Problem

Value Stream Mapping is a great technique to understand how an organization delivers value and allows the organization to improve this flow of value by optimizing individual steps while still maintaining a systems view.  The technique is a cornerstone of Lean flow-based improvement, however, only following the two commonly recommended steps (Identify, Optimize) falls short of the true potential when it skips the 2nd reason: Organization.  This is where the Scaled Agile Framework (SAFe®) comes in to play, as one of the core constructs of SAFe® is to virtually organize around value delivery. 

(Note: this article documents an approach that is somewhat tangential to the SAFe® prescribed approach: current SAFe® material is based on Karen Martin based thinking; map the operational value streams, find the systems, and map the steps to support those systems.  This guidance works well for understanding business process and gaining visibility, but when used for SAFe® virtual organization purposes it can lead to organizing around current functional silos.  This is due to the fact that most major enterprises have organized around their internal/external systems and subdivided around the various technologies to support that system, leading to the wasteful hand-offs, delays and conflicting priorities.  This article spells out a different pattern for using this powerful technique along with SAFe®)

The Proposed Solution

Value Stream Mapping used in conjunction with SAFe should be organized into three specific usages: Identification, Organization and Optimization, with Organization being the added step in addition to traditional Lean based approaches.

Identification

Identification is the obvious starting point, but there are ‘better practices’ around this first step.  Karen Martin defines a Value Stream as “All of the activities, required to fulfill a customer request from order to delivery (and beyond to cash received)” (2010 Karen Martin & Associates).   Martin extols the virtues of starting at a high level by identifying the actual value stream (“Rooftop View”), and then taking a layered approach to dive down into the details. 

The level of mapping we need to begin to effect change is usually somewhere between the “Rooftop” view and the In The Weeds view.  While we want to eventually understand the deeper aspect of the Tactical portion, we can start to effect change before having this full detailed view.

Dr. Allen Ward discusses the importance of focusing on Operational Value Streams.  “In Lean Thinking, Womack and Jones say that lean companies figure out what value is— what customers actually want— and concentrate on “value streams,” the connected activities that create value.  Conventional companies often get so involved in their internal organization that they lose sight of value and produce waste instead.”  “The operational value stream includes activities converting raw material into products in the hands of customers. It produces high-quality products at the time the customer wants them. Activities are value-creating when they change materials toward the products customers pay for. The development value stream includes activities running from recognizing an opportunity through manufacturing launch.” (Ward, Allen; Sobek, Durward. Lean Product and Process Development, 2nd ed. (highlights added).  This thinking is based on the Toyota concept of value being the “horizontal slice across vertical functions in an organization”. 

To illustrate this concept, think of how we map value streams in a DevOps transformation.  Value Stream Mapping is a critical first step in DevOps improvements, and yet if we were to focus on the tools or ‘systems’ at each step we would not see the true effect of bottlenecks, overloaded people, sign off delays and the like.

Identifying Operational and Development Value Streams

As a veteran of many value stream identification sessions I know all too well how this relatively simple step can really confuse and impede most organizations.  The truth is that the simpler you start this, the better.  My guidance is always to start with a stack of stickies (Post-It’s), pens, and a group of people that have a relatively good understanding of the organization and the value it delivers to its customers.  Some key points are:

·        Don’t Focus on Products: too many organizations are keyed in on the organizations products, or even worse, on their internal applications and systems.  This makes it really tough to find the true value streams.  Instead, focus on how your customer perceives the value you deliver, e.g. what problems do you solve or solutions do you provide to them

·        Identify What You Have: understand that you already have value streams, and you need to avoid the temptation to map out a future state that may be unreachable, or not even the right target.  Identify what you have, even if it’s not a pretty picture.

·        Start with The Fence Posts: What is the value you deliver?  Think of this from the customer standpoint.  A Customer Journey map can sometimes really help in this effort, as it focuses on value as perceived by your customer, and not how you envision it from the inside out.  Once you have this clarity of true value, determine the trigger points to deliver more value.  Is it a new product idea?  A new feature for your mobile game app?  These two points, the Inception and the Delivery, are your fence points to build around.

·        Avoid Writers Block: If you get stuck in an area, move on.  Very often further discovery in other areas will allow you to come back to these initial blockers.  Most Identification workshops start with creating a Value 'Pool', a brainstorm of non-sequenced stickies.  Once we get a number of these on the wall we can start to sequence.

·        Gemba Walks: you will rarely (if ever) have a small group of people in one room that understand the full flow of value in your organization.  In these cases, encourage the group to map what they know and then take a walk to observe and learn how the value really flows (“Gemba” literally means “the Place”).

Once you have sufficient clarity on your Operational value streams (in this case, less is more) you will need to identify the Development value streams, or those interconnected steps you go through to deliver improvements or optimizations to each Operational step.    This is a critical step as these Development stream steps are typically what you will organize around.   Skipping this step will lead to organizing around the processes or systems, which in most large organizations would result in the current functional silos that are responsible for the heavy waste in hand-off’s, lack of visibility, etc. 

Organization

To fully support the SAFe® core values of Alignment and Transparency, we need to be organized around true value delivery steps.  The focus on mapping out each activity or ‘process’ step in a value stream will allow us to then determine the people needed to gather together into an ART to reduce/eliminate the hand-off’s and to create true value delivery-based organizations.  Applying an overlay of the systems impact to this new organization will allow us to see the trade-off’s we are making in architectural integrity, consistency, and perhaps other issues such as system security. 

A former client of mine (Phil Purrrington, now a very successful Agile Coach) described this virtual organization concept as populating a deserted island.  To be successful, we need to bring all the people needed to create a society on to this island.  This would include construction, medical, government, food gathering and preparation, etc.  The same is true with our SAFe® virtual organizations.  In many cases we need to have people from process, legal, compliance, research, etc on the ART to deliver value end to end.  Forming our organization solely around systems will lead to a number of critical roles, skills and people being left out of the ART.  I have experienced this at many customers in the finance, health care, retail and manufacturing verticals, and it invariably leads to greatly reduced ROI from a Lean Agile transformation.

Optimization

Optimization is a critical step in the lean improvement process, but once we have our virtual organization aligned around these value delivery steps we have already eliminated a great deal of the waste in the system just through the alignment and single-purpose/single-piece-flow focus of an ART.  Continuing to re-map the value stream as improvements are made, and optimizing around the largest bottleneck, will be far more effective when the ART is truly organized around value delivery steps.

The Action

Incorporate Value Streams using the first two elements (Identification and Organization) to find virtual organizations to launch trains around.  By this early action of re-organizing around value delivery, many of the current value delivery impediments will be removed.  You can then focus on the remaining Optimization step to further lean out your delivery process. 

Lead with Purpose

I was walking through the airport the other day and a young family was walking in front of me. The father was trying to get control of a very precocious three-year-old, and the mother made a statement I thought was really powerful. She told her daughter to 'walk with purpose'. At first I thought it was kind of cute, and understood it to mean that she should respect and understand her surroundings. Those of you that know me know that one of my biggest pet peeves is when people are not aware of their surroundings (spatially aware), especially in an airport. Seeing these young parents striving to teach that to their daughter reminded me how important it is to apply it to our lean agile leadership. How many of us actually 'lead with purpose'?  How many are setting a pace and a direction where people can walk with purpose, and are spatially aware of their organization's direction?  

A client of mine (let's call her Jennifer) sent this out to her team prior to our SAFe® for Teams training.

"Shu Ha Ri is an agile adoption pattern. It is the Japanese art of mastery and often used in martial arts and a pattern I intend for us to follow as we start our SAFe journey. As with everything, there are critics with legitimate points. So, I'm going to take some liberties with the concept but still feel the spirit of Shu Ha Ri is there. I plan for us to:

1) learn from the SAFe experts and do it the way they suggest,

2) spend time practicing and mastering our SAFe practices, and

3) adjust and tweak as needed.

What will we not do (“anit-patterns”)? We will not do these three things out of order. We will not refuse to do things that smart, knowledgeable, experienced people who understand us recommend. We will not feel we are so unique and special that we can't learn from the outside world. We will not throw a recommended practice out the minute it becomes difficult or we see hints of imperfection. When the time is right (after we do 1 and 2), we will not be afraid to make changes or trust our judgement. We will not adopt a SAFe practice just because SAFe says we should do it – instead, we will get solidly educated and partner with SAFe experts and determine which ones we should adopt when. We will not throw everything at you at once (but, admittedly it could kind of feel that way at first because change can do that!).

This is very important: We will not turn our brains off and blindly do something because someone told us to. What I'm asking is that you recognize that our brains will be much better after we do 1 and 2. 😊 Don't turn your brain off...it is needed for all steps: 1, 2, and 3. Just don't forget to recognize that none of us are SAFe experts and we need to have humility and adaptability. I've been seeing it. Keep it up!!!!"

This leadership team went further.  During their first PI Planning session all the leadership wore bunny slippers (the Product Manager wears a size 15, that was a bit frightening...) to signify their servant leadership attitude.  To further quote Jennifer

"as it relates to our SAFe journey, is this:  don't be hard on yourself or others...let us try things, make mistakes, even bump into some walls.  guess what?  our soft, fluffy bunny slippers may hit the wall first and it won't hurt.  when you make a "mistake", learn something, brush yourself off, and get back into the game.  don't make it a big deal.  don't make it a big deal when others make a mistake."  

I thought this was one of the most powerful examples of lean agile leadership I have seen in a long time. Jennifer was being not meek and humble, but bold and brave, all well setting a direction without being command and control.  Servant leadership does not mean that you take a backseat. Servant leadership means that you create the right environment to allow and encourage others to move forward. Servant leadership is not mild, it is bold  brash, very often quite brave, but needs to exhibit the same sense of "walk with a purpose" displayed by this young couple in the airport, and by Jennifer and her team.

If you are in a leadership position (and that really means all of us in some way), look at how you exhibit servant leadership qualities.  Are you leading by example?  Are you creating an environment that creates other leaders, and strengthens their ability to lead?  Are you holding others accountable to the same behavior?  Are you wearing your bunny slippers?  To Lead with Purpose requires strength of character, courage, and a humble attitude that openly states "I'm learning right alongside you".

Leadership and Mentoring: What to Read Next

(Post by John Miller, SPCT)

“An investment in knowledge always pays the best interest.”  Benjamin Franklin, The Way to Wealth

“What book should I read next?” I have been asked this question many times. There is an easy answer and a much more in depth answer. The first is merely read the books in your field of knowledge others are reading. The second requires that we know enough about a person to mentor them in their own unique current place in work and in life. This requires much more in depth thinking and thus a unique answer.

“Not all readers are leaders, but all leaders are readers.” John Maxwell, Leadership 101.

In Leadership 101 Maxwell writes that we should spend 80 percent of our people development time with the 20% of the Leaders in the organization that will make the most difference. 80% of the difference. This comes out in his 4th level (of 5 levels) of leadership. By the way, there IS a difference between a Leader and a Manager. And I’ll leave that for another note to all of you.

In Maxwell’s Level 4: People Development, he states people follow you because of what you have done for them. Individually. Not collectively. This means we know each person. And we know them well. They trust us as leaders. They have become loyal, and this is reflected in their trust.


So when someone that trusts me asks for what they should read next I take their request seriously. Yet we need to have a shared understanding. A shared language. A shared vision (that is coming from me as a leader). This also means we know where they are at. What they are doing. What books they have read. What information they need next.

I was asked a question by a really smart SPC I work with today. One that is doing all of the right things. One I really admire.  It is a simple question - “What book should I read about lean budgets?”  I just knew they had read all of the articles behind the icons at the SAFe (Scaled Agile Framework) site. And I was thinking they had read that initial list of books - as all of you have, correct? So what would I recommend next?  I knew they were waiting, and as the milliseconds ticked by, I was thinking - I had to come up with an answer. Fast. So I was pretty quick to reply with the answer a question with a question technique.

Have you read, “… by … yet?”

The answer kind of surprised me as this is one of the short list of books listed in Lesson 7 – “Leading a Lean-Agile Enterprise” of the SPC Implementing SAFe class. Well it is in v4.5.1 anyway.  I told them I was surprised they had not read it, but to read that one next.  And then we had a nice discussion on what to expect to learn from this one book on lean budgeting.

My question of you is this. Are you a Level 4 Leader? Are you working with the 20% of Leaders in your organization that will make 80% of the difference?  For you to have a shared understanding of where the folks putting the framework together are coming from have you read the books on that list? And if you have, have you also read the technical books in the “Sustaining and Improving” lesson (lesson 16). As a Level 4 Leader, when you’re thinking of recommending a next book from all the books you can recommend from, I challenge you to think of these questions first.

Where is this future Level 4 Leader (and maybe even Level 5 Leader) at? What books have they already read? What books do they need to read to advance their Leadership skills?  Have they read the short list of books in the SPC training guide, or do they think the books on that list are just to have a reading list in the course materials. And if I have not, which one would my mentor suggest to them. Hmmm...  Give the person you are mentoring a call. They might have some questions for you on the next book you might consider recommending them to read.

An ending thought.

Sometime ago one of my mentors suggested to me I had no right to recommend a book I had not read myself. Since that time I have followed his advice. I recommend this same approach to you. It will rapidly advance your own learning.

A side picture of notes from my "DevOps Handbook", a book I frequently recommend.

Value Streams in SAFe: A new way of creating Lean Flow

Value Streams and SAFe® are almost synonymous.  Without the former, the latter would struggle to deliver business value.  But, since the inception of SAFe way back in 2008, we have learned a great deal about how to view these value streams, and how to organize around them to promote true lean flow of value to the enterprise.

SAFe ® Value Stream Alignment

Before diving into this new learning, let’s review what a ‘value stream’ really is.  We start with understanding our Operational value streams, which are the set of interconnected steps that we go through to deliver value to our customers.  These value streams start with the concept, or the trigger or reason for delivering the value.  For example, when a potential or existing bank customer learns they are going to have their first child they may start thinking about purchasing a new house.  The trigger is the need for the value that the enterprise wants to provide.  The steps the enterprise goes through to deliver that value successfully to the customer are the operational value stream steps, such as marketing the mortgage offering, accepting the application, processing the customer’s credit and information, and providing and servicing the mortgage.  As the customer pays off the mortgage, we get to the other side of the operational value stream, the Cash.  This term is often used a bit ambiguously, but essentially means the fulfillment of the value stream to the satisfaction of the customer and the enterprise, resulting in both the customer and enterprise receiving benefit for the value.  Very often the actual money is transferred from customer to enterprise during the value stream (not always at the end), such as when the customer continues to pay the mortgage payments and the bank receives the mortgage principle and interest, but the operational value stream continues to flow as it services and eventually closes the mortgage.

While SAFe ® can be used to assist operational value streams to deliver, the sweet spot is really in supporting the Development value streams.  Development value streams are the set of steps we go through to support operational value stream steps.  They consist of the people, systems, and processes we use to support these operational steps.  For our mortgage example, there is most likely a credit review system for the credit approval step, and a set of systems that support the mortgage servicing steps. 

A Different Way of Thinking

SAFe ® was originally designed to organize Agile Release Trains around these systems to allow lean flow of value to increment and improve these systems.  E.g. If we want to improve the Credit Review System, we would organize an Agile Release Train around the development of this system.

However, as we learn about the application of the virtual organization of an ART to deliver value, we have discovered that very often this does not promote lean flow of value.  There are many reasons behind this issue, but the most prevalent is that very seldom does a single system alone support the Operational value stream step.  There are almost always other aspects, such as Compliance, Regulatory, Marketing, Sales, Legal, Research, etc.  To promote true lean flow, we need to rethink this paradigm and focus on all of the steps needed to improve these operational value stream steps.

The new way of thinking starts with a new way of identifying value streams.  Traditional SAFe guidance helps us find the Operational value streams, then discover the Systems that support these steps, and then to find the people that support these systems.  Dr Alan Ward defined Development value streams as the set of steps we go through to Create, Update or Deprecate Operational value stream steps, and he included all steps in this process.  Applying his work and this new way of thinking we look at all steps we go through to positively impact these Operational steps, such as Business, Infrastructure, Research, Marketing, Legal, Sales, etc. 

Lean Flow

Let’s discuss a simple example from manufacturing.  If a car maker is building cars, they are using an operational value stream to handle orders, bring in raw materials, create and assemble the parts, and ship and sell the car.  In manufacturing the steps to create a part are typically called a recipe, which includes all the specific steps to heat, form, stamp, etc the material to create a part, such as a hood.  The operational value stream step already is capable of producing this hood (via the recipe), but lets say we want to improve this hood.  What are the steps we would go through to improve the strength of the hood?  To improve the aerodynamic properties?  To reduce the amount of metal used in the production?  These steps are probably fairly similar, and would require the same people: designers, metallurgy specialists, marketing (for shape), compliance/legal (for safety), etc.  These people would go through a somewhat generic set of steps to improve the recipe to create the hood.  As they design, test, review, validate and confirm this new hood design, they update the Recipe, hence they are updating the Operational value stream step.  We then repeat these same steps for the next improvement we want to make to this Operational step, such as reduce the cost of the hood, make it lighter, etc.

Software and Hardware development is no different.  The end result is still that we want to improve the operational step, and we need a variety of people to do so.  In software we typically need the people in the SDLC process, but we also need people from Legal, Compliance, Marketing, Sales, Design, Infrastructure, etc to improve this Operational step.  Hardware/Firmware is similar in that we also need the people that actually create the product, but also all the other players that are needed to actually update the operational step.  These are the people we include in our virtual organization in the ART.

The Island

While coaching this method to a past client, I had the pleasure to work with a true Change Agent, Phil Purrington.  As Phil came to understand this method, he explained it this way.  “Imagine we have a deserted island, and we need to bring all the people needed to solve similar business problems to this island.  This has to include all the skills needed because, well, we’re on an island!”  This is a great visual as we understand the importance of having all the skills and experience needed on the ART to deliver value, and not just update a system.  Having this island mentality will definitely promote lean flow!

The Tradeoff’s

While this method creates true lean flow, it does not come without it’s cost as we have to make some tradeoff’s.  When we focus an ART on a specific system we can create a high level of architectural integrity and consistency, as the same people are always updating the same system.  Using this lean flow method we lose some of that singular focus on a system, but this can be easily overcome and compensated with good architectural design (loosely coupled, micro service based systems are great ways to relieve this issue), Community’s of Practice to distribute knowledge and proper usage, and clear strategic direction from leadership for a common vision to build upon.  In reality, less focus on organizing around the systems leads to better architectural development out of necessity.

A Different Focus

The result in focusing on this wider scope is that we reduce all the handoff’s and delays created when we have to wait for legal, compliance, marketing, or other inputs.  And, after all, that’s what we really want to focus on, Lean Flow. If there’s anything that the Toyota Production System, Don Rienertsen’s work, or any other lean expert will teach us, focusing on true lean flow of value will provide significant increases in value delivery.  And, after all, isn’t that what SAFe ® is all about?