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. 

Self-Organizing does not mean Self-Managing!

I hear quite often someone referring to the importance of ‘self-management’ of an agile team.  I want to dispel that myth.  Agile teams are Self-Organizing, but not Self-Managing!

Agile Principle #11 “The best architectures, requirements, and designs emerge from self-organizing teams.”(1)

Self-organizing means that a team can see a

piece of value to deliver, and within their own ranks, organize around how to accomplish the work.  This is a core tenant of Agile as it has been proven over and over that the most effective teams are simply given the Principle of Mission (2) and the minimal constraints within which they must operate, and allowed to organize themselves around the work.  By self-organizing around the work the team self-optimizes for the best approach, using the localized knowledge they have of the domain, skill sets, etc of the team environment.  True efficiency, as well as team satisfaction, is gained only through self-organization.  However, when teams try to Self-Manage in most organizations (the Spotify’s or Holocracy organizations of the world excluded) they will struggle. Why?  Because every agile team has intrinsic needs to be truly successful, and many of these cannot or should not be handled within the team alone.

Current management patterns are based on 17th century Taylorist styles that essentially state that the workers are too uninformed/ignorant/uncaring/stupid to figure things out for themselves, so they have to be told what to do at every step (my bias shows through in that statement).  True management is about maintaining the systems we build for the teams to thrive in.  To paraphrase John Kotter, ‘Leadership builds systems, management maintains systems”(3).  This style of management does not mean controlling the teams, but instead acting as a bulldozer to clear the obstacles out of the team’s way.  This includes things like supporting the teams in limiting and adding visibility to WIP and identifying and removing impediments for the teams to focus on the work.

There are many attributes of management that work well in a lean and agile environment, but some of the characteristics I have seen are: challenging the teams in a positive manner, helping the team to create and continuously update improvement metrics, and enabling and encouraging career and skill growth, Team formation is also a key role of agile management; I once heard Esther Derby state that over 60% of the success of any agile team is based on its initial creation, and I have experienced that same approximate importance.  Also, and unfortunately, not every agile team can deal with the ‘voting off the island’ time when a team member is just not in the right situation; good agile management can turn that potentially negative situation into a positive.

To enable true self-organization, Agile Managers need to exhibit the same lifelong learner and knowledge hungry approach that they expect from their teams.  They are not in the role for the title but for the sake of advancing the careers of others and for the ‘greater good’.  This takes a special mindset, and one that will take time to bake in, but the underlying desire to move towards that type of role is essential. 

If this definition of the Agile Manager is not what you see at your organization, then I can understand the desire to make agile teams self-managing.  However, let’s fix the root of the problem: let’s train and educate our managers to drop the draconian practices and become true agile managers.  That’s when, IMO, you will start to see the difference between self-organizing and self-managing agile teams.  The added benefit is that these agile managers will find more career satisfaction and enjoyment in their new role.

1) AgileManifesto.Org

2) Humble, Molesky, O’Riely, “Lean Enterprise: How High Performance Organizations Innovate at Scale”

3) John P. Kotter ‘Leading Change”

   

Focus the System Demo on the System (and not the teams!)

The system demo is a critical aspect of SAFe for each PI, but many people misunderstand the reason for it and the outcomes we are looking for.  The System Demo is much more (and much less) than what is sometimes practiced, and understanding the goals and ‘better’ practices will help you get the most out of this critical ART event.

This article is not meant to re-define the System Demo; that’s already been done quite well in the SAFe guidance article on the System Demo.  It provides very clear direction on the importance and objectives of the System Demo.  What I want to call out is the importance of making this demo Team Agnostic.  The problem that I have seen quite often is that many ART’s have not fully grasped the importance of a Team of Teams, and still function as a collection of teams.  The System Demo is a great way to start to change that mindset.

General Stanley McChrystal laid out what a true Team of Teams looks like in his incredible book “A Team of Teams”.  (please see John Pearson’s blog for a great summary).  This pattern needs to be replicated in some form in every ART to create the right alignment to deliver on a common value stream.

Let's first clarify the difference between the System Demo and the Team Demo (or Team Review). The team demo in SAFe is very similar as in Scrum; as a team we are demonstrating what we were able to accomplish to gain feedback and course correction. It's not about showing how much we accomplished (it’s not a status report), but rather about showing the progress we made on a given effort so that we can get input on direction and possible course correction.

The system demo is very similar in that we’re really looking for feedback on what we've accomplished to gain course correction. We are also looking to measure progress against our team and Program objectives. Just like the team demo, this is not to show that the team is getting work done but much more to show how we're doing against our stated objectives and helping us see if we need to pivot to be able to meet these objectives.

