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

Story Telling with Story Mapping

Once upon a time, a customer had a great buying experience on a website.  The customer loved how from the moment the customer was on the site to the moment they checked out a product, the process was intuitive and easy to use.   The process and design of the customer experience was not by accident.  In fact, it was done very methodically using story mapping. 

What is Story Mapping

Story Mapping is both a visual practice that provides you with an understanding of how a user might use a feature and a decomposition practice that helps you consider how you may incrementally decompose an idea. Established by Jeff Patton, the visual portion helps the team understand the customer experience by imagining what the customer process might be.  This promotes the team to think through elements of what the customer finds as valuable. 

The decomposition portion allows the team to think through a number of options which represent pieces of work (e.g. epics and user stories) on how to incrementally build the feature to gain the most feedback from the customer.  This helps both validate the value of the idea and ensures the idea is being built in a way that provides the best customer experience. 

Benefits of Story Mapping

Story Mapping is a way to bridge the gap between an idea and the incremental work ahead.  It's a great way to decompose an idea to a number of unique user stories.  What are some additional benefits of story mapping?

• It moves away from thinking of functionality first and toward the customer experience first. 
• It provides the big picture and end-to-end view of the work ahead
• It's a decomposition tool from idea to multiple user stories. 
• It asks the team to identify the highest value work from a customer perspective and where you may want the most customer feedback.
• It advocates cutting only one increment of work at a time instead realizing that feedback from the current increment will help shape subsequent increments. 

Getting started with Story Mapping

How might you get started in establishing a story map?  It starts by having wall space available to place the customer experience upon.  Next you educate the team on the story mapping process (see below).  Its best to keep to a Scrum team size (e.g., 7 +/-2), where everyone participates in the process.  Then as a team, follow these high-level steps:

• Create the “backbone” of the story map.  These are the big tasks that the users engage with. Capture the end-to-end customer experience.  Start by asking “what do users do?”  You may use a quiet brainstorming approach to get a number of thoughts on the wall quickly
• Then start adding steps that happen within each backbone.  
• From there explore activities or options within each step.  Ask, what are the specific things a customer would do here?  Are there alternative things they could do?  These activities may be epics and even user stories. 
• Create the “walking skeleton”.  This is where you slice a set of activities or options that can give you the minimum end-to end value of customer experience.  Only cut enough work that can be completed within one to three sprints that represents customer value. 

As you view the wall, the horizontal access defines the flow of which you place the backbone and steps.  The vertical access under each contains the activities or options represented by epics and user stories for that particular area. Use short verb/noun phrases to capture the backbones, steps, and activities (e.g. capture my address, view my order status, receive invoice). 

Next time your work appears to represent a customer experience, consider the story mapping tool as a way to embrace the customer perspective.  Story mapping provides a valuable tool for the team to understand the big picture, while decomposing the experience to more bite size work that allows for optionality for cutting an increment of work.  Its another tool in your requirements decomposition toolkit.  

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.