How Value Stream Mapping can help your Agile Journey

Would you be surprised to learn that many people who participate in getting an idea to market are not very aware of all of the steps it takes to get it to the customer?  People know their sliver of work well but when asked if they know where in the full process their slice lives, it can be a bit challenging to pin it down.  One solution is to apply Value Stream Mapping (VSM) to gain that end-to-end view. 

Value Stream Mapping is a lean method for mapping an end-to-end flow of a product or service from the idea to the delivery to the customer.  It represents all of the activities required to transform a customer request into a product or service.  More importantly it is a way to optimize your flow through understanding what the state is today and then incrementally improving it over time to reduce waste and achieve faster delivery.  It is a means to help you optimize the value being delivered to the customer by creating a value stream that indicates what is value and what is waste.

Having applied Value Stream Mapping a number of times, the first benefit is it makes people aware that they are part of a much larger value stream than they thought.  People start to realize that there are more upstream and downstream steps and interdependencies than they thought.  It can be quite an eye-opener for some. 

The next benefit is that it highlights the end-to-end flow of work, not just the development work.  Some folks like to highlight only the development work and fail to realize that there are activities occurring prior to and after development.  An example is that if you are applying a yearly planning process, an idea or customer request may sit in the planning pipeline for upwards of half-a-year.  This is a very slow way to get an idea to market.  An end-to-end view ensures we visualize the full picture starting with an idea or request and then understand the amount of time it can take to get it to market. 

Another benefit is that now we visualize the end-to-end view of the work, we can identify the value-added and non-value added steps as well as the waste (e.g., wait) states.  It becomes much easier to become aware of the value and non-valued steps and waste when the big picture is in front of us. 

And most importantly it provides us an opportunity to incrementally improve.  Now that we are aware of the end-to-end value stream and we know what steps are value and where is there waste, it is time to experiment with incrementally improving the process.  The primary goal of the incremental improvement is to increase the process cycle efficiency and reduce the lead-time from the idea or customer request to delivery. 

Process cycle efficiency is a number that represents the efficiency of your lead-time (concept to cash).  It is a summation of all value-added time divided by that same value-added time + all of the wait/waste time.  A process efficiency example is while the value-add steps takes 115 minutes and the full processing time takes 2275 minutes, then you divide 115 by 2275 or 5%.  The goal is to look for those incremental areas of improvement.  

How does this help in an Agile environment?  If a goal in Agile is to get an increment of value to market quicker, then by identifying waste in your end-to-end value stream, and removing it, can reduce the time to get that value to market.  Value Stream Mapping is yet another tool in your Agile toolkit.  Consider learning more about Value Stream Mapping and experimenting with it for incremental improvement.

Bounded Authority in an Agile World

Much is written about self-organization in an Agile world.  For some, the notion of self-organizing teams scares folks.  Does this mean that a team can decide everything?  Of course, the short answer is no.  I suggest the concern is due to not having boundaries for self-organization.  I call the framework for this context, bounded authority.  Bounded authority is defined by the information, experience, and decisions a group has control over within their context. Within a hierarchical structure of a company, bounded authority can work at multiple levels.  For simplicity, let us focus on the team level, middle management level, and senior management level. 

First, let’s spend a few minutes to explore what self organization means.  A self organizing team is a group of motivated individuals who have a common purpose, owns their work, and has the authority to make decisions on the work they are doing.  This means they can decide how to do the work (e.g., how to build the widget) and who will do the work (e.g., not assigned by a manager).  

Within an Agile context, the goal is to push decision making to the level in which the most information and experience dwells.  For a Scrum team, they self organize around the work in the product backlog that has been prioritized by the Product Owner.  Once that work is available at the team level, the team has the authority to make architecture, design, programming, and coding decisions and can self-organize around the work.

So if the team’s work is defined within the product backlog, what does middle management do?  Can they assign work to the team?  The short answer is that this is not within the bounded authority for the middle management since the team gets their work from the product backlog.  While the team self-organizes around the work, middle management helps optimize flow for their teams and enables the team to be its most effective. By optimizing flow for their organization and teams, this includes removing impediments for their teams to enable them to work faster.   Middle Management may also focus on helping their teams with their career management goals. 

Above the middle management are the senior management (or executives).  Should they be reaching down and telling the teams how to build the product?  To answer this question, another question should be answered.  Does senior management have more knowledge and experience in how something should be built or is this knowledge most known at the team level?  While the answer is the latter (team level), senior management has a bounded authority and duty to provide a strategy for the organization. This means they must help the teams understand the strategy and help them align strategy with their work.

Another example of bounded authority is relating it to your requirements hierarchy.  Consider who has the authority over the strategy, who has the authority over the ideas, who has the authority over the user stories.  This could be senior management who makes the decision to decide the top strategies, the chief product owners who makes the decision on prioritizing the ideas, the product owner who owns the decision to prioritize the backlog, and the and team who makes the decision on how to self-organize around the user stories.   