The core difference between a system demo and a team demo however is really in the scope and the manner in which the demo is presented. By it’s very name, System Demo, we are showing how far we have advanced the system, not just what each team has done. So, from that perspective I believe it vital that the system demo is done team agnostic, e.g not done team by team. I see a lot of ARTs that are running system demo’s team-by-team or even story by story, but that's really for the team demo. The system demo is about showing the entire system and how all teams have contributed to moving it forward during the last iteration. In fact, the system demo is one of the best ways to show the critical distinction that this is a team of teams, rather than a group of teams. By demonstrating the system and how its advanced, combining each team's contribution, we bring the perspective that this is really a team of teams working together towards a common goal and not just a collection of teams.

Another important note is that the system demo is generally presented from the product management to the stakeholders. I see a lot of ARTs that use this opportunity to demonstrate to product management how the system is incremented, but this progress should be discussed with Product Management outside of the system demo and during the iteration. The Product Manager(s), just like the Product Owner, should see the progress as the system moves forward during the iteration.  This does not mean that the Product Managers are not learning more about the system and providing course correction and direction during the demo, it just means the bulk of the course correction and feedback should be coming from stakeholders,

PI Planning and Execution Simulation

(Designed to complement SAFe® For Teams Training)

Overview

SAFe® For Teams (S4T) training is a critical component to launching an Agile Release Train (ART) successfully.  The training event will provide a level set on SAFe® ScumXP, provide insight into how to plan and execute a Program Increment (PI) and allow the teams to start or solidify their formation as a successful Agile Team.  However, the impact of the 2 day education can be enhanced by providing a hands on simulation for teams to practice their new learning and skills prior to the upcoming PI Planning event.  The Scaled City PI Simulation is an adaptation of the tried and true Scrum Simulation using LEGOS® that has helped so many teams learn the basics of Scrum in a fun and engaging environment.

The PI Sim PowerPoint provides a step by step guide for SPC’s to use to deliver this exercise.  The Sim is intended to be incorporated into the S4T training, preferably in the morning of the second day, but can be utilized outside of the training event.  This allows team members to lock in the learnings from the previous day and an opportunity to exercise their new Lean Agile muscles.  The PPT is self-explanatory for the delivery steps, however there are many nuances to apply to this exercise to enhance the learning.

Setup

You will need around 200 various sized LEGO® pieces per team.  Try to get a variety of types and usages, including a number of wheels and special shapes.  LEGO's are not cheap, but hitting a few garage sales or eBay items will help reduce the cost.  You will also need large 2’ x 3’ poster sheets (2 for the city layout and 1-2 per team for planning), markers or sharpies, and a printed copy of the Features from the PPT.  Each team should have a table and space large enough for 4-6 people to move around easily, as well as one large poster sheet to do their planning.

Prior to the start of the exercise you will need to setup a ‘deployment’ table in the middle of the room, and tape two large flipchart sheets long edge to long edge on the table for the city layout.  I usually draw a river along one edge and leave the rest as a blank canvas for the teams to innovate on.  If you have a co-trainer, ask them to play the role of Mayor of Scaled City.

Simulation

This exercise is about learning, but it’s also about generating energy and confidence in the PI Planning and Execution process.  Hopefully, you are presenting the S4T training right before the PI Planning event (think M-T for S4T and W-T for PI Planning) in which case any energy you can generate in this simulation will spill over into the planning event.  Start this sim off with as much energy and enthusiasm as you can, and keep it fun! 

I usually jump right into the deck and explain the sim using the information in the slides. 

Team/Feature Selection

To speed things up, each team will have pre-assigned features based on their team name.  Make sure you explain that this is not normal, but only done for the simulation, as most PI Planning events will utilize what I call team agnostic features.  I like to have the teams select their team name (and their features) after the Product Vision and Roadmap to create a sense of self-organizing around the problems to be solved.  For experienced Product Owners and Scrum Masters I like to have them take a different role to see how the ‘other’ side lives, but inexperienced or new PO’s and SM’s should probably take that role in the Sim.

Planning

Don’t worry that the team members are following every ‘rule’ of PI Planning, but focus on the important aspects, such as Team Objectives (gleaned from their features and the vision of the city), dependencies to other teams (e.g. DOT needs to work with Works to make sure the bridge meets the needs), and risks to their plans (a common one is that they will not have enough Legos and will need to borrow).  During planning ask each team questions that will lead them to discover the objectives, dependencies and risks critical to the commitment.  Help them with the time box by repeating “Breadth versus Depth” and focusing on a broad plan with gaps that they can go back to fill in as time permits.

Plan Review

This is a great time to cement in the need for discovering and planning around dependencies on other teams.  As each team reviews their plan ask questions that will lead to discovery of missed dependencies.  Have each team focus on their objectives in the review, rather than reading off each story.  Call out risks they may have missed in their plans, stressing that risks are opportunities for the plan to fail.  Once each team has committed you can do a confidence vote, but for the sim you don’t need to spend much time on getting every team member to a 4 or 5.

PI Execution

Iteration 1

