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?

Quality is Management's Responsibility

Yes, you read that right.  Quality is management’s responsibility.  Most agilist’s reading that statement would spit out their coffee and then declare “But, quality is the Team’s responsibility!”.  While that statement has merit, it is far more important to have a system in place that ensures high quality, and systems building is a management responsibility.  This is one area where traditional agile thinking meets with traditional lean thinking to create the best outcome.

Wisdom from Dr. Deming

Tim Stevens of IndustryWeek magazine had the privilege to be the last to interview Dr W. Edwards Deming about management’s responsibility.  One of the first questions Mr Stevens asked Dr Deming was “What can you say to IndustryWeek's readers that they might benefit from and apply to the way they are running their businesses?”  To which, Dr Deming replied “Management today does not know what its job is. In other words, [managers] don't understand their responsibilities. They don’t know the potential of their positions. And if they did, they don't have the required knowledge or abilities. There's no substitute for knowledge.”  Dr Deming continued with this explanation “Quality is the responsibility of the top people. Its origin is in the boardroom. They are the ones who decide.”.  Dr Deming, with all his experience and knowledge, wanted to illustrate that management’s (leadership’s) main responsibility is to build a system that creates and ensures quality.

Taking a Systems View

As a manager or leader one of your key roles is to create an environment that encourages rapid delivery of the right solutions for the customer.  This requires stepping back from the traditional command and control (telling people what to do) and instead focusing on creating a system that allows people to innovate while ensuring the right level of quality and governance is applied at the right points.  This is a difficult transition for most managers and leaders that have grown up in the Tayloristic work break down structure approach.  But what really creates value is the focused system that good people thrive in, not a failing system that good people try to work around.  In short, managers need to move from managing people to managing systems. 

Applying Systems Thinking to Ensure Quality

Taking this leap towards focusing on a system that ensures quality can be a daunting task.  I have found that starting with understanding the system is a critical first step.  To best understand a system, there is no substitute for a post-its-on-the-wall value stream mapping session.  (see my blog on the three reasons for value stream mapping in SAFe ® or some of Al Shalloway’s work on this subject).  For the sake of this article, let’s assume you have gone through this initial work (value stream mapping is an ongoing exercise), and have a decent understanding of how value flows through your system.  As a manager, your challenge is to begin to understand the bottlenecks at each state in the system, but also to understand how each state ensures Percent Complete and Accurate (%c&a).  One of your key objectives in applying systems thinking is to increase this %c&a at each critical transition or hand-off.  Definition of Done is an important tool to assist in this critical task.

The Importance of DoD in Increasing %c&a

True quality comes from a system that encourages transparency along each step of the process and incorporates the Andon chord approach to determine when/if to halt production when an issue is found.  In many cases the Dev Team does not have visibility or ability to change these systemic issues, but management can and should.  Using a clear Definition of Done (DoD) at specific points is a critical part of the quality system.  DoD’s are not checklists that we mindlessly go through, they are living contracts between teams, PO’s, PM’s, and the rest of the ART and its stakeholders as to our quality and accuracy validation.  If you are working in a scaled environment, the SAFe® recommendations on Definition of Done are a great starting point to improving the system to achieve Built In Quality. 

DoD is Measured at each Increment

In SAFe®, DoD is purposely used at various granular levels.  The team meets the Team DoD to ensure that the value added is worth demonstrating and reviewing.  The System Increment DoD ensures that it is integrated into the system and is worthy of Release consideration.  And the Release DoD ensures we have met our customer readiness and impact standards and are ready to put it in front of the customer.  Each Definition of Done is essentially asking “Are we done enough to go to the next state?”, which is a key part of our quality control to ensure our %C&A.

It is hugely wasteful to meet Release DoD on a story that may never be in the customers hands.  As Peter Drucker said "The worst thing we can do is do something well that should not have been done at all".  We increment towards a true state of ‘Done’ (in the customers hands and they are happy) through a set of ever expanding DoD increments.

The System needs to work even if a critical person is out.  Just because Dinesh is out sick today should not mean we have lesser quality that day.  The system should have its checkpoints that ensure that we are still following our agreed upon contract with the next step to consume the value.

Managements Role in DoD

