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? 

Sunday, January 25, 2015

Agile Success Measures for your Agile Transformation

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 be followed, this can impact your success.

As for the Agile mindset indicator, 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 delivering early and often.  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.