In the first iteration you want to generate a quick win for the teams to generate confidence, so I usually coach them a fair amount towards success.  However, I do leave particular things out, such as early integration and deployment.  A very typical scenario is that the teams will build for the first 14 minutes and then scramble at the last minute to integrate into the city, resulting in things like a 1 inch high fire department and a 4 inch high fire truck.  As Product Manager, I stress the importance of integration by looking for issues (real or made up) to show the impact of lack of early deployment and integration, resulting in delayed learning.  The system demo is always full of teaching opportunities!

Iteration 2

During Iteration Planning I stress the inclusion of learning from the first iteration, encouraging them to alter their iteration plan from the PI Planning as needed to adapt.  Depending on the progress of the teams I will add a wrinkle by disappearing for most of the iteration timebox, thereby making the Product Manager not available.  When I reappear (usually with just a minute or two left in the iteration) there are usually tons of questions and adjustments needed.  This is done to illustrate the need for the involvement of the Product Manager throughout the iteration, and the usefulness of live feedback.

Iteration 3

By the middle of iteration 3 the teams are usually winding down on the committed features and have time to innovate.  At this point I start to introduce new ideas based on the knowledge they provided during the other two iterations, such as adding a ‘homeless problem’ from all the people moving in to our great city faster than expected, or a water treatment problem (one team solved the lack of fresh water by grabbing the water pitcher off the snack cart and placing it in the town as a water tower, that’s innovation!)

Summary

After the PI system demo (end of iteration 3) I gather the teams around the city and pick out other learning opportunities.  Look for things like the amount of collaboration, the ability to work cross team, the way the teams solved problems that they didn’t believe they had the skillset to tackle, etc.  I wrap it up by illustrating how similar this is to executing in a PI, and encourage the teams to use the sim to help them think differently during the upcoming PI Planning event.  Heading back in to the rest of the S4T training I can now use a lot of examples from the sim in the subsequent content with something they can connect with.

Please feel free to use this toolkit as is without any license or the like, however, please do not modify or remove the Radius ET branding without previous permission from Radius ET.

Note: SAFe®, SAFe For Teams®, and the Scaled Agile Framework® are all copyrights of Scaled Agile Inc.  

The Only Valid Architecture is Validated Architecture

I have worked in the IT field for over 3 decades now, and I’ve seen a lot of effort expended in design, architecture and infrastructure areas to build out some incredible and fantastic platforms and underlying systems.  However, I’ve never seen a 100% utilization of that effort.  In general a large part of the work is never used or, even worse, becomes a blocker to future agility.  Why do we do that?  Why do major components of these architectural designs, many built by some of the most intelligent people I know, go unused?  From my experience, it is always due to our tendency to separate architecture usage from business feature usage.  Architecture alone does not add to our bottom line or overall success.  It is only when that architecture or design enables us to solve customer problems that business value is achieved.

Architecture, design, UX, and any other similar effort should only be expended in the pursuit of supporting business value.  Yes, Architects, Designers, etc, I do mean that without the business value you support you have no reason to do the work.  And, even more importantly, unless you are building architecture to directly support currently needed business value, you have no way of validating if you have designed the right architecture!  Only after validating your design by seeing it enable business value do you know if you have built a valid architecture.

From an Agile perspective, this makes sense.  Agile Principle # 10, the art of maximizing the amount of work not done, stresses that the simplest solution is often the best solution.  From a Lean perspective we are pushing to eliminate waste in the system; unused architecture is a huge source of waste (as well as quality issues).  Add in the Lean Startup perspective, which brings to the table that sense of experimentation to gain knowledge quickly, and we gain the perspective that true validation only comes from the customer.  Then apply all 9 SAFe® principles (yes, Intrinsic Motivation counts) and you start to see the picture that we should only consider architectural effort well spent and validated once we see it supporting business value and solving customer problems.

“But, wait!” you say, “if we delay creating architecture/infrastructure/design, we end up with a fragile mess!”  True enough, we definitely need to have intentional architecture so that we have a consistent and supportable direction with our designs.  We absolutely need to be looking ahead for the architecture, designs, patterns, infrastructure, and all the other needed components to support business value.  Enter the SAFe® Architectural Runway.  This Runway combines Intentional Architecture and Emergent Design to ensure that we are building the right amount of architecture up front, but ensuring that all of our efforts can be quickly validated by supporting actual business value.

Intentional Architecture

Where are we going with this solution?  What framework, capability, etc will be needed to support future business value?  What do we need in place to avoid future performance issues?  Are we headed in a direction that supports future security concerns?  Those are all things that need to be discussed and planned for.  However, each discussion we have should be accompanied by “what business value is upcoming that can validate this is the right direction?”

Emergent Design

Emergent Design is a core component of validating architecture incrementally.  The ability to create a ‘walking skeleton’ of the intent and then allowing the details of the design to emerge from the teams each increment allows us to validate the value of each architectural component as we progress.  The key is to ensure that we are establishing our measurements and leading indicators of the viability of the architecture and design we are pursuing.  Having a direction is the first step, but then we need the teams to build to that intention, and then stack business value on top to validate the intention. 