As already stated, far too often teams are held accountable for quality when they have little to no ability to change the system that should be ensuring quality.  Agile teams are described as Self-Organizing and Self-Managing, but as described in another post, teams are not really self-managing.  We need management and leadership to provide teams with solid systems to work within, and these systems need to be built to deliver and ensure quality.  Built In Quality Is not just a phrase on the SAFe® Big Picture, it is a way of working and thinking that ensures quality at each step.

Iterative Growth on DoD

Building a DoD is not a one and done.  We need to start with a set of validations that we believe to be correct, measure the outcomes using this set of validations, and then iterate on the set.  We will almost certainly not get it right the first time, only through inspecting and adapting will we get to a solid set of DoD’s.  One good way to ensure that we are iterating on it is to capture any exceptions we deal with and determine if the DoD needs to be updated to prevent in the future.  E.g. If a system issue slips by our current DoD and into the customers hands, is there something missing from the DoD that would have caught this?  Whenever we are in crisis “it has to be fixed yesterday” mode we have to also capture the underlying data that allows us to improve the system once the crisis is over.

Footnotes

(1) Percent Complete and Accurate (%C&A).  A quality metric used to measure the degree to which work from an upstream supplier is determined by the downstream customer to be complete and accurate (or error free).  https://www.ksmartin.com/lean-terminology/

Crossing the Chasm with Scaled Agile

Like any successful business, Scaled Agile Inc. Has 'Crossed the Chasm' from Innovators, through Early Adopters, and has moved into the mainstream Early Majority stage. 

https://dwaynenesmith.com/book-review-template/

As experts like Geoffrey Moore and Ash Maurya pointed out at last week’s SAFe® Summit, it takes different leadership models to navigate your business in these different stages.  The 2018 SAFe® Summit pointed out just how well the Scaled Agile team is adjusting to this growth.

The week started off with the SPCT (SAFe® Program Consultant Trainer) session on Monday, where the SAFe® experts gathered to teach each other the subtle but significant changes to version 4.6.  The session capped off with an Epic generation session based on an SPCT view of the needs for 2019 and beyond.  The next day these ideas, focused on furthering the quality and effectiveness of training and the impact of SAFe® beyond the typical IT Systems Implementation, were presented to the partners for input and voting.  This is a great example of a company listening directly to its customers and key stakeholders. 

The release of version 4.6 was highlighted by the 5 Core Competencies: Lean Agile Leadership,  Team and Technical Agility, DevOps and Release on Demand, Business  Solutions and Lean Systems, and Lean Portfolio Management.  Each of these competencies highlight new learning and application of that knowledge to the framework.

https://www.weforum.org/agenda/2015/04/how-should-disrupted-businesses-plan-for-the-future/

The main conference was highlighted by Geoffrey Moore's great keynote on the 4 zones, and further illustrated how Scaled Agile is supporting the current body of knowledge with the existing framework (zones 1 & 2) while looking to the future (zones 3 & 4). 

In short, this is an exciting time to be part of this community.  It feels like we have come a long way already, but the week further highlighted how much more there is to learn and apply.  It was clear to me that Scaled Agile Inc has their Profit motive firmly moored to their Purpose motive.  Exciting tines indeed!

A New Take on The 3 Questions

The ‘typical’ pattern of a DSU is focused on the 3 questions: What I did yesterday, What I plan to do today, and any Impediments I am facing.  Over emphasis on these 3 questions can easily kill agility and lean flow.  Here’s why.

What I Did Yesterday

This is far too often treated as a status report to the team, “I finished Story xyz” or “I’m still working on Story XYZ”.  Sharing this information is negating the value of collaboration outside of the DSU.  As a team we should be continuously working together through various best practices such as Pair Programming, limiting WIP, co-location, and transparency, that going into the DSU we already know what the others on the team were working on.  (Limiting WIP, which results in swarming on highest priority stories first, means there’s a good chance most/all of the rest of the team were working on the same story!) .  As a Scrum Master, you should be looking for this type of status report approach as a sign that the team is not really collaborating during the other 23 hours and 45 minutes since the last DSU.  This provides a great opportunity for process and team improvement, which is the core responsibility of every Scrum Master.

A better approach is to discuss what we did as a team yesterday.  A good practice is to review the team story board (or Kanban board) and have a general discussion on the highest priority stories that are in flight or soon to be taken on.  What have we learned about these stories?  What issues remain?  My personal advice is to change this first question to “What did we accomplish and learn as a team yesterday?”

