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. 

First, let’s spend a few minutes to explore what self organization means.  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.  This means they can decide how to do the work (e.g., how to build the widget) and who will do the work (e.g., not assigned by a manager).  

Within an Agile context, the goal is to push decision making to the level in which the most information and experience dwells.  For a Scrum team, they self organize around the work in the product backlog that has been prioritized by the Product Owner.  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 how something 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, and in all levels within an organization. 

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, Prioritization, 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. 

Agile Adoption Roadmap blog - over 500,000 views!

The “Agile Adoption Roadmap” Blog has just topped 500,000 visits on December 31, 2020*.  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 55 different countries that have visited my site.  The top 10 countries include: United States, United Kingdom, India, Russia, Germany, Canada, France, Australia, Ukraine, and Sweden. Other countries that have significantly visited my site are: China, Poland, Spain, Finland, South Africa, Iran, Norway, Iraq, Romania, Brazil, Argentina, Belarus, Israel, Malaysia, Portugal, Netherlands, Switzerland, Colombia, Mexico, Nigeria, Taiwan, Algeria, Tunisia, United Arab Emirates, 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 100 articles to date.   What are some of the top articles that Agile, IT, and Business Professionals have found of value?  The top articles include:

• The Forgotten Agile Roles - The Customer
• Story Telling with Story Mapping
• What really is an Agile MVP? 
• Who makes the best Scrum Master
• Agile Animal Farm – Pigs, Chickens, and more
• Agile Value Capture Metrics – Are you building value?
• Right-sizing Documentation in an Agile World
• Agile Definition of Done Starter Kit
• Agile – Its more disciplined than you think
• Gamification of your Agile Journey
• Agile Culture – Are you stepping up?
• The Role of Middle Management in an Agile World
• Are you Ready for your Agile Journey?
• Agile Executive Playbook
• Robust Agile Requirements – Its about the Discussion
• Is it finally time to “Be Agile”?
• Personas – Do you really know your Users?
• User Story Writing Starter Kit
• Agile Lagging to Leading Metric Path

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!

* I reached 200,000 hits on June 23, 2016 and I reached 100,000 on October 26, 2014 so this is good progress.  

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.  

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. 

Is it finally time to “Be Agile”?

As I look across the Agile landscape, I am worried that Agile has become little more than a superficial tag that some teams and companies seek without really aligning with the cultural shift that is needed to truly become Agile.  What I mean by this is to really align with Agile, it means to understand and embrace the Agile Values and Principles.  While this sounds obvious, I believe there is such little focus on the values and principles and much more so on the mechanics. 

I have hypothesized that those involved in Agile are more knowledgeable about the mechanics of “doing Agile” than understanding the cultural aspects needed for “being Agile”.  My specify hypothesis stated that I believe fewer people could name 3 of the 12.

As I look across the Agile landscape, I am worried that Agile has become little more than a superficial tag that some teams and organizations seek without aligning with the real cultural shift that is needed to truly become Agile.  What I mean by this is to really align with Agile, it means to understand and embrace the Agile Values and Principles.  While this sounds obvious, I believe there is such little focus on the values and principles and much more so on the mechanics. 

I have hypothesized that those involved in Agile are more knowledgeable about the mechanics of “doing Agile” than understanding the cultural aspects needed for “being Agile”.  My specify hypothesis stated that I believe fewer people could name 3 of the 12 Agile Principles, then could roughly name 3 of the 5 Scrum events (i.e., Sprint, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective).  In order to make my hypothesis meaningful, it was important to test it. 

With that in mind, I established an experiment that tests if people can articulate the Agile principles and if they can articulate the Scrum events.   I created a simple survey that asked Agile participants to write down as many of the five Scrum events that they knew and then write down as many of the twelve Agile Principles they knew.  I distributed this survey to two different Agile professional events and accumulated over 100 survey responses (109 to be exact).  The results were quite revealing and support my hypothesis.  Of the 109 Agile participants: 

• 59% knew 3 or more of the five Scrum events
• 11% knew 3 or more of the twelve Agile principles

I actually find these results quite astounding.  Could it really be true that only 11% of Agile professionals and enthusiasts could name just 3 Agile principles?  I don't mean they they memorize them but can provide at least the key words of the principle.  This means that 89% could only name 2 or less.  What makes this even more astonishing is that 67% could not name even a single Agile principle (and I did give credit to those who could name the key words of the principle - e.g., self-organizing,  frequent delivery, etc.). 

In reviewing the survey results, about half of the 67% confused the Agile principles with the Agile Values (e.g., Individuals and interactions over processes and tools).  On the flip side, 59% could name at least 3 of the mechanical Scrum events.  Here are two charts that illustrate the number of respondents that could name a certain number of Scrum events and Agile principles. 