For example, let’s assume you are trying to move your application base to the cloud.  Your assumption is that moving your entire infrastructure to the cloud will result in cost savings and the ability to scale capacity much more quickly.  However, you have a massive amount of applications to manage, that all seem to be inter-connected, and you cannot interrupt operations.  In addition, most of your footprint is legacy apps that are client-server or mainframe based design.  A traditional mindset would state that you need to design a cloud capability to support all of these apps and their connectivity (which means migrating a number of mainframe apps) which will require a massive application and workflow design.  And you are correct, you do need a plan, but as von Moltke stated “No Battle Plan Survives Contact With the Enemy”.  Applying Intentional Architecture along with Emergent Design is the way to survive this massive effort.

Instead of pursuing a big bang approach to this effort, pursue an incremental, learning based approach to the architecture and design.  What early indicators would help prove we have the right concept of how to move to the cloud?  What early value can we pursue that will not only help us determine the right direction, but also confirm the perceived value?  The first step is to have a firm plan that is easily changed.  Create a clear vision of where you want to go, and your approach to getting there, but create the plan with a high level of abstraction.  Avoid the locked in design that can result from going too deep too quickly.  For each component of the design ask yourself “How does this support the business outcome we are looking for?”

Next, determine the architectural/design areas that are the most mission critical or present the most risk.  It is important to isolate these areas to be targeted for early learning.  Look for areas that will not only gain knowledge on the architectural direction, but also support the most business value, both of which will provide faster feedback on future direction.  Avoid the ‘sacred cows’, the areas that you want to put in, but don’t really need.  Add in the understanding of how you will measure this progress, looking for leading indicators that will help to provide faster pivot or pursue moments.  For example, if part of your reasoning for moving to the cloud is cost savings, determine how you can measure cost savings with each increment.  Sometimes you have to extrapolate or use non-monetary indicators early on, but get as quickly as you can to real savings measurements.

Now, build the bare minimum architecture you can to gain the knowledge you need, e.g. to move your metric needle forward.  If your assumption is message based connectivity in the cloud, but you are using file based communication in many areas, can you first get these apps to talk via a simple message queue or service bus?  Do you really need to move to the cloud before you have built the first step of communication?  As you build these incremental steps you start to play leapfrog: a little architecture, a little business, rinse and repeat, all while keeping an eye on the end target.

Both Emergent Design and Intentional Architecture require Validation to be successful.  The Architectural Runway is there (in part) to ensure that we are recognizing that need for validation.  The next time you are thinking of this cool new platform concept, wanting to implement the latest My/No/Yours SQL, remember to think “what business value needs this?  What business value can we build on this capability to validate we are going the right direction with our intent?  How can we quickly measure the success of the design?”  Then, build that business value on the early iterations of that architectural work, and look for customer validation for course validation or correction.

Solution Accuracy over Quality

In the last few years (maybe even decade) there has been a strong surge towards quality in our product development.  Not just limited to software, this focus has led to much stronger practices and tools leading to much more robust, scalable, and resilient products.  While this is in general a highly needed change from the somewhat sloppy work from previous generations of developers, but I believe we are missing the point in not applying the same, or more, attention to the accuracy of what we are building. 

Think about it.  If you are delivering a solution that is near 100% quality, what good does it do if it is not the optimal solution?  Regardless of your definition of quality, If I create a product that meets 100% of those levels, but does not solve the customer problem or advance the ability to use the product, did I do any good?  As an extreme example, if I write the highest quality game application that could exist, but what the customer needed was banking functionality, did I really add any value?  Don’t get me wrong, I am a huge advocate of quality in all products, and teach and coach software craftsmanship as a part of my work with my customers.  However, we have to balance that out with the accuracy of the solution.  Our attention to ‘Zero Defects’ has lead us away from ‘Solved the Problem’

Solution Accuracy, on the other hand, has a strong focus on learning, analyzing, measuring, validating and adjusting to deliver what our customers need.  Not what they tell us they need, but what they really need.  The adage “the customer doesn’t know what they want, they only know what they don’t want when they see it” is painfully true.  (Remember Henry Ford’s statement of “If I had asked customers what they want, they would have said faster horses”).  Accuracy is about incrementally working towards an optimal solution by applying the concepts of established Principle of Mission, iterating towards an optimal solution, and applying leading indicators that help us course correct or pivot as needed as we continue to study the impact on our customers of our emerging capability(ies).  From my years of working with Fortune 100 companies I have experienced time and again the lack of attention to accuracy and optimal solutions, instead following a Crystal Ball plan of predicting/forecasting what the customer needs, and most often arriving well short of the target.

Why is this a problem?

Assume Variability, Preserve Options