What I Plan To Do Today

This is another area where we can far too easily create a team of individuals, rather than a true team working towards the same goal.  The plan for today (the next 24 hours on the Scrum diagram) needs to be a team plan, not an individual plan.  Understanding where we are at as a team towards Iteration Goals (and Team Objectives when working in SAFe®) is critical information.

Using a North American Football reference (the NFL in the USA)  is a good way to understand this concept.  When an NFL team runs an offensive play, attempting to move the ball down the field or potentially score points, after the play they all have a clear idea of how well the play went.  When they return to the ‘huddle’ (players gathered together in a circle to discuss what to do next) after the play, they only have 45 seconds to run the next play, so they don’t take a significant amount of time to discuss how the last play worked.  They all know if they gained yardage, if the play was successful, etc.  There may be nuances that are important (one player to another: “I was open for that play”) that are shared, but it quickly focuses on what to do next.  Was the last play a run?  Was it successful?  Let’s run the ball again!

A DSU is very similar to an NFL huddle.  The team should get back together and should already know how the last ‘play’ (the last 24 hours effort) went, and what the result was.  The DSU can then quickly focus on the best plan for the next 24 hours (or until the next DSU).  My recommendation for the second question is “What is our plan until the next DSU?”  This can include things like “Dinesh, can you pair with me on this part of the effort?”  “Dave, I’m going to need help with this test scenario, can we start right after the DSU?”.  A clear sign for a Scum Master that the DSU was effective is that the team has a shared plan walking out of the DSU, and each team member knows how they are going to contribute.   If this is not happening it’s another opportunity for team process improvement.

What are my Impediments?

This third area is also critical to keep at the team level, rather than an individual level.  The true concept of a team means that if one has an impediment, the whole team has an impediment.  Going back to the NFL huddle concept, if a wide receiver knows that the next play called means they are needed to run a deep route of 80 yards, and they just ran 80 yards and are too winded to complete this, they let the team know this isn’t the right play to run.  They share the impediment with the team, and the team takes on the impediment as one.  This is the same for an agile team; when there is an impediment for one it is an impediment for all, and it needs a team solution.  This approach is carried out in so many other scenarios, such as the military, but we tend to shrink away from this when it comes to agile teams.

My recommendation on this third question is just a bit modified, and then extended.  “What impediments do we have to our plan?  What can we do to adjust our plan to compensate or mitigate the impediment?” 

The End Result

Following these simple changes results in a DSU that is team focused, identifies improvement issues, and creates a collective ownership approach to planning and overcoming impediments.  Collaboration is critical amongst an agile team, but during the DSU the shared input into a new or adjusted plan until the next DSU is even more important.

Understanding the Components of Economic Sequencing (WSJF)

Weighted Shortest Job First, or as I like to call it, Economic Sequencing, is a critical tool in properly focusing on the right problem to solve next. Far too often I work with executive leadership teams to discuss their strategic goals, and they give me a list of around ten ‘priorities’. My job is to help them understand that if you have 10 priorities, you have no priority. (The word Priority was never pluralized until around the late 18th century, it’s based on the Latin ‘Prior’, meaning first). Having that one key business initiative, with the other initiatives being clarified as ‘Important, but not the priority’ is critical to limiting Work In Progress (WIP) and delivering real value. Without this clear sequencing based on projected economic outcomes we end up working on too many things at once, and delayed or prevented delivery on the most important thing.  Don Reinertsen’s work (among others) has shown that we get more done in the long run by focusing on one thing at a time.

WSJF in the SAFe® world utilizes proxy values for the Cost of Delay measurements that Rienertsen advocates.  (Note: Outside of the SAFe® world this is typically referred to as CD3, or Cost of Delay Divided by Duration).  These 3 CoD factors, User/Business Value, Time Criticality, and Risk Reduction/Opportunity Enablement, are very often confused or misunderstood, resulting in watered down impact of the process. I’m going to use the analogy of a sail boat to help illustrate these three elements.

Here’s the scenario.  We have a sailboat that we want to sell to a customer, but it has some issues.  The paint is peeling, the motor needs work, and there is a leak in the hull that we have yet to find.  Which problem should we correct first?  Let’s use relative sizing with modified Fibonacci to determine the CoD factors for this effort.

