Good and Bad Reasons for Moving to Agile

There are various reasons behind moving to Agile. Some are proactive and some are reactive. Proactive motivations tend to be accompanied by a greater understanding of the business benefits of Agile and the culture change it implies. However, this is not always the case. The reasons behind the motivation can determine your chances to achieve a real transformation. Let’s take at a notional proactive-reactive model that looks at some motivations for moving to Agile and what you can do to enhance your chances of gaining the business benefits of doing so.  

• "It’s the trendy thing to do." Agile is popular, so we should do it. This is reactive and not a strong motivator for change. When another trend comes along, Agile may be abandoned. Agile may be seen as a hollow initiative and some may wait it out to see if it will go away. It will be important to investigate the benefits of Agile to see if it is right for you. Then determine if real commitment can be gained. 
• "The competition is doing it." Others are doing it, so we better do it. This is reactive. Although it may provide a driver for change, it does not provide clarity on why Agile was chosen. Some will question why what a competitor does is good for us. What happens when they do something else? It will be important to investigate the benefits of Agile to see if it is right for you. 
• "We need to reduce costs." This is a reactive and insufficient reason whereby Agile is seen as a tool to cut costs and maybe the workforce. This will not lead to the business benefits of moving to Agile. Although it may be an outcome, other benefits of Agile may be gained if you are willing to adapt the culture. 
• "What we have isn’t working." We’ve been using another process to deliver software and it isn’t effective. This is a reactive reason with little understanding of Agile, but it may provide an initial motivation for change. However, moving to Agile without understanding what it takes may lead to a failed deployment. It is best to understand the root cause for the failures in the past, because this can affect your change to Agile. 
• "We hope to increase employee morale." This is a proactive reason based on an understanding of the importance of employee engagement and empowerment to improve morale. Validate that there is real commitment to empowering employees and self-organizing teams. 
• "We hope to improve productivity." This is a proactive reason when the goal is to empower employees and help them improve productivity. The danger is that management may believe that Agile is something someone else must do to increase productivity or the real intent is to make employees work harder. The other challenge is that productivity may come at the expense of sacrificing quality. It will be important to investigate all of the benefits of Agile, not just productivity. 
• “We aim to decrease time to market.” This is a proactive reason in which Agile is seen as a way to shorten release cycles. If there is an understanding that this implies a change across the organization to get from market idea to release and it is meant to satisfy the customer, then this is a good starting point. It is still important to discuss the benefits of Agile to see if it is right for you. 
• “We want to deliver customer value.” This is a proactive and genuine reason if Agile is seen as a way to engage the customer and understand value. Validate whether there is a real commitment to delivering value and an understanding of the need to change organizational behaviors and processes to get there .
• “We believe in the Agile values and principles.” This is a proactive and genuine reason where Agile may be seen as a positive change in company vision and behavior. Validate a drive toward continuous customer engagement and employee engagement that can help gain the business benefits that Agile can bring. 

In all of these cases, you need to validate commitment to the values and principles and the culture and business change it entails. Once the initial motivation is understood, we can work to adapt it with the goal of better gaining the business benefits of going Agile.  

Top 5 ways to adapt your Agile Enterprise for a better Year ahead!

A New Year is upon us!  What is in store for 2018?  Better yet, what changes might you apply for a better Agile transformation and better business outcomes?  Here are a few to consider.

1) Focus more (much more) on the Agile mindset and the Agile values and principles.  Without this, people aren’t quite sure whey they are implementing the Agile mechanics (practices and tools).  Ask your employees if they know why they are applying the Agile methods and practices.  If they don’t really know, more strongly relate them to the Agile values and principles. 

2) Place Coaches high enough in to make a difference.  Placing them too low in an organization will give them little or no influence to change anything that matters.  Gauge your current placement of Agile Coaches and determine if they have the right access and influence to leadership.

3) Ensure leaders in your organization are educated in Agile.  Provide a combination of the Agile values and principles and Agile concepts, mindset, and practices that will help them support and lead an Agile transformation.  This includes understanding and establishing a high performing Agile workplace.

4) Focus on the employee side of Agile and what it takes to build a high performing team.  This includes establishing psychological safety, demonstrating servant leadership, creating a culture of self-organizing teams and even self-management, introducing continuous peer-to-peer feedback loops, and more. 

5) Become totally customer-value driven. Stop doing Agile for Agile’s sake and focus on the customer benefits.  Bring a customer mindset to Agile.  This means more closely identify with your customers (e.g., personas) and capture and apply more customer feedback along the way. 