As an Enterprise Transformation coach and SAFe SPCT, I rely heavily on two core aspects to raise awareness to the solution accuracy problem.  The first is SAFe’s Principle #3 “Assume Variability, Preserve options”.  In general, this principle shows us the benefit of not relying on predictive ‘Point Based’ solutions that rely on far too little knowledge and information to state that we know what the customer needs/wants.  The typical 3-9 month corporate project that relies heavily on not only a stated outcome, but also a direct statement on how to achieve that outcome, usually accompanied by a project plan with everything detailed out to the low-level task.  If we were to honestly reflect on the results of this predictive planning we would quickly see that these efforts rarely are on time and within budge, but even worse, rarely actually solve the problem at hand. 

SAFe Principle #3 Assume Variability, Preserve Options.  Copyright Scaled Agile Inc

When we “Assume Variability” we understand that we don’t have the full level of knowledge yet (that will be gained as we iterate towards a solution) and that we should assume that our current assumptions are invalid because of the lack of that yet to be gained knowledge.  It is important to have assumptions of what the best path forward is, but when we assume variability exists we accept that we are most likely wrong (sometimes very wrong).  Assuming Variability says that we know we are going to learn more, so let’s take advantage of that variability and iterate towards the solution with a plan and process that inherently incorporates that new knowledge as we progress.

To ‘Preserve Options’ means that we never lock ourselves into a corner, never stating “this is the only way to solve this problem”, until we have gathered the most knowledge we can.  It’s great to have an assumed best path, but we also need to acknowledge, and sometimes pursue, other options that may turn out to be the better path.  Yes, that does mean sometimes you will pursue a solution that will be deprecated or dropped based on knowledge that indicates it is no longer a viable path.  If that sounds like wasted work, I would gladly trade that level of ‘waste’ for the waste we find when we pursue a point based solution and have the resulting adjustments, changes, and sometimes project cancellations due to chasing the wrong path. 

Tying these two together means we start out by allowing and encouraging more than one possible solution direction, pursue one or more to gain knowledge as fast as we can, and pivoting or dropping assumed possible solutions when the knowledge shows we should.  The end result is an optimal solution with less effort because we were not forced into retrofitting the wrong solution like a square peg in a round hole.

Example of “Assume Variability, Preserve Options”

I was working with a client on this concept, and as they began to understand this principle they shared a story with me that is a great example.  This client is highly regulated, and needs to process documents for regulatory and audit reasons on a regular basis.  When this new requirement came to light, the business asked the IT group how they could solve it.  Being the technology savvy group they were, they stated they could create an automated system that would process the documents as needed, at a cost of $8 million and about 6 months of effort.  They completed the project a little over budget and a little late, but since this was the norm they considered the project a great success.  Until they turned it on.

The first month the system only processed 3 documents based on the needed updates.  The second month?  2 documents.  The third?  3 documents.  The result after one year was that each document cost about $67k to process.  They then realized that if they had “Preserved Options” they would have realized that an alternative option would have been to hire a temp to come in one Saturday a month to process the documents, at a cost of approximately $75 per document.  Because they had not recognized the need to “Assume Variability” in that they did not yet know the volume of documents, they went to a point based solution that made sense.  Bear in mind that the automated system was still a viable option, but since the manual was such an easy approach it most likely would have been the first option to pursue.    The ‘quality’ of the effort was high based on the low number of defects in production, but the accuracy was 180 degrees from the optimum solution.

Focus on Solution Accuracy

Focusing on solution accuracy does not mean being predictive, it does not mean having to know all the answers at the start.  In fact, it assumes we don’t have all the answers, and incorporates learning early and adjusting based on gained knowledge throughout the effort.  Another coach just sent me an email with this quote on her signature line:

“Progress means getting nearer to the place you want to be. And if you have taken a wrong turning, then to go forward does not get you any nearer.If you are on the wrong road, progress means doing an about-turn and walking back to the right road; and in that case the man who turns back soonest is the most progressive man.”

C.S Lewis

Our goal in focusing on solution accuracy is trying to get to the most valuable and informative pivot or pursue moments as soon and as often as we can, and making those adjustments as needed in pursuit of the optimum solution.

SAFe Train Engineers: Metrics - Activity Accounting

Copyright: cthoman - 123RF Stock Photo

As a Scaled Agile Framework RTE (Release Train Engineer), one of your primary goals/responsibilities is to measure and track the improvement of the teams and the train.  One of the ways to do this is through Activity Accounting.  Essentially, this is an assessment from product developers stating the percentage of time they spend on each measurable activity (the important ones).  We then want to help the teams turn these numbers from many of the non-value add activities towards the direct value add, like innovation and planning

First, to measure these things.  Work with the teams to figure out what makes sense, but an example to maybe start with is:

• Defect fixing
• Code Integration
• Planning
• Branching/Merging
• Manual Testing
• Creating/maintaining automated tests
• Innovation
• Other?

Copyright: 123RF Stock Photo