Let’s start with the User/Business Value (UBV) aspect for each effort.  Looking at the boat peeling in the sun, it doesn’t look very pretty, so we probably say that the Paint initiative is our highest issue.  But, what’s our lowest UBV?  Probably the motor, since the motor does run, so let’s assign that our 1.  Looking at the other two items relatively, we then decide that the Leak effort is probably a 3 since it’s causing the boat to settle lower in the water.  Based on how bad the paint looks, we are putting the Paint effort at a 13.  So we now have, in relative UBV ranking, Motor = 1, Leak = 3, Paint = 13.

Time Criticality (TC) is one of the confusing ones for most people, as they tend to think only of deadlines.  The truth is, unless you are building systems that have to align with the lunar cycles or other unchangeable events, deadlines are created by someone, somewhere.  We have to look at time criticality as the loss of potential value over time more than by deadlines, as that is the true impact to ability to deliver the most valuable thing first.  So, where do our 3 initiatives fit in with TC?  Since our motor is running now, and we believe it will continue to run, we are going to put this as our 1.  This does not mean it has no time criticality, only that of our given opportunities it has the least amount of TC.  The paint is peeling, but we are not in the rainy season, so our TC for Paint is relatively low at a 3.  However, the leak is getting worse, and we can’t fix a motor or paint a boat if it’s on the bottom of the ocean, so our TC for the Leak is 13.  The potential loss of value increases greatly the longer we delay.  So, our TC is Motor = 1, Paint = 3, and Leak = 13.

Last comes the Risk Reduction and Opportunity Enablement (RR/OE).  These two elements work well as a combined value since rarely are we able to reduce risk and open new opportunities at the same time.  Risk Reduction increases when we see an opportunity to lower a potential risk to the enterprise or the customer.  In our case, the risk of the Leak is greater than the risk of the Motor failing, but both are relatively high concerns. The Paint has little risk, and while there is an opportunity for increased margin on the sale of the boat, based on greater interest and competition among buyers, it is still our lowest RR/OE value.  Based on this understanding, we are assigning RR/OE as Paint = 1, Motor = 5 and Leak = 13. 

eater than the risk of the Motor failing, but both are relatively high concerns.

Now we can add these proxy values up to get to our forecasted Cost of Delay. 

Paint = UBV (13) + TC(3) + RR/OE(1) = 17

Leak = UBV(3) + TC(13) + RR/OE(13) = 29

Motor = UBV(1) + TC(1) + RR/OE(5) = 7

This tells us that our greatest cost of delay is in not fixing the leak, but it still doesn’t tell us which one we should focus on first.  We have to add in the cost of implementing these initiatives to the equation in the form of Job Size (JS).  This is also a relative number based on our understanding of the complexity of the effort, the uncertainty of the solution, the knowledge (or lack thereof) in the issue, and the over amount of effort and complexity.  Since we are familiar with the process of stripping the paint, prepping the hull, and repainting, but it’s a fair amount of work, we are thinking the Paint would be the largest job size.  The Motor should be a simple fix, but due to our lack of mechanical skills, the Motor has a great deal of complexity, so we are thinking this falls some just below the Paint.  The cause of the leak is readily apparent, and does not seem too difficult, so it’s our lowest job size.   That gives us a Job Size of Leak = 1, Motor = 5 and Paint = 8.

Applying the Weighted Shortest Job Size equation of WSJF = COD (UBV + TC + RROE) / JS results in this ranking:

Leak = CoD(29) / JS(1) = 29

Paint = CoD(17) / JS(8) = 2.125

Motor = CoD(7) / JS(5) = 1.4

This clearly tells us (by a wide margin) that despite how bad the boat looks, the first thing we should focus on is the leak.  It may be hidden from view (eg. Technical debt, architectural or infrastructure needs) but focusing on the Leak first will result in the greatest economic outcome.  This type of data can greatly help with the typical ‘prioritization’ methods that usually result in HiPPO decisions (Highest Paid Persons Opinion), and instead use localized information to create the greatest benefit.

Don’t Blame your Failed Transformation on [insert lean agile framework here]

