Sunday, June 21, 2015

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.

Sunday, May 10, 2015

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. 

But first, let’s spend a few minutes to define what self organization means at a team level.  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.  Within an Agile context, the goal is to push decision making to the lowest possible level and to the level in which the most information and experience dwells.  For a Scrum team, they self organize around the work that has been prioritized by the Product Owner that lives within the product backlog.  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 what 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. 

Sunday, April 19, 2015

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 Agileand 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).

Sunday, March 22, 2015

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 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.  Here’s how it 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?    

Sunday, February 22, 2015

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 team cohesion each time they disband a team.  When team’s 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.  In relation to teamicide, if a team hasn't yet 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) in relation to the product, they inadvertently achieve no ROI since they disband teams and not allowing 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 method, when they really should be applying a move work to the team method.  Exploring the “move team to the work” method, 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.   

So how do we solve this problem and gain the most from performing teams?  The first change that must be made 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 disciplines 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 lightening bolt has one spike going deep (primary skill) and at least 2 additional spikes of lessor 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 apropos to the several spikes of skills and the various depths that are needed.  

To create a lightning bolt shaped team, takes an investment in education.  This takes a commitment to educate each team member in both a secondary and tertiary skill.  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 then they can 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?