Have your teams determine how to measure their selected items from a % of total time spent, for example, Integration might be 10%, manual testing 30% and automated test creation might be 15%, etc.  Don’t worry about actual hours, just percentages.  Then, assess that data in the I&A workshops in your planning events.  Which ones stick out as issues?  Which ones would add the most benefit if improved upon (usually reduced)?  How can we shift from non-value add (branching, defect fixing, etc) to value add (planning, innovation, etc)?  Share these numbers, goals, and plans with your leadership to show them where you are now (transparency), and what your targets are and your plan to get there.  Incorporate these improvement efforts into your planning event as objectives and help the business owners understand the business value of these items.

One other thing, be fairly aggressive on these goals.  For example, improving automated testing by 1% is pretty weak, try for a higher number that seems challenging but still reachable.  If you don’t make that number, that’s ok, you will learn much more about what is keeping you from those targets, and these newly discovered impediments can be addressed as new objectives in the next planning event.

If this sounds like a lot of work, it is.  But it’s well worth it.  If you say that you don’t have time to add this to your plate, look closely at what’s on your plate.  This measurement practice is the protein and vegetables you need, a lot of the other stuff is just empty carbs and should be prioritized out or delegated to someone else.  Your true value as an RTE is in helping the train improve, using Activity Accounting is one significant way to do so.

(Much credit for these concepts go to Humble, Molesky and O’Reilly in their excellent book “Lean Enterprise”.  I recommend every train engineer have a well-read copy at hand)

Just what is an Agile coach?

Having labeled myself as a coach for the last 10+ years, and having trained other coaches, I’m often asked about just what is an Agile Coach?  Just like in many other industries that have no true certification or accreditation, we see people claiming the title that maybe should not, and others that are coaches without even knowing it.  I thought I’d share my thoughts on what I believe the attributes of a true coach is, and why it’s important to understand these attributes.

Definition

Merriam-Webster defines a coach like this:

  

Merriam-Webster aside, the Lean Agile movement is all about self-organizing teams, de-emphasizing meritocracy and Taylorist style management, and teams and organizations learning and adapting as they go.  So how does a traditional term like Coach, that implies some level of direction and decision making, apply to how we help teams and orgs succeed?  It’s simple, really, we do both.  A true coach will create an environment of self-learning and growth, combined with the safety of just enough guardrails to enhance the chance for success. 

However, there are times that a coach needs to provide strong guidance and direction to help avoid as many of the potential mistakes as possible.  This doesn’t mean shielding the group from experimenting or trying new things, but it does mean to start the group on the best footing possible.  I heard from one of my favorite agile champions several times “we didn’t bring you in here to tell us what we are doing right, we want you to tell us what we are doing wrong”.  There are many occurrences when a coach has to establish guidelines, guardrails, or guide posts to help direct the groups.  If your family is running along a mountain top and are heading towards a cliff you might say “are you sure you want to run that direction?” but there comes a time where you will physically stand in front of them to prevent them from going off the cliff.  The same is true for a coach; we want to help the groups learn, oftentimes from their own mistakes, but there can come a time where you have to stand up and say “no, don’t do that” and help them understand both the dangers they face as well as some alternatives they could try.

Over the years I have developed a set of attributes that I think are critical to have as a coach.  Some have to be there from the start, others can be developed along the journey.

Empathy

Your clients are typically coming from a different perspective than you, and it is critical that you can   When I coach a mid-level manager on standing up to a tyrannical manager that is blocking progress, or a command and control HR department that wants control and stability, I have to remember to view the situation from the eyes of the manager I am working with.  Often times my first reaction is to say “What’s the worst that can happen, they could fire you?”  But then I remind myself that the manager may have built a career in a difficult environment, has just bought a house near the office, or any other number of reasons that they may have the self-preservation instinct kicking in to block them from doing what they know they should do.  Working alongside them, observing (without being observed) in as many of their interactions with the problem situation, and trying to really understand the problem from their perspective is a critical aspect of a good coach, and one I continue to work on myself. 

put yourself in their shoes (to a point) to understand how best to help them.

Courage

My definition of courage is not being fearless, but rather facing a situation in the presence of fear.  As a consultant you are often walking a thin line between continuing on with the client and going to that next engagement, but that should have limited impact on how you face a difficult situations.  As an internal coach you may feel that you have job security and a home for the foreseeable future, but you have to set this aside in favor of what’s right for the company.  Courage is about knowing what’s right and fighting for it, despite the consequences. 

Passion

Monotone just doesn’t cut it.  Lethargy is a buzz kill.  Indifference is the enemy.  Passion in helping others see success, in displaying excitement for the potential, in giving others a kick start from your energy level, all of these are vital to a coach.  This does not mean you carry pom pom’s around and try to get the crowd to do ‘the wave’, but it does mean that you carry yourself with a certain level of energy that others can see.  It means showing your excitement for what they are doing.  It also sometimes (many times) means bringing the energy level up by your example and sometimes by being a part-time cheerleader.

But, passion is more than that.  It is that deep seated desire to see others succeed, in knowing that what you are doing will help them achieve great things, and taking pride in their accomplishments.  It is displaying that level of caring that goes way beyond a billable rate or bi-weekly paycheck.  It truly is demonstrating in everything you do that your true desire is for their success.