As a SAFe® SPCT I work with a number of large companies with an end goal of transforming the way they work and think to gain the advantages of Lean and Agile in their enterprise.  Their burning platform is usually the same, “we need to deliver faster than our competition, with better quality, and reduce our costs”.  Sometimes we are successful, but many times we are not, and the underlying reason is always lack of leadership engagement.  I work with a number of top notch coaches and have learned that they have had the same experiences.  The problem isn’t the framework (I’ve seen it work too well too many times for this to be the case), and the problem is rarely logistical or physical constraints.  The underlying issue is always a missing focus on creating a better system.

In your enterprise you have two (at least) common systems; the systems you build for your customers and the system you use to build those systems.  This enterprise system consists of your culture, environment, organizational structure, value streams, constraints, etc that create the environment that allows you to deliver value to your customers (the other systems).  The major problem I have seen is that leadership in most large companies tend to view any lean agile framework, be it SAFe ®, LeSS, Scrum, etc as a panacea, the magical prescription to solve all of their systemic problems.  There tends to be a perception of “Hey, IT, go do that [framework] thing so you can deliver faster and cheaper”.  None of the current frameworks will directly create a new system for you, that’s up to you.

One of the reasons I am such a believer in SAFe ® is that it is a big spotlight.  Applying the principles and practices of SAFe® will not solve many of the systemic problems causing your quality or delay issues, but it will shine a very bright light on the source of these problems.  Visibility is key to improving your enterprise system, and the strategic alignment, cadence and synchronization, and inspect and adapt practices will provide a great deal of transparency and understanding to the true root cause of your systemic impediments.  I am not well versed in many of the other frameworks, but I believe this increased visibility to be a natural artifact of these as well.

Here’s where we start to fall down, as I tend to see one of two leadership patterns come out of this visibility.  The first is to blame the framework.  “We never had these problems before we implemented xyz, cancel xyz and try something else”.  If you are driving your car and hit a tree, we can’t blame it on the car or the tree.  The car, like the framework, has principles and practices of operation and needs maintenance and attention.  If you ignore these, bad things will happen.  The same holds true for the framework we base transformations on.  The framework will provide lots of data for us to act on, if we ignore it how can we blame the framework? 

The second common issue I see with this visibility is fear.  Fear of change, fear of loss of control, and fear based on self-preservation.  These are valid and legitimate human reactions, and we need to deal with them, but they should be viewed as a positive sign from the transformation.  We are now exposing underlying issues in the system that were already there, but with the increased visibility we can now deal with them.

The cure to all of these exposed systemic issues is simple, but not easy.  Leadership needs to re-focus on building a better system.  As I coach executive leadership I hear a common thread “we don’t have time for training or coaching.  We have too much to do”.  However, when we look at what these leaders are really spending their time on I find a large focus on directing work rather than building a better system.  Before we blame the framework for lack of transformation success, let’s look at how much time we are spending on creating an enterprise system where the framework can thrive.  That is the true objective of leadership.

Reactionary Product Ownership

If you are a Product Owner in a SAFe® ART, are you having to adjust and adapt on the fly to team questions, stakeholder questions and Product Manager questions?  Are you struggling to find answers to team questions?  Are you finding it difficult to represent the value opportunities, and struggle to prioritize stories for the team?  If so, you may be a Reactionary Product Owner.  The Reactionary PO suffers from these all too common symptoms, which is very often caused by lack of a Product Vision and an accompanying Product Roadmap.

Avoid 'Reactionary' Product Ownership with a Product Vision

Many PO’s I work with are surprised by the reality that they need to have a documented vision in place.  The common thinking tends to be “Doesn’t the Product Manager(s) vision cover my team?”  The short answer is no.  Every product owner needs to have a vision of what their team is going to do to contribute to the ARTs success.  As part of a Team of Teams within an ART, the vision should closely align with the ART’s vision, but should add more detail and narrow the scope to the team level.  Without a vision the team is left with no clear direction, and the frantic Product Owner has to jump from issue to issue, providing on the fly answers.  With a healthy vision, the team can answer many questions on their own by simply determining which of the options would best target and work to fulfill the vision.  With a vision to guide their decisions, prioritization of both the team and iteration backlogs becomes much easier.  
Note that many ART teams focus on slices of a Value Stream, rather than a 'Product', but the above still applies.  Whether Product or Value Stream based, a vision answers the team question “What part do we play in making this Team of Teams successful?”

