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

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.