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 looses 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.  

Sunday, December 14, 2014

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!

Sunday, November 16, 2014

Agile Education Engine - Bringing Power to your Agile Transformation

When I look across the numerous Agile deployment efforts, I see a lower rate of success in achieving the business benefits than I would expect.  May I suggest that in order to improve the odds of achieving Agile success and gaining the business results it can bring, there are three success factors. The first is that the Agile change must be thought of an organizational level change.  The second is that the Agile change must focus on getting the mind Agile-ready.  This is emphasized in the article Are you Ready for you Agile Journey.  And the third is that in order to bridge the gap between the Agile values and principles to Agile methods and practices, people need to be well educated in ways to build more customer value, optimize the flow of work, and increase quality with feedback loops.    

The current level of Agile education tends to be limited to 2-days of training and a variety of books.  I think most people will acknowledge that 2 days of Agile training does not provide enough learning.  On the other hand, reading lots of books takes a lot of time and are often not aligned with each other.  The other challenge with some of the Agile education is that it is often focused only on implementing the mechanics.

What is missing from many Agile transformations is an Agile Education Engine that helps you truly understand and embrace Agile and helps bridge the gap between Agile Values and Principles and the Agile methods and practices.  This will help folks better understand how to understand, embrace, and implement Agile and move beyond simply following the Agile mechanics of the methods and practices.  The Agile Education Engine can help ready the mind for an effective transformation.  


One of the best Agile education engines that I have seen is the material found in the Value Flow Quality (VFQ) work-based education system.  VFQ provides a set of well-researched topics that are easily digested in the form of readings, case studies, activities, and experiments.  It provides students with the ability to study a little, then experiment a little within their own context (aka, project or team).  The benefit of the VFQ work-based learning system is that it helps people apply their newly learned skills on the job when they need them.  This bodes very well for the learners because, they can learn at their own pace and as they are trying to implement the Agile values, principles, and practices. 

Some topics that VFQ offers are: Why Change, Optimizing Flow, Feedback, Requirements, Priorisation, Trade-offs, Understanding your Customer, Delivering Early and Often, Teams, Motivation, Attacking your Queues, Work in Progress, Trade-offs, and more.  Each topic includes a number of techniques that will help you achieve the business outcomes you are looking for.  The VFQ materials will provide you with knowledge on Value Stream Mapping, Story Mapping, Cost of Delay, 6 Prisms and much more.   

In addition, VFQ really helps you get to the state of “being Agile”.  It moves you away from thinking about the mechanics.  Instead, it provides you a layer of knowledge in a critical thinking manner to ensure you apply the principles and behaviors to the practices to gain the outcomes that you want.  Finally, applying the VFQ education is also an excellent way to kick-start an Agile transformation.  This way, the Agile champions for the transformation and teams are armed with a variety of different ways to bring Agile to the organization. 

If you find yourself struggling with getting a good baseline of Agile education, then consider the Value Flow Quality (VFQ) work-based learning system.  It will help you bridge the gap between the Agile values and principles and Agile methods so that you bring the Agile mindset to bear as you start or continue your Agile journey. 

Sunday, October 26, 2014

Agile Adoption Roadmap blog - over 100,000 views!


I am very pleased to announce that my “Agile Adoption Roadmap” Blog has just reached 100,000 hits.  This is a great milestone and it makes me happy that there are so many professionals curious about Agile including many Agile enthusiasts, advocates, champions, coaches who are visiting and even commenting on my articles.  It highlights that the many articles have value.  If you want to receive its value, consider following this blog at: http://cmforagile.blogspot.com/ 

To add to the statistics, I have folks from 45 different countries that have visited my site.  The top 10 countries include: United States, United Kingdom, India, Russia, Germany, Canada, France, Australia, Ukraine, and China. Other countries that have significantly visited my site are: Sweden, Poland, Spain, Finland, South Africa, Iran, Norway, Iraq, Romania, Brazil, Argentina, Belarus, Malaysia, Portugal, Netherlands, Switzerland, and Italy.

The Agile Adoption Roadmap blog provides the reader with a range of topics related to adopting Agile within their teams and organizations.  The content has a special emphasis on “being Agile” and bringing the Agile mindset to your work.   I have written and posted 56 articles to date (although this one technically counts as the 57th).   What are some of the top articles that Agile, IT, and Business Professionals have found of value?  The top articles include:
Next time you are looking for Agile material to support you Agile Journey or you are looking to learn what it means to “be Agile”, look no further.  Consider reading the articles and following the blog.   Thank you!

Sunday, October 12, 2014

Building the Agile Culture you want