Product Vision

A vision should clearly state the purpose and direction for the team.  It should finish the statement “We exist as a team to deliver/solve/provide <X>”.  Roman Pichler does a great job of defining a vision with this statement: “The product vision is the overarching goal you are aiming for, the reason for creating the product. It provides a continued purpose in an ever-changing world, acts as the product's true north, provides motivation when the going gets tough, and facilitates effective collaboration”.  But what does a good vision look like?

Every successful vision has a few key elements.  

Roman uses 8 steps that are extremely valuable, but I'd like to highlight a few key steps:

Describe the Motivation behind the Product – Why is it important to achieve this vision?  How is the world better when we get there?

Employ a Shared Vision – If the vision is created in a vacuum and kept in a desk drawer it adds no value.  Share it with your team members, with your Product Manager, with your Stakeholders and others that can help to refine and achieve this vision.

Choose an Inspiring Vision – Does your team feel motivated when they read the vision?  Do your Stakeholders get excited when they read the vision?  Does it get you up in the morning with a smile on your face as you realize the importance of your vision?

Keep your Vision Short and Sweet – Your vision should be something you can put on a poster in the team space (and read without a magnifying glass).  If you have to write War and Peace to state your vision then it will be hard to convey to others.

And I will add my own step, Your vision should be Unique - Your vision statement should not be so generic that you could take it down to the local sandwich shop and see the same vision.  Avoid the generic statements such as “we want to be the biggest/best/fastest at what we do”.  Make it measurable and unique to you and your dream of a better future for your customers.

Here are two examples of good vision statements.

SpaceX

"SpaceX was founded under the belief that a future where humanity is out exploring the stars is fundamentally more exciting than one where we are not. Today SpaceX is actively developing the technologies to make this possible, with the ultimate goal of enabling human life on Mars."  (Authors note: Notice how they were specific with “enable human life on Mars”?)

Ikea

“At Ikea, our vision is to create a better everyday life for the many people. Our business idea supports this vision by offering a wide range of well-designed, functional home furnishing products at prices so low that as many people as possible will be able to afford them.”  (Authors note: Notice the specific reference to well-designed, functional and affordable)

Creating a Vision

Start by listing some simple things, like what you like about your job, what makes you feel good about what you do, and what you would tell others about what you do.  Then think about your customers, both internal and external.  How are you trying to make their life better.  What specific things about your product or service do you want to brag about to others.  Build on that by stating why these things are important.  How are you trying to change the world by creating these products?

Now, create your first rough draft.  If you are like most, it will be lame, ambiguous, and uninspiring.  That’s ok, this is a process.  Circle the parts you like about your vision, and underline the parts you don’t.  Do you see the passion, the energy, the motivation in this version that you want to convey?  If not, rewrite it and focus on this energy and passion.  Now take a closer look at this version.  Is it specific?  Is it measurable?  Would it provide guidance and direction for your team?  Would it show how you are aligned with the ART vision?  If not, refactor it.

Once you have something you are reasonably pleased with, show it to your team.  Don’t ask them if they like it, instead ask them to identify parts that inform them, that get them engaged, that inspire them, that help show how they are aligned to the ART goals.  Ask for and demand honesty, and their help in iterating on the vision.  You will find that this will become a really important team building exercise, as all of you will take part in creating the vision for the team.

The last guidance is this: don’t save it off in a corner and ignore it.  Print it in large font and post on your team wall.  Make notes on it as you learn new things about the vision.  Point to it when you or your team has questions about direction.  If you can’t find at least high-level guidance from the vision, go through it again.  Print a new version on a regular basis as it matures and evolves.  Visions are dynamic, living things that need usage and attention to be successful.

Roadmap

Once have your vision in place, now it’s time to determine what steps you have to take to achieve this vision.  Roadmaps are essentially statements that are based on what we know today but are easily adjustable as needed to apply new knowledge and shifts in markets to still achieve the vision.  A roadmap is saying “See our vision?  Here are the near-term steps we believe we need to accomplish to achieve that vision”.  In SAFe®, the Program Roadmap is documented in a healthy Program Kanban board, where we can see near term (“Implementing”), projected (“Analysis”) and potential (“Idea Funnel”).  At the team level, the roadmap is refreshed each PI through PI Planning.