The key to bounded authority is that each level knows what they can self-organize around, what they have the authority to change, and areas in which they can make decisions.  Within an Agile context, that level of ownership and decision-making should be pushed down to the lowest possible level.  This can be an exercise that occurs at both the senior management and middle management levels, and in all levels within an organization. 

Have you Crossed the Agile Chasm?

In 1991, Geoffrey Moore refined the classic technology adoption model with an additional element he called the “chasm.”[1] He advanced a proposition specific to disruptive innovation that there is a significant shift in mentality to be crossed between the early adopter and the early majority groups. Disruptive innovation is the development of new values that forces a significant change of behavior to the culture adopting it. In this case, Agile is that disruptive force that insists on applying a set of values and principles within a specific culture of “being Agile” to be successful and for the organization to realize the full business benefits of Agile.

At first glance, it would appear that many companies have adopted Agile. I believe, however, that this perception is specious, in view of the further observation that the majority of companies that are “doing” Agile have not actually adopted the new values and principles and not made the cultural shift to actually “being” Agile. Such companies look at Agile as a set of skills, tools, and procedural changes and not the integrated behavioral and cultural change it truly is. In other words, they think they have crossed the chasm, but they have not made the significant change of behavior required to make the leap.

My experience in the field leads me to posit a refinement on Moore's chasm concept as applied to Agile. First, there is the real Agile chasm between those on the left side who have made the organic behavioral changes consistent with the values of being Agile―and those on the right side who are just doing” Agile mechanically. Second, there is a fake chasm, which many organizations pride themselves on having crossed by virtue of adopting some mechanical features of Agile, whereas they have not been willing or able to make the behavioral changes and adopt the values required to cross the real chasm. Although many companies say that they are doing Agile in some form, a large proportion of these are actually doing Fragile ("fake Agile") or some other hybrid variant that cannot deliver the business benefits of Agile.

I cannot overstate this point: many companies and their teams are mechanically doing some form of Agile without having actually crossed the Agile chasm, not discarding the behavioral baggage that is keeping them from behaviorally and culturally being Agile. Until a team attains the state of being Agile, the business benefits that Agile can provide will be elusive. I contend that the industry has barely entered the early majority of true Agile cultural transformation, and many companies continue to struggle to leap the Agile chasm.  What have you noticed across the Agile landscape?  Have companies crossed the Agile chasm?

Note: If you are looking for more insight in crossing the Agile chasm, consider reading the book Being Agile. This book lays the foundation for those who want to cross the Agile cultural chasm, understand the behaviors that need to change, and gauge progress along the way. It provides an Agile transformation roadmap to the destination of achieving better business results.

---

[1] Geoffrey A. Moore, Crossing the Chasm (New York: Harper Business Essentials, 1991).

Constellation Icebreaker - Getting to know you

How do you get a group of folks to quickly learn about each other’s common interests? Consider the Constellation icebreaker technique.  Constellation is used to identify to what degree people from a group agree or disagree with certain statements (which can be based on a belief, idea, or value). 

This icebreaker technique is an informal way to get people to share a bit about themselves at the beginning of a training session, workshop, or when a new team is forming.  It is a non-confrontation way of learning people's opinion on a topic or statement.  Within seconds of applying this technique, the participants will clearly tell you what they think of the statement. Its also a great way to connect people together since they will visually see who has their common interests and opinions. There are several types of constellation icebreaker techniques and here is how the Constellation Orbital Icebreaker game works:

The set up:  

• Identify a "center" of the room (or constellation).  This is the Sun.  The location of the Sun represents the highest degree of agreement with the statement.
• Optionally, use masking or blue paint tape to create dashed lines around the sun in 3 feet/1 meter increments away from the sun.   

The activity: 

• Ask everyone to stand on/around the Sun (aka., the center) - don't crowd too much
• Speak the statement, e.g., "I love the Red Sox" 
• Ask folks to place themselves either close to or away from the sun according to how much they agree or disagree with this statement (each person becomes the planet)
• Once everyone has placed themselves, ask some/many/all of the folks why they have placed themselves where they are

Its a great way to learn about people fairly quickly.  Have you tried the Constellation icebreaker before?  If so, what do you think?  Do you have another icebreaker that you have found of value to getting folks to learn about each other?    

Reducing Teamicide with Lightning Bolt shaped Teams

Teamicide is the act of purposefully disbanding a team after they are done with a task or project.  While this may not sound particularly negative at first glance, an organization loses the benefit of achieving team productivity and cohesion each time they disband a team.  When teams form, they take time to gel as a team. This is an organizational investment that often isn't realized. 

