Showing posts with label values and principles. Show all posts
Showing posts with label values and principles. Show all posts

Sunday, January 25, 2015

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.  

Sunday, September 7, 2014

Are you Ready for your Agile Journey?

The common pattern in approaching an Agile implementation 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. It emphasizes collaboration, customer centricity, adapting to the market, and more. Although it is important to lead with readiness, this framework may be used iteratively depending on whether you plan for a more holistic implementation 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 mechanics or learning a new skill.  A culture change is a transformation in belief and behavior that we learn our way toward value.  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) implementation framework specifically focusing 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. Essentially you are being asked if you are ready to be an adaptive organization who recognizes that customer needs and market conditions change regularly. 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 business benefits that agile brings
  • Gauge the team and management willingness

Readying the mind should not be taken lightly. It is important to understand the ‘what’ and ‘why’ prior to discussing the how and when.  It is important that 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 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 and your company will more easily derive the business benefits that agile can bring.  

Since there is already an overwhelming amount of material that focuses on “how to implement Agile” from a "doing" perspective, may I suggest 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