Create your vision with the teams help.  Iterate on it as you learn more and move towards the vision.  Establish a roadmap for your team that aligns (as needed) with the ART roadmap.  Then, the next time you face a tough question from a team member on direction, you can be 

this cat   instead of this cat.

Systemic Problems in IT

Technology is great, when it works.  How many times have all of us made this statement when tech has left us hanging?  But, is it really tech that’s the problem?

One of the nice conveniences I take advantage of each year is online or kiosk based license tab renewal.  Since I own a plethora of motorcycles it is extremely handy to go online, enter in the license plate and last 3 of the VIN, and process my tab renewal in minutes.  However, the Minnesota DVS website has been experiencing some problems, which lead to finding this article:

“State won’t say when DMV problems will be fixed. Senator suggests IT overhaul”

Reading through the article I’m reminded what a difference mindset and thinking have to play in how well our technology supports us.  The responses from the MN IT group are (unfortunately) far too typical of traditional thinking, and clear indicators of an underlying problem with this type of thinking. 

Let’s take a look at some of the symptoms.  “Redwing said the team is working on a “road map’ for how to fix the $93 million system, known as MNLARS, and that road map will have a timeline for fixing the problems, which have persisted since its launch in July. ... Redwing said the “road map” would be completed at the end of January. ” 

While a roadmap is essential to a lean agile way of thinking, it is never kept in a dark corner until ‘completed’.  If we are working on a roadmap, and not getting feedback from our stakeholders, how do we have any idea if it is in line with what they want?  How do we know we have priorities organized for the best economic sequencing of value?  Roadmaps serve one key purpose: they elaborate in more detail how we expect to achieve our vision.  They are not predictive (we humans are terrible at predicting the future) but instead rely on “based on what we know today” approach.  As we begin to iterate towards this vision through the roadmap we apply what we learn along the way to update and improve the roadmap.  So, in short, a roadmap is never ‘complete’ until the vision is achieved.  If this sounds undisciplined to you, then you are missing the point.  It is actually far more disciplined than a traditional, ‘waterfall’ approach, as it requires us to learn quickly, measure our progress honestly, and apply both learning and metrics to iterate on the roadmap. 

Senator Scott Newman is one of the vocal critics of this approach within the Minnesota legislature.  “So far I haven’t heard much of anything of a definite answer to anything,” he said. “So far I have heard ‘I don’t know’ and, to be candid, evasive answers.”.  What puts IT leadership in a situation to provide these types of frustrating answers?  This is (almost) always a systemic problem, and in this case most likely goes quite deep.  If the system penalizes honesty and learning, then we will work within the system, and these types of vague answers are the result.  How do we fix this?  Fix the system.  This is a core responsibility of lean agile leadership; create an environment that promotes openness, honesty, and a culture of learning and iterating based on that learning.  I completely understand this is in a government setting, and unfortunately, we tend to expect more of this predictive behavior.  But what if the system underlying this problem promoted and encouraged fast learning, application of that learning, and transparency to progress and direction?  You would see a very different scenario.
Seeing the full organizational process you use to deliver value as a system is critical to improving situations such as this.  As Esther Derby points out, applying lean and agile thinking to improving these types of situations is only possible when approaching this as a system problem, and not a people problem.

Based on my years of coaching large enterprises that find themselves in just such a situation, I have Weighted Shortest Job First.  My guess is that far too much time has been spent on the gathering and far too little on the economic sequencing.  Open the conversation with key stakeholders (state government officials, DMV users, etc) as to the direction and purpose, deliver incremental changes and improvements on a regular basis (no less than monthly) and apply concepts such as Innovation Accounting to measure the impact of the efforts.  This is not an 'assessment' issue, this is a 'let's get started and learn and improve as we go' issue.  I have seen this same organizational system at many fortune 100 companies, and have experienced over and over that this is a solvable problem, but not with traditional thinking.  Incorporating a mindset, principles and practices based on Lean and Agile thinking is the only way to solve these types of systemic problems.  
some specific advice for MN IT (and echo Senator Newman's sentiments).  Change the system, before it’s changed for you.  This would involve quickly gathering and assessing the major problems and sequencing the resolution of these efforts for best economic outcomes using a formula such as