To gain some perspective, let’s take a moment to review Tuckman's model that discusses the gelling process.  Established by Bruce Tuckman in 1965, this model has four sequential phases (e.g., Forming, Storming, Norming, and Performing) that teams go through to effectively function as a unit, know each other's strengths, self-organize around the work, with optimal flow, and reduced impediments.  Regarding teamicide, if a team hasn't achieved the performing state, they will have invested in the time and team building effort without actually gaining the benefits of a performing team.   The irony is that while companies focus a lot on return on investment (ROI) regarding the product, they inadvertently achieve no ROI since they disband teams and not allow them to achieve performing.   

The next question is, why does management disband teams?  Do they not understand the harm they are doing to their organization when they disband teams?  Do they not respect the benefits of a performing team?  Or maybe they apply a move the team to the work approach when they really should be applying a move the work to the team approach.  Exploring the “move the team to the work” approach, this may occur because either there is a “form a team around a project” mindset or there is a belief that teams don’t have all of the skills or disciplines needed to handle the new types of work.   

How do we solve this problem and gain the most from performing teams?  The first change is to move to (or experiment with) applying the “move work to the team” method.   This assumes that we have teams that have the skills and discipline to handle a variety of work.  Therefore, the second change is to invest in building Lightning Bolt-shaped teams. These are teams where each team member has a primary skill, a secondary skill, and even a tertiary skill. 

The shape of a lightning bolt has one spike going deep (primary skill) and at least 2 additional spikes of lesser depth (secondary and tertiary).   The purpose of having various depths of skills is for the team to be able to handle a broad range of work and for team members to be able to step up and fill gaps that other team members may not have or need help with.  Note: some have used the term “T-shaped” teams, but I find that the lightning bolt shape is more appropriate to the several spikes of skills and the various depths that are needed.  

Creating a lightning bolt-shaped team takes an investment in education.  This takes a commitment to educate each team member in both secondary and tertiary skills.  As an example, let’s say that a developer has a primary skill of programming code.  As a secondary skill, they can also learn how to build database schemas and as a tertiary skill, they can write unit tests and run test cases.  The long-term benefit is that if the team members can develop additional skills, there is a greater likelihood that a team can work on a much wider range of work and be kept together allowing the organization to gain the benefits of a high-performing team.   This can reduce teamicide and increase the organization’s ability to produce more high-quality product.

Have you seen teamicide occurring in your organization?  Have you seen the benefit of allowing a team to remain together long enough to become a high-performing team?  If so, what level of skills were or are prevalent on the team?  

Agile Success Measures to answer the question "How do I know when I'm Agile"?

I often get asked, “How do I know when my company is Agile? ” While I have various answers, it led me to construct an Agile measurement framework that helps you guide your Agile transformation toward success.  

    

I start by asking, “What outcomes an organization would like to see when they go Agile?”  Agile asks that you consider your outcome instead of output as a measure of success.  I would suggest that being Agile should only occur if your outcome is some type of better business results.  In other words, Agile shouldn't be the outcome of being Agile.  The good news is that organizations are looking for better business results.  This could be in the form of shorter lead times, reduced whip, or an increase in revenue.  Sometimes it can be all three. It is important to understand that outcomes are lagging metrics.   Now that we have highlighted the importance of outcomes, let’s add two ingredients to give us perspective and help us build the framework.

For the first ingredient, I will take a page from the book Being Agile in Chapter 2 “Crossing the Agile Chasm”.  When we discuss Agile adoption, we are talking about a change to the organizational culture.  This is because adopting Agile is more than learning skills or understanding a procedure.  It is about adopting a set of values and principles that require change in people’s behavior and the culture of an organization.  This mindset and culture change involves the most time for an organization to adjust.  According to Paul S. Adler and Aaron Shenhar, “Adapting your Technological Base: The Organizational Challenge”, a culture change is measured in years.   

For the second ingredient, I will take a page out of the article Agile Lagging to Leading Metric Path.  This article highlights that an Agile lagging to leading metric path recommends that for every outcome (aka, lagging indicator), you supplement it with corresponding leading indicators that provide you with visibility during an Agile transformation.  Capturing the leading indicators helps you steer toward a successful Agile transformation.  The leading indicators are effectively feedback loops that help you understand if you are leading toward your outcome.

Now that we have the two key ingredients, the goal is constructing an Agile lagging to leading metric path that recognizes that change takes time and provides us with feedback to adapt toward a more successful Agile transformation.   Lets start with the outcome.  For my Agile transformation, the key outcome is that we are seeing better business results for our products, translated into increased revenue for our business.  From this, I need to consider what leading indicators help guide me toward better business results.   From my Agile transformation experience, I will suggest that the two broad leading indicators are adopting Agile mechanics and embracing the Agile mindset.   This is illustrated within this lagging to leading framework.