I will go so far to say if you don't do anything else this year but these, you will have a stronger Agile enterprise that brings you more aligned with building high value products and services.  Give them a try!

Learn more by reading The Agile Enterprise.   

Outcomes Matter in an Agile World

The primary outcome of Agile is achieving better business results. This is why outcome based measures are much more aligned with Agile then output measures. Output measures focuses on how much you delivered, while outcome measures focus on the results of what you deliver.  It is the results (aka, the outcomes) that matter. 

Outcome based measures are drivers to help you understand business success.  You may still need some output measures to help you on your way.  Just ensure that they are relevant to help you determine if you are reaching the outcomes you are looking for.  The output could be the delivery of a release or the number of releases.  The outcome is how many customers either bought or used the product release.  Often times people focus on outputs because they tend to be easier to measure or are a carry-over from a more traditional mindset.  

The danger of focusing on outputs is that you may have a high number of outputs with a low number of outcomes.  Outcomes are what drive business success. As illustrated in the chart, it appears that the output of the 4th quarter is best.  However, if you look at the outcomes chart, the 3rd quarter is better with revenues of $80,000 instead of only $20,000 from the 4th quarter. While the output of four releases sounds good, $20,000 is not favorable to good business results. Outcomes  ask you to measure different things, with a particular focus on customer value.

In addition, an outcome focus changes our perspective from internal to a customer or external focus.  This helps us better understand what we are aiming for in the customer value-driven world we need to establish. So next time you are considering measures of success, just remember that outcomes matter!

Putting Self-Management into Action!

Applying self-management is a journey that requires deliberate steps. This article, the third in this four-part series on Self-Management explores those steps. The first article explains what is self-management, the second focuses on the difference between self-organization and self-management.  The fourth article shares the challenges in moving toward self-management.  Let’s explore some steps in applying self-management. 

Gauging your Readiness

The first step in approaching self-management is to gauge whether your culture is ready to accept self-management and if there is enough of a mindset that an experiment can be tried.  After all, it is a shift in mindset. Equally important is to gain agreement from your manager that the team can operate in a self-managed way.  This step shouldn’t be taken lightly, since if the environment is too traditional and not accepting of self-management or if you don’t have manager’s buy-in, then you may have some ground work to do before you can get this to happen. 

Leading with Education   

The second step in applying self-management is to understand what is and isn’t self-management (e.g., this can occur in parallel to the first step).  Begin education regarding self-management including what it is and what it isn’t. Consider reading part 1 (What is Self-Management and is it good for Agile?) and part 2 (The Difference between Self-Management and Self-Organization) of this series as a good place to start.

Learn the concept of Bounded Authority as this is a critical element for moving toward self-management.  This concept captures the essence of understanding your baseline of ownership and then allows you to better consider which activities to incrementally move toward the team.

Building your Self-Management Activities Matrix

Create a self-management matrix of those activities the team should own in the first column labeling it “Activities”.  This should include things like backlog management, planning, prioritization, stakeholder management, budget management, staffing, growth, performance feedback, vacation management, space management, guiding principles, and more.  

Then create two more columns to indicate who currently has that bounded authority for those activity.  The minimum bounded authority configuration is 1) the manager owns the activity and 2) the team owns the activity.  This may become more nuanced to 4 bounded authority configurations such as 1) the manager owns outright 2) the manager owns with team input, the 3) the team owns with manager input, and 4) the team owns outright.  There is also a more nuanced bounded authority configuration called the Delegation board by Jurgen Appelo with 7 bounded authority configurations.  I recommend starting with the manager and team columns.   

Understanding your Baseline of Ownership

The next step is to understand where you are right now with ownership. Once the activities and your bounded authority configuration are on your self-management matrix, identify where the current ownership of those activities live today (e.g., manager or team – bounded authority configuration).  This will help you understand where you are today. 

Progressing with an Incremental Approach

Applying an Agile mindset, I recommend an incremental approach in moving toward self-management.  This helps you focus on just a few areas where you think the team can benefit most and/or where it may be easier or more challenging depending on which approach you want to take.  

Discuss your incremental strategy.  Do you want to start with those activities that may be easier to move ownership from management to the team or those that are harder?  Also, determine how long do you want to experiment with this increment.

Now review your Self-Management Activities Matrix and identify 2 to 3 activities that you’d like to move toward self-management.  Discuss what it means to move an activity from manager to team.  This involves understanding what it means to own an activity and the details of an activity.  For example, if the team moves staffing from manager to team, the team should understand what is involved in staffing, who to contact, what processes are involved in hiring, how to get new staff on-boarded, how to get them a work space, computer, id, and more. 