Resiliency

Coaching teams is not all fun and games, and can be quite frustrating at times.  When you see the level they could achieve, and yet all the times that they continue to stumble, it can take a lot of wind out of your sails.  A true coach must have a dogged sense of determination and the ability to look past the short term struggles.   A continued outlook of “well, that didn’t work.  What did we learn and what are we trying next?” is vital, and must be clearly visible to the groups you work with.  You must have the ability to always try to draw the positives out of a situation and use what was learned to apply to the next effort.  Yes, some situations can be impossible, there are teams and groups that just don’t want to move forward, but up until that point is reached you need to have the “Never give up” attitude.

Knowing When to Back Away

As I just said, there are times when you need to cut your losses and move on, at least for the interim.  Whether you are a consultant or an internal FTE coach, you will face situations where your customer is not ready to change, not ready to transform.  When to back away is never an easy decision; many clients I have worked with that I initially thought were a lost cause have turned out to be some of the most successful.  But often times an organization needs to struggle more before they can find that sense of urgency that is so critical, and the commitment to change how they think and act.

When working with larger organizations this can open up opportunities to work with other groups that are ready to commit, and then use those groups as ‘bright spots’ for the more reluctant group.  There does come a time when you need to say to a team, organization, or group “I’ll be back when you are ready”.   Good coaches are hard to find, and as such we need to help make sure we are working on the most valuable effort that we can, the one that will produce the most value for the business overall.  

Humility

My favorite phrase about how a good coach will act is “Be the Guide on the Side, and not the Sage on the Stage”.   A good coach will use every viable opportunity to create a learning opportunity and a chance for growth, rather than be seen as the ‘Expert’ or the puppet master pulling the strings.  A true sense of humility and encouraging the teams to take the credit for their success is critical.  I have been called many terms of endearment or ap   A real coach will step back from the limelight and let the group revel in their success and achievements (and then help them realize that they still have a long way to go).  There are many times that at the end of a very successful workshop, training, or other event where the group has made a major breakthrough, I will sit to the side or in a corner and let the team celebrate.  After all, it’s their victory, not mine!  We have to learn how to take our metrics, growth opportunities, and career satisfaction directly from the success of others.

preciation by teams and orgs that I have helped, and that always makes me uncomfortable because I know without the hard work and commitment of the team I would not have accomplished anything.

Quick Wit

Sometimes defined as ‘smart ass’.  There are many times that you can diffuse a tough situation, calm nerves, or just take the edge off a room with a well-placed one liner, joke, or funny comment that can get a chuckle and bring everyone back to reality.   It’s called a ‘sense’ of humor though because we have to have the right timing and content to make it work.  The easy ones are the self-deprecating ones, “if only you guys had a decent coach, you would have seen that issue much earlier” or the like.  Obviously, stay away from anything viewed as a personal attack, but I don’t avoid the cultural or gender issues that many times crop up or are under the surface.  Throwing in a quick quip around the problem can help everyone relax and realize that they need to discuss this openly, especially when it’s a sensitive subject.   We are trying to create an environment of transparency, honesty, and collaboration, we can’t do that without addressing the tough challenges, and very often a little humor can help us get to a place where we can effectively address the issue.

Transparency and Honesty

I put these together because they are hard to separate; how can you be honest without being transparent?  And true transparency is based on honesty as we expose ourselves to the realities of our thoughts, goals, ambitions, etc.   Above all, a coach needs to exemplify the character attributes we are trying to build in our clients, otherwise we just appear as a phony.  We have to be willing to expose our mistakes and not try to appear as perfect.

Hunger to Learn

As in many other things in life, product development is really about knowledge gained.  Acknowledging that we don’t know everything (if we did, we wouldn’t need small batch sizes), and having a never-ending thirst to learn more is critical to be a successful coach.  There is a wealth of knowledge out there in books, blogs, websites, etc. from people that are on the same learning journey but perhaps are farther along.  We need to take advantage of these pieces of knowledge already out there, and add to them with our own experiences and nuggets of wisdom gained.  By making this thirst for knowledge very apparent we can instill the same thirst in our clients, letting them know that it’s ok to admit that you don’t know everything.  

All of these attributes that (I hope) we agree are vitally important to a good lean/agile coach, but does that still sound like the Merriam-Webster definition?  I think it still does in many ways, but the most important difference to me is the approach of “take a back seat as soon as you can”.  Yes, we are really trying to coach ourselves out of a job, since our true success is only when our clients no longer need us.  To me, using, exposing and growing the above attributes is one critical part to attaining this end goal.

Forming a highly functional Scrum team – Part One

There seems to be a lot of misconception in the agile community as to what ‘self-organizing’ means.  When we talk about teams self-organizing, we are not talking about a group of 50 people in a room deciding how to make up 6-8 scrum teams.  Yes, that can be done, and it can be effective, but the real gist of self-organizing means to allow the already formed team to determine how to get the work done.  Self-organizing means giving the team the autonomy to determine how to complete the work, but often times the teams need to be formed up first.  Although there are many successful case studies of ‘build a team on the fly’ approaches, there is also a lot to be said for forming these teams with a plan.