This illustrates several conventions.  The first is that from an Agile perspective, in order to get to better business results, we must educate folks on the Agile mechanics and Agile mindset.  As we do this, we gain feedback so that we can adapt the Agile journey to ensure more success in our Agile transformation and achieve the better business results we are looking for.  The second is that applying Agile mechanics tends to be easier and takes less time since it involves learning skills and understanding procedures.  Adopting an Agile mindset takes more time since it requires changes in people’s behavior and the adaption of the organizational culture.  The end result (outcome or lagging metric) is that we hope to see better business results by first implementing Agile mechanics and adapting to an Agile mindset. 

The last task at hand is to create measures within each indicator to gauge progress.  For the Agile mechanics, capturing a training metric is helpful.  In order for people to mechanically adopt Agile, they need some form of education in their role (e.g., Scrum Master, Product Owner, etc.) and education in the process (e.g., Scrum, Kanban, etc.).  Then you can assess if the mechanics are being applied.  If education doesn’t occur or the mechanics aren’t being followed, this can impact your success.

For the Agile mindset indicator, you need to gauge if there is a shift in ways of working. You can assess if the Scrum Master is exemplifying servant leadership, you can gauge if management are allowing for self-organization, you can assess if the team believes in the Agile values and principles, and you can determine if the product owner and organization are adapting to customer needs based on actual feedback and to delivering early and often.  You should also gauge if the team is incrementally improving the mechanics, meaning are they applying the retrospective for the team to improve their ways of working. If the behaviors behind the Agile mindset are not occurring, how do you expect to be Agile?   This is why they are all leading indicators to getting better business results. 

I hope this article may provide you with a framework to help you more effectively gauge “How do we know when we are Agile?”.  It highlights that if you are looking for the business benefits that Agile can bring, then establishing an Agile measurement framework based on lagging to leading indicators can help guide you achieve a more successful Agile transformation. It is then up to you to identify what is your outcome, then your leading indicators to know if you are heading in the right direction.  Many end their journey with adopting Agile mechanics without adapting their culture toward an Agile mindset.  Stopping at the mechanics is why many organizations fail at Agile.  Hopefully this framework can help you see the bigger picture toward Agile success and the business benefits it can bring.  

Agile Retrospective – the Gift that keeps on Giving

As we approach the holiday season and the new year, it may be a good time to celebrate our past success, understand where we may need to improve, and commit to where we want to go in the future.  Applying a “Year-in-Review Retrospective” can be a good way to do this.  This type of Retrospective asks you to reflect on the year (e.g., 2014), embrace what you are thankful for, and help you build meaningful and realistic resolutions for the new year. 

Borrowing a page from an Agile retrospective, here is a personal way to conduct a "Year-in-Review Retrospective".  It can be done individually, with your family, or any size cohort of people.   The 12th Agile Principle asks us “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”  This can be adapted to read “At regular intervals, we celebrate our successes, reflect on areas for improvement, and commit to resolutions to improve. “

Let’s begin by establishing a framework for applying the retrospective.  Let’s call this the Retrospective Starter Kit.   We start with creating a reflection (or retrospective) board.  This board should have a place to indicate “What I am Thankful for” (or “What we are Thankful for”), “What can be Improved”, and “Actions for Improvement”. 

Start with reflecting on what went well over the past year.  Document the successes and events and then put them in an order of significances or importance.  Then take a moment and celebrate what went well (maybe over a drink and with some music in the background).

Next, reflect on what was problematic over the past year.  Write each statement as a problem.  Avoid jumping to solutions (that will come next).  Once all problems are listed, prioritize which problems may be the most significant or challenging. 

Lastly, take the top 2 or 3 problems and consider actions for improvement.  You want to identify the root cause for each problem so that you establish a solution that addresses the cause behind the problem.  For example, if the problem is that “I am out of shape”, suggesting a solution of “I need to work out” may not be the only action.  Instead, applying root case techniques may uncover that you need to create time in your schedule first.  Otherwise simply saying that you should “work out” will be unrealistic.  Once you have identified actions, then you must commit to your resolutions (or actions that you identified).   

Over time, if you find the retrospective valuable, you may want to conduct this practice in an increasingly timely manner, possibly every month.  Within an Agile context, this occurs at the end of each iterative of work which could be weekly, bi-weekly, every three weeks, or four weeks.

Finally, in the spirit of giving, may I gift you with the following items:

• Agile Adoption Roadmap – this blog offers many helpful ways to implement and practice Agile to achieve an Agile mindset and receive the business benefits of being Agile. 
• Being Agile: Your Roadmap to a Successful Adoption of Agile – in 24 concise chapters, this book focuses on the business benefits of Agile and then introduces you to the Ready, Implement, Coach, and Hone (RICH) deployment model as a pathway to help you in your Agile transformation.     

Happy Holiday and Celebrate, Reflect, and Improve!