Based on this data, my concluding hypothesis is that the reason there is such a lack of awareness of Agile principles is that there is very little education focused on the Agile principles.  This is particularly concerning since the principles form the basis for what an Agile culture should look like. A simple way for each and every one of us to test this hypothesis is to ask these two questions:

• How many Agile principles can you name?  Is it 3 or more?
• How much Agile related education have you have received and how much of it was focused on the Agile principles? 

Now do keep in mind, knowing the principles is just the first step and it doesn't make you Agile. Next its time to live it.  But how do we expect to “be Agile” if our focus is so much more focused on the mechanics or “doing Agile”.   I would suggest that anyone who claims to be an Agile enthusiast ought to periodically bring their work back to the Agile values and principles.  Maybe its time to revisit the values and principles and understand what it really takes to be Agile.

A great Agile book - Being Agile: Your Roadmap to a Successful Adoption of Agile

Being Agile is your roadmap to successfully transforming to an Agile culture. In this unique book, veteran Agile Coach Mario Moreira advises new and current adopters how to implement a robust Agile framework that emphasizes Agile values and principles over the mechanical elements. This book focuses on the business benefit of implementing Agile which focuses on delivering customer value and having a positive impact on revenue. 

This book begins by explaining that in order to truly cross the Agile chasm, there must be a transformation to the Agile culture that focuses on delivering customer value.  Mario shows maturing early adopters how to bridge the chasm between going through the motions of “doing Agile” and genuinely “being Agile.” 

It then delves into the business benefits of Agile and the often missing discussion that Agile supplements your strategy to help your business succeed.  The book highlights the important objectives of customer and employees matter, another area that often is underserved.  It briefly discussions some of the methodologies (including Scrum, Kanban, DSDM, Lean, VFQ, and XP), and the roles a team and organization can play within an Agile context. 

After a high-level synopsis of Agile, Mario reminds us that Agile is nothing more and nothing less than a set of values and principles.  This book delves deeply into a focus on the Agile values and principles.  This book dissects each value and principle that conveys whether they are really exhibited within a culture.  These values and principles must be observed, believed, and translated into actions as an important to precipitate a cultural shift. The book emphasizes the importance of keeping the values and principles always in mind.

The author then plunges into the nitty-gritty of the deploying Agile in a manner that will better achieve an Agile transformation.  He does this by introducing the reader to the Ready, Implement, Coach, and Hone (RICH) Deployment model.  The rubric of readiness engages and begins conditioning the mind toward the Agile mindset as well as focusing on the areas that need to be considered as you are embarking on your Agile journey.  He asks you to consider such factors as:

·         Evaluating team candidates for skills, behavior, and willingness 

·         Assessing Stakeholder buy-in and engagement

·         Determining Suitability for applying Agile

·         Identifying measures to see if you are Agile and if you are deriving the business benefits

·         Establishing a customer validation vision to engage in the critical customer feedback

·         Implementing Agile roles and identifying those best for these roles

·         Establishing an adaptable and scalable Agile framework

·         Determining your User story writing and grooming approach

·         Understanding story points for sizing and establishing a relative sizing framework

·         Establishing Educational needs and building an Agile community

·         Constructing Done criteria and how it helps with quality

Implement focuses on the timely application of agile elements within a team or organization while still maintaining emphasis on the Agile values and principles. Coach focuses on on-boarding teams, coaching teams and management through initial implementation, grooming in-house talent, ensuring Agile values and principles are a focus, while acting as a navigator on the path to Agility. Hone emphasizes the inspect-and-adapt model where periodically the current state is reflected upon and opportunities for improvement identified and acted upon.

This book is geared toward Agile Coaches, Scrum Masters, Product Owners, Team members, product managers, project managers, middle, senior, and executive management in software engineering and development divisions and enterprises.  Learning opportunities include:

·         Comprehending Agile values and principles with an in-depth discussion on each principle and how they may be exemplified within an Agile culture.

·         Advocating a framework in which values, customer engagement, employee engagement, and an Agile framework can lead to an increase in sales and productivity, incorporated in the Agile Value to Incentive Differentiator (AVID) framework.

·         Presenting a methodical yet adaptable approach toward Agile transformation, encapsulated in a Ready–Implement–Coach–Hone (RICH) deployment model that can help establish an adaptable roadmap toward your Agile destination.   

·         Introducing the importance of an Agile Customer Validation Vision that emphasizes a disciplined approach to engaging customers and gaining their valuable customer feedback

·         Providing a mechanism for evaluating your level of alignment to the Agile values and principles, encapsulated in the Agile Mindset Values and Principles (Agile MVP) Advisor.

·         Promoting a special focus on value-added work (VAW) that features customer work as valuable and an accompanying value capture metric.

·         Introducing Gamification concepts to engage and motivate employees toward Agile behaviors with the goal of achieving an Agile transformation