Getting Started

Now it is time to get started.  Once you select the activities to move to self-management, begin the experimentation and adoption process of those activities.  Treat the self-management experiment as a real project or task as it takes time to adopt.  Have checkpoints along the way.  At the end of the increment, consider a retrospective to discuss how self-management and the adoption of the new activities are going (e.g., inspect and adapt).

-->

Finally, it is important to keep in mind that the manager plays an important role toward self-management.  They are effectively giving up control of the many activities listed on the matrix.  The manager will trust the team to methodically own the activities being moved, the team must ensure that it handles the activities with accountability.  Consider periodically communicating progress to the manager.  Remember that it isn’t always easy for a manager to give up ownership of activities so that team must appreciate and embrace ownership in a serious manner. Consider reading the rest of the Self-Management series:

• What is Self-Management and is it good for Agile - Part 1
• The Difference between Self-Management and Self-Organization - Part 2

What is Self-Management and is it good for Agile?

This is a four-part series on Self-Management.  This first article focuses on what is self-management.  The second article conveys the difference between self-organization and self-management.  The third article focuses on putting self-management into action.  The fourth article shares the ways to mitigate the challenges in moving towardself-management.  First up, what is self-management?

Self-Management is an alternative approach to management.  It moves away from the traditional structure of hierarchical management and moves the core management activities and work related activities to employees therefore effectively eliminates the manager role.  Typical management activities that move to employees include planning, organizing, staffing, directing and controlling (per Morningstar Self-Management Institute). 

A major change that must occur for self-management to be achieved is a shift in mindset.  People within the organizations that move to self-management must believe they both have ownership and accountability of the work and each other.  More importantly, relationships matter in self-management as there needs to be personal responsibility to each other. 

Self-management in context to organizations and corporations doesn’t mean people can do whatever they want.  Leadership defines the mission level 'what' and 'why' for the organization. Employees own the 'what' to work on and the 'how' to do the work, along with 'who' does the work.  It means that within the boundaries of the organizational mission or strategy, employees align the priorities, budgeting, planning, staffing and more around the work.   

Models similar to self-management include Holocracy, which is defined as a different way of operating an enterprise that moves power from a hierarchy management structure and distributes it across autonomous teams. Holocracy should have clear rules and definitions on what teams and individuals can do. 

It is recommended to start self-management with first understanding all of the types of activities that management would do so that they are understood and then adapted in a manner what allows for more of a distributed ownership of the activities. 

As self-management relates to Agile, it may be said that they are both mutually supportively of each other.  Agile works better when the bounded authority of many management decisions particularly regarding the work are pushed down to the team effectively reducing hierarchy.  Inversely in order to achieve self-management, it is supported by the Agile values and principles and the mindset it brings that is center around a strong focus on individuals and collaboration.

To read the second article in this series, go to: The Difference between Self-Management and Self-Organization. 

The third part of this series is titled: Putting Self-Management in Action!
The fourth part of this series is titled: Ways to Mitigate the Challenges of moving toward Self-Management.

--------------------------------------------  

To learn more about self-management, consider visiting the Morningstar Self-Management Institute website at: http://www.self-managementinstitute.org/about/what-is-self-management. 

The Power of Agile is in your Customers and Employees

I’m Agile, you’re Agile, everyone is Agile.  Or folks think they are.  But are they really? If Agile is only a process to you, Agile will fail. If Agile is pretending certainty without validating with customers, then Agile will fail. If Agile is commanded from above with little ownership from the team, Agile will fail.  More importantly, not only Agile will fail, so will your business.  Agile is a move to a lean culture focusing on customers and what they find as value and focusing on employees who are the engine that can create that value.  Agile is effectively about creating a thriving business. 

I believe there are the two primary success factors in creating a thriving business: a culture where customers matter and employees matter. I’m not talking about the lip service that is prevalent today. In some cases, we see quite the opposite, where employees are disenfranchised and customers are rarely engaged. Instead, the goal is to have a culture and practices in place that truly gain the benefits of engaging with customers and employees. Through the customer and employee, a company draws their power within an agile culture and, I contend, within any thriving company.

When you have a riveting focus on the customer and you believe that an engaged customer matters, then you have the basis for a relationship where you can truly understand what the customer wants. When you have a sharp focus on employees and provide them the space to make decisions and own their work, then you will begin to understand the value an engaged employee base can provide.

If the values are sincerely translated to organizational objectives and agile approaches are applied, then it can act as a differentiator between the success of your organization compared to the success of other organizations. Of course, every company likes to say that employees and customers matter, but are their objectives and actions really aligned with these values?

Upon closer inspection, the values should translate into objectives focusing on customer engagement and employee engagement.

• Customer engagement focuses on establishing meaningful and honest customer relationships with the goal of initiating continuous customer feedback to truly identify what is valuable to the customer. This includes establishing all of the activities involved in a Customer Feedback Vision.
• Employee engagement focuses on empowering employees so they can self-organize into teams and can own and be a part of the decision-making process at their own level.  When employees have ownership, they have more passion in their work.  When they have more passion, they give 110%. 

Then we add the “secret ingredient” of applying a continuous and adaptive approach (a.k.a. agile culture, processes, methods, practices, and techniques). If done properly with the ability to adapt, this can lead to an increase in customer sales and an increase in team productivity. This finally leads to your incentive, which is an increase in company profits.  

Now is time to take a moment.  Are employees disenfranchised or fully engaged?  Are customers rarely engaged or is their feedback continuously engaged?  Is Agile just a trend that others should do or are you serious about Agile and the culture shift it requires?  Keep in mind, the combination of customer and employee engagement within an Agile context isn’t just a good idea, it is great for business.  

PS - to read more about the importance of customers and employees, consider reading Chapter 3 of the book entitled Being Agile.  

Are Google’s OKRs compatible with Agile?

A collaboration by JP Beaudry and Mario Moreira

Recently, someone asked us if we thought that the Objectives and Key Results (OKRs) used at Google and applied at Intel in the 1970s is compatible with the Agile mindset. In order to refresh our understanding of OKRs, we reviewed the Rick Klau presentation on How Google sets goals: OKRs. After examining the characteristics of OKRs, and with a few open questions, we are of the opinion that for the most part, they can be used in support of the Agile mindset. 

To provide a basic understanding, OKRs is a technique for setting and communicating goals. The first part, the objective, is the outcome that is sought. While the second part, the key results, is comprised of 3 to 5 specific and measurable pieces of evidence of progress against the objective. OKRs can be cascaded and refined at various levels in an organization. In order to allow people to be bold and think big, the guidance is that only about two thirds of OKRs be completed within a given period of time. To promote transparency, everyone’s OKRs are publicly accessible and graded.

Now back to the key question – Are OKRs compatible with Agile?  Based on our examination of OKRs, here are some reflections:

Ambitious - By design, OKRs should only be met or succeed about two thirds of the time. This lines up well with the general desire for organizations to be more innovative. There is a broad agreement that innovation is inherently uncertainty/high beta, and that a certain amount of failure/learning is inevitable. A goal of imperfection makes it safe for people to take chances

Measurable - Measurable outcomes are critical in determining whether one is getting closer to the stated objective. This is well aligned with Eric Ries’ concept of Validated Learning. It also plays well with Mario Moreira’s framework of a Lagging-to-Leading metric path. 

Public - I’m sure the public display of OKRs does wonders for creating alignment on priorities. This is because it makes it so much easier for all stakeholders to notice, and more importantly correct, misalignments. So much the better if the full cascade from strategy to team-level user stories is visible in one place. 

Graded - Grading OKRs forces participants to confront reality. Without an explicit process step where results are confronted, it’s too easy to skip the learning step. Without the result-driven feedback, roadmaps cannot be updated.

Because we haven’t worked with OKRs on a sustained fashion at scale to date, we have a few open questions on how they would fit in an Agile environment:    

Individual or Team

At what point does the individual accountability get in the way of teamwork? Most Agile organizations spend a tremendous amount of energy creating high performing teams. It seems that individual OKRs could undermine teams

Local or Global Optimization

A corollary is how to prevent local optimization that could make top-level objectives more difficult to attain. Would OKRs promote a narrow view?

In summary, it seems to me that the Objectives and Key Results (OKRs) technique has several characteristics that make them compatible with Agile environments, and few obvious downsides. The fact that OKRs are also used at LinkedIn and Twitter seems to provide further evidence of their usefulness in innovative environments. 

If you have experience with how OKRs can be used in an organization that values Agile and the discovery mindset, please consider sharing.  Bonus points if you can shed some light on the open questions in the article.  

------------------

To read more of JP Beaudry's articles, visit: http://www.thepragmaticleader.com/   

To read more of Mario Moreira's articles, visit: http://cmforagile.blogspot.com/