When some organizations think of going Agile, they tend to gravitate toward applying a set of Agile practices.  While this provides insight into the mechanical elements of agile, these types of implementations tend to overlook the cultural elements.  A move to Agile implies that you make the cultural transformation to embrace the Agile values and principles and put them into action. 

Adapting an organization's culture is effectively an effort in change management.  And changing a culture is hard. People underestimate the difficulties of a culture change within their organization because it involves the cooperation of everyone. This is why some organizations avoid this.  But the business benefits can be tremendous. 
I have seen Agile efforts get started with poorly stated objectives and motivations, a lack of employee ownership or engagement, and a lack of thinking through the effort. Also, Agile journeys significantly benefit from education in both change management and agile techniques to achieve a meaningful cultural change. I have seen companies assign a member of senior management as the change agent, yet they have neither education nor experience in change management. A better approach may be to hire an Agile Coach with change management and Agile experience.

Creating or adapting a culture is not done by accident. It must be considered a change initiative and thought through. As part of readiness of deploying Agile, start the process of adapting to an Agile mindset and the culture you are looking for. What are some activities that will help you move to an agile culture?  Some include:
  • Recognizing that moving to Agile is a cultural change (it’s a journey)
  • Sharing and embracing the Agile values and principles (seriously folks!)
  • Moving to an end-to-end view of delivering value (don’t stop at just the build portion)
  • Adapting your governance to focus on value (enough with the cost, schedule, and scope!)
  • Evaluating employee willingness (employees are your brainpower!)
  • Gaining continuous feedback from customers (adapt toward customer value)
  • Adapting the reward system to align with the new culture (toward team and value)
  • Assessing executive support (build engagement along the way)

What other activities would benefit you in getting to an Agile culture?  Ultimately you want to start living the values and principles that help you develop the culture you are looking for.  As you have approached Agile in the past, how much of it was focused on the mechanics and how much was focused on adapting to an Agile culture? 

PS - to read more about really making the shift toward an Agile culture, consider reading the Agile book entitled Being Agile.  

Sunday, September 7, 2014

Are you Ready for your Agile Journey?

The common pattern in approaching an Agile deployment is to begin by conducting Agile practices training typically on Scrum or another Agile method.  While this will allow the team to begin mechanically applying Agile practices, it doesn’t address the culture shift that must occur, a culture shift that helps to inform the mind and shape behaviors, a shift toward "being Agile".  I term this approach of focusing on the cultural aspects of Agile as “readiness”. 

Readiness is the beginning of the process of acclimatizing the mind toward Agile values and principles and what they really mean.  It includes making decisions on the elements for your implementation. Although it is important to lead with readiness, this framework may be used iteratively depending on whether you plan for a more holistic deployment or iterative deployment of certain elements.
This first starts with the premise that Agile is a culture change.  The implication is that Agile is more than a change in procedure or learning a new skill.  A culture change is a transformation in belief and behavior.  It requires a change by more than one person, and instead by a number of people within your organization.  As you can guess, this takes time. 

Over the years, I’ve established what I term the Ready, Implement, Coach, and Hone (RICH) deployment framework specifically focuses on readiness activities that help you prepare not only to adopt the mechanical aspects of agile practices but more importantly, begin a meaningful transformation of behavior toward an Agile mindset. 

Readiness starts the moment someone asks the question, "Is Agile right for me?” The goal is to work through this question, understand the context, and figure out how Agile might be deployed. Readiness can start weeks and even months before you really get serious about moving down the agile path. However, it can also begin when you are ready to commit.

What are some of the “readiness” activities?  These activities can help you shape the implementation according to the context and need of an organization. Readiness provides us with an opportunity to:
  • Assess the current environment and current state of agility
  • Lay the educational groundwork of agile values and principles
  • Understand and adapt to self-organizing teams and away from command and control
  • Shift the focus to delivering customer value and away from an iron triangle mentality
  • Discuss the agile business benefits
  • Gauge the team and management willingness

Readying the mind shouldn’t be taken lightly. It is important to understand the ‘what’ and ‘why’ prior to discussing the how and when.  It is important that the teams understand and really embrace the Agile values and principles.  Does senior management believe in the principles?  Do the teams feel they can operate in an Agile manner that aligns with the values and principles?  In fact, I will dare say that if the team acts in the manner that expresses the Agile values and principles and forgoes the mechanical application of agile practices, then there is a greater chance that Agile will survive and thrive within a company.  

Since there is already an overwhelming amount of material that focuses on “how to implement Agile” from a "doing" perspective, may I suggest that a different approach.  Provide the time to prepare the mind toward the Agile mindset and then incorporate this mindset into the culture, education, and decision-making process for your proposed implementation. With that goal in mind, let the readiness games begin!  How ready are you?

To read more about the importance of readiness and additional readiness activities in detail, consider reading the book Being Agile