I spoke at a conference that Esther Derby was also speaking at, and was privileged to hear her talk on team formation.  She made a statement that took me awhile to process when she said that “60% of the success of an agile team lies in the initial formation of the team”, meaning there is a lot to be said for building the team right to start with.  This was at a time that I was really on the self-organizing bandwagon and so I had to really think through this one.  As I did, however, I realized how right she was.  Building the right team from the start, with the right personalities, drive and attitude, and the right mix of skill sets was absolutely critical to the successful teams I have worked with.  Many (most? all?) of the teams I have worked with that were struggling were seeing issues because of their initial formation.  A team of all extroverts with strong opinions will just clash and fight against the tide, while a team of all introverts will be too passive and just flow with the tide.   A team strong in development but weak in testing practices will struggle with quality, and so on.

So, how exactly do you form the A team for an agile environment?  This is more art form than science, but there are steps that can be taken to increase the chance of success.   These steps include skills analysis, personality assessment, and aligning common goals and interests (amongst the other soft skills needed). 

Personality Assessment

Paramount to building a successful team is to understand what type of team mentality you are looking for.  Do you need a hard charging, driven type of team that won’t accept failure (R&D, Skunkworks, etc) or do you need a team that has a high degree of compassion for the user and always keeps the users’ needs first (Support teams) ?  Understanding what type of team you want to end up with is critical; set up your own acceptance criteria for the team so that you have a clear definition of what ‘done’ looks for the team formation.  Compassion for the user, a drive to accomplish the ultra-cool, and a comfort level with a steady, rhythmic cadence are great team personalities to cultivate

The best scrum teams tend to form a personality all their own, based on the sum of the parts, and you can set the team on the path you want by mixing the right blend of personalities on the team.  Because very few team members will have each of the desired qualities, look for members that bring one or more of the desired qualities and show an open attitude towards the others.  Use scenario based questions that will help bring out the candidate’s personality traits you are looking for.  For example, if you are looking for the customer focused personality, ask a question similar to this.  “Imagine you are asked to staff the support desk for a few days, and a customer calls in that really doesn’t understand our product.  How would you help this customer?”.  Based on the answer, try to put the candidate in a difficult situation by stating “yes, but let’s say the option you just described is shot down by your supervisor, or is against company policy, now what?”  Gauging the depth to which the candidate will go towards helping the customer to a solution that works for them and the company is a great indicator as to how deeply they will care about the features being built by the team.

Skills

One of the tenants of the Scrum framework is to have all the needed skills to complete the work on the team so that there are no external dependencies (and other reasons).    But what’s a good mix, and how to identify these team members?  First, don’t go for all superstar team members, the ones that can do anything and everything.  They usually don’t exist and, even if they do, are usually not what you really need.  Look for candidates that have demonstrated a high level of aptitude in learning new technologies rather than the one that has remained an expert in the same technology for many years.  In today’s business world, skill sets need to not only improve, but adapt to the latest and greatest, as well as have a knack for understanding what new technologies are worth pursuing.

Just like with the Personality aspect, make sure you set out a goal for what type of skill sets you want on the team.  If you need to have a high level of quality (medical devices comes to mind) over technical aggressiveness, than purposely build that team skill with a high level of quality driven candidates.  If you are building a fast paced team to research and prototype new products you will obviously want to go towards the candidates that can work within a “good enough” quality approach.  Most teams will be in an environment where quality and speed are equally as important, in which case you are looking to blend candidates of both mindsets together.

If you are building more towards the quality side you can ask questions such as this.  “We are ready to push the Deploy button but have found a defect in our code that can affect the user.  What would you do?”  If the candidate comes back with a ‘”Stop the presses and fix the bug”

Intangibles

Team work is everything in agile environments, and mixing in the right intangibles is so critical to taking a collection of individuals and helping them turn into a team.  I just finished watching “The Internship” (for the second time, good movie), where the main cha racters are accepted into the summer internship program at Google.  The whole movie is based on interns joining a team and having to succeed or fail as a team, the winning team will be hired on full time.  Sure, it’s a movie, and may not be all that close to reality, but I really like how they portrayed looking for ‘that Googliness’ in each potential candidate. 

Looking for these intangibles is, in most cases, the most difficult and the most important part of building a successful team.  Determine what intangibles are important to you by wide scope categories (since most intangibles found in an individual are usually unique) and devise ways that help you see those qualities.  The most important thing to remember is that the search for these intangibles is just as important as any personality or skills assessment you may apply to each potential team member.

What’s Next?

Just like building successful Scrum teams is an ongoing process, this blog will be a series of entries, each dealing with the next step in this journey.  Look for the next post that discusses pulling the team together, aka, Day One of the new team.