Showing posts with label bounded authority. Show all posts
Showing posts with label bounded authority. Show all posts

Sunday, August 6, 2017

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:

Monday, January 18, 2016

Unlock the Power of Self-Forming Teams


A collaboration by Chris LeBlanc and Mario Moreira

It is quite possible that many teams in your organization are going through the motions of Scrum.  Per the Tuckman model, they are in the Norming phase of team group development, but are hard-pressed to break into the Performing phase.  This may be due to the team feeling a lack of empowerment and what it means to be Agile beyond the mechanics.  We are going to share a technique that can help bring your Agile organization to the next level, increase employee engagement and help make your engineers high performing and happier. This technique is relevant when you have a squad of 14 or more people who need to form into 2 or more teams.  

The common scenario in team formation is where a manager (or those who do not do the work) decides the team structure.  Managers have external knowledge of who may work well together and what skills they possess.  This is an educated guess at best.  Might we consider another approach?

By embracing the concepts of self-organizing teams and bounded authority, we ask those who actually do the work, the team members, to use their team internal knowledge of who they work best with and how their skills are able to complement the members of their team.  The result can be happy, high performing cross-functional teams composed of engineers that that want to work with each other.  For those experienced with the process of self-organizing teams, might it best start with the ability to self-form? 

May we introduce the Self-forming Teams starter kit!  This is a technique used to help engineers self-organize toward an engaged and effective team based on their current skill sets.  There are few steps that need to be completed by the leaders before you begin:

Create a vision of the work ahead.  This will give the engineers the information they need to understand who is best to work with based on their current skill set.

Set up bounded authority for the exercise.  The leaders can provide their bounded authority guidance on a few inputs to the exercise: mix of senior and junior team members and buy-in to this process.Everyone follows the bounded authority of the Scrum process as input: team size (7+/-), cross-functional skills (Dev+ QA)

An Agile Coach or facilitator to help guide the team toward their self-forming goals

Once the bounded authority and the vision are established, the Agile Coach or facilitator is ready to begin.  Here are steps to follow. Again, this is relevant when you have 14 or more people who need to form into multiple teams. 
  • Kickoff the session with sharing the self-forming goals with everyone. They include: Well-balanced teams who can successfully and efficiently complete any item in the backlog;  Long-term teams and can autonomously deliver value as fast as possible; Teams that understand skills needed on each squad and a learning path for the short term; Team members like the team they are on and the work they are doing
  • Conduct a connection Ice Breaker to lighten the mood of the session
  • Describe the definition of self-organization
  • Introduce the Product Owner and Architect to discuss the vision and any backlog input
  • Conduct a divergent conversation with everyone.  Ask “What skills will be needed to tackle the presented work from the backlog?”  Write down each skill given by the engineers.
  • Follow this with a convergent conversation that draws affinities between the skills to generate a list of Macros Skills each team would need (5-7 is a good number)
  • Ask each engineer to walk to the board and mark off each skill they currently have and each skill they want.
  • Now start the self-formation process.  Ask the engineers to self-form into teams, using bounded authority and the Macro Skills that were generated as guidance.  As the facilitator, move the conversation along when they become stuck.
  • Finally, nobody leaves the room unless everyone is happy with the team they are on.  Ask for a Thumbs Up / Thumbs Down vote from the group.  If there are any thumbs down, explore the reason and adjust the teams accordingly.

What we have seen to be true of self-forming teams is that knowledge workers who choose their own team structure are more invested in owning the health of the team.  When something is not working on the team, they are more likely to improve it. They are excited and happy to be on that team.  Healthy, happy people create high performing teams that build high quality products quicker.  Unlock the potential (and untapped power) of your teams and extend your ability to self-organize with self-forming teams.

To read more of Mario Moreira's articles, visit: http://cmforagile.blogspot.com/
To read more about Chris LeBlanc, visit: https://www.linkedin.com/in/chris-leblanc-47619a5