·         Advocating a change in your IT governance toward collaborative governance and performance review process places a focus on team rewards. 

This book ends with three case studies—stories of a smaller colocated project, a medium distributed project, and a large distributed team—to help you understand how the readiness activities, deployment approach, and commitment to Agile lead to different results. This book can help you focus on truly “being Agile” and gain the business benefits of doing so.  What will your case study look like?  Let this material in Being Agile help you achieve a successful one.

Agile’s Little Secret – It Makes You Money

Agile tends to be introduced at the team level and it’s the Agile teams who are expected to adopt Agile.   While there is various amounts of buy-in from management, some don’t seem to understand that it takes an organization to embrace Agile in order to gain the business benefits.  In other words, management has a strong role to play including adapting their behavior, embracing the Agile values and principles, and leading a culture change, in order to gain the business benefits of Agile.  It requires significant buy-in to achieve a culture change.  But this doesn’t always seem to happen. 

Some of this is not management’s fault.  Part of the issue is that Agile gets introduced to them is various ways – as a way to improve productivity, as a way to speed up development, as a way to increase quality, but in most of these cases, those introducing Agile to them fail to mention the significant buy-in they need to make.  While each of these ways have different levels of merit, it often doesn’t convey enough of a reason for management to motivate a change in their behavior and their organizational culture.    

   

How about changing the message?  Though there are many benefits for going Agile, it occurred to me that to get serious executive/senior management attention and buy-in to Agile is to give them a reason that is near and dear to their heart.  Explain to your management that Agile can increase revenue—in short, it can help them make money (or more of it).  In my experience, this gets them to actively listen, versus the passive listening they may exhibit when they think Agile is an engineering method or something the engineering team and others must do.

Yes, Agile can lead to an increase in customer sales, ergo an increase in revenue. This is all true if the organization is truly allowed to “be Agile”.  This means that teams continually demonstrate working software to customers and they are allowed to continually adapt their requirements to customer needs.  Then teams can more closely align with what customers find as valuable.  The more value customers see in your products, the more likely they will buy (or buy more).  Maybe, just maybe, if you convey that Agile can make them more money, they will listen and buy-in to what it really takes.     

You may be FrAgile if...

Moving to the Agile can be challenging.  It implies a behavioral change to the Agile mindset supported by the Agile Principles found in the Agile Manifesto. However,  many find themselves in the land of FrAgile (i.e., fake Agile), Scrumbut (i.e., we are doing Scrum but not some of the practices), Scrumfall (i.e., some elements of scrum within a waterfall lifecycle), and even Kantban (i.e., Kanban without respecting the queues). 

What is FrAgile? This is where there either isn't really a commitment to go Agile, there isn't an understanding of what "being Agile" means, there isn't the talent like an Agile Coach to help bring about that change, or an incremental deployment approach stalls along the way. And most importantly, frAgile is when Agile very quickly becomes brittle, lacking in vigor, and shatters once there is tension applied leading to a regression to past ways of working.    

When "Fragile" happens...

Some may ask, “why do I care if Agile is not quite right”.  When a form of Fragile is applied, you will not gain the business benefits of aligning better with customer value and the many other benefits Agile can bring. When you see that you are not gaining the business benefits of Agile, instead of blaming Agile, look to see how you have implemented Agile and whether you are really aligning with its values and principles. 

In honor of Jeff Foxworthy and his "You might be a Redneck if" routine, I thought I would adapt his saying to fit the Agile message of this article.  I present several areas which can be problematic if they are not in place and you are serious about Agile.  So without further ado, "You may be FrAgile if": 

• ...you do not want to hire or identify a Product Owner (or similar) who works with both the customers to gather requirements and Engineering team to describe the requirements in more detail.  The result is that there engineering will build what they think the customer wants and then you will wonder why the customer doesn't want it.  
• ...you continue to have the Project Manager or Functional Manager assign the work to the Team.  The result is that your team will not be self-organizing and you will wonder why your team members are not engaged.  
• ...you continue to collect your requirements upfront and lock them in for the remainder of the project.  The result is that you may build the wrong thing for the customer and you will wonder why the customers are not very excited about the release and few are buying or upgrading to it. 
• ...you do not want to have a healthy balance of test/QA minded folks on the team.  The result is that the testing activities will become the bottleneck or worse yet, the testing aspects will become watered down (i.e., skip testing steps), ergo releasing a product with low quality and subject to many defects.  
• ...you mechanically know how to do the Scrum and XP events and practices but can't remember any of the Agile values nor any of the 12 Agile principles.  

Let me know what you think about the results of "You may be FrAgile if".  If you believe there are other Fragile, Scrumbut, Scrumfall, Kantban, and other related Agile challenges that could be non-starters or significantly impact the ability to "be Agile", please feel free to share.