What Color is receptive to Agile?

In Frederic Laloux’ book “Reinventing Organizations”, he describes organization paradigms as an evolution in human consciousness.  Examining these paradigms can provide insight into organization attributes that lend themselves to an Agile culture.  The early paradigm starts with the Reactive-Infrared paradigm and then Magic-Magenta paradigm.  Both of these embody the early stages of humankind which include smaller groups such as tribes of people.  This is followed by the Impulsive-Red paradigm which has the guiding metaphor of a wolf pack illustrated by tribal militia, mafia, and street gangs. 

The Conformist-Amber has the guiding metaphor of an army illustrated by a church hierarchy, military, and most government agencies.   Next is the Achievement-Orange which has the guiding metaphor of the machine illustrated by multinational companies and charter schools.  A majority of the organizations today tend to reflect a red, amber, or orange paradigm.

From an Agile perspective, it is after this where it becomes interesting.  A general alignment can be made to two of the latter paradigms that may be considered as behaviors you would hope to see in an Agile enterprise. These are the Pluralistic-Green and the Evolutionary-Teal paradigms. 

The Pluralistic-Green organization strives to bring equality where all viewpoints are treated equality irrespective of position and power.  It uses the family as the guiding metaphor where we are in it together and help each other out. One of the breakthroughs of a green organization is Empowerment. Empowerment is focused on pushing a majority of decisions down to the frontline (e.g., where the work is).  This is directly aligned with Agile thinking where there is a focus on pushing down decision-making to the lowest possible level where the most information resides regarding the topic.  

Another breakthrough of a green organization is that it is a values-driven culture. This very much aligns with the importance of leading with Agile values and principles. The green organization understands that a shared culture where leaders play by shared values is the glue that keeps those in organizations feeling appreciated and empowered that can lead to extraordinary employee motivation.  

The Evolutionary-Teal paradigm emphasizes that the organization adapts as circumstances change. Its metaphor is one where the organization is a separate living organism. In a teal paradigm, titles and positions are replaced with roles, where one worker can fill multiple roles. This is very much like the concept of the cross-functional team within an Agile structure.  This paradigm emphasizes the capability to self-organize around the organizational purpose.  The hierarchical structures are replaced with self-organization focusing on the smaller teams. This is aligned with the Agile principle of self-organizing teams (aka, the best architectures, requirements, and designs emerge from self-organizing teams).  

To read more about how the colors of Pluralistic-Green and Evolutionary-Teal can benefit an Agile journey, consider reading The Agile Enterprise: The Agile Enterprise: Building and Running Agile Organizations. You can also learn more about colors of organizations by reading Reinventing Organizations. 

Visualizing your Team with the Team Constellation

Your team is real. It is made up of real people that support each other toward common goals. We often get so engrossed in our work that we forget the important connections and relationships across and beyond a team. What really is a team?  Emergn defines a team as having a shared purpose, compelling direction, complementary skills, shared responsibilities, and common performance goals. It is important to imprint the team in a visual way.  Equally important for a team to visual themselves is for those that support the team to be visually connected.  

One way to envision a team is through the visual Team Constellation.  The team constellation is a visual way to share who is on the team and who may contribute to the team.  The question is how to create the constellation? If you have a team room or area, you can construct one on a white board or on large poster paper, although in either case, I recommend using post-its to represent the people. I’ve had some teams print out small photos of their faces. For distributed teams, you can create a digital online constellation via a number of graphic or illustrative tools and place them on team sites or printed out so they can be shared.

I typically recommend a Team Constellation with three tiers as there are three levels of responsibility that typically are needed to embrace the team’s needs.  The first tier includes the core team who are committed to work directly on the product or service and meet the definition of team (in the first paragraph). They provide leadership for each increment, self-organize around the work, build the deliverables, and attend team ceremonies.

The second tier are the extended team that contribute to the team but are not fully committed. They may provide subject matter expertise in a specialized area or a missing temporary skill needed by the team to build the next increment. For work done in an increment, they should participate in any planning, stand-up, or demo related ceremonies.

The third tier are the stakeholders that support and advocate for the team.  Those in this tier, have an interest in seeing the team’s work become successful.  This will include providing sponsorship in terms of people and resources.  They help with communicating progress more broadly and may attend team demos to observe what is being build and may provide feedback. They may also help the team remove roadblocks beyond the team level.

Consider taking time to visualize your team via a team constellation. Take a moment to adapt the definitions of each tier. I suggest making it publicly available so that others understand those that work on and support the team. It can also help you solidify what it really means to be a team.  

Applying the Pair Protocol beyond Programming

-->

Pairing isn't just for programming, it can be advantageous to have two people pairing on any type of work. Have you ever had to pair up with someone on a piece of work?  Have you ever launched into the work only to realize that you haven't discussed how to pair up or realized that you aren’t really working well together? There are dozens of different ways to work as a pair so it is important to have protocol on how to work together through a piece of work.  I call this the Pair Protocol.  This is a guideline on how two (or more) people engage together in a piece of work to have the maximum alignment and productivity. The objective is to get two people to work as one. 

Setting the stage 

You need a piece of work, team of people, and the right pairing mindset. The piece of work can be a feature, a user story, a requirement, an increment, or similar that has been refined so the work ahead is clear.  This forms the basis for what you pair around.  You need people who are coming together for a common purpose, know the context around the work, and are willing to work together.  You also need a mindset of “we” and “us” over “I” and “me” as pairing implies that all collaborators of the work in harmony and get the credit together.   

Pairing up 

The first step is for two people to volunteer to do the work together.  This implies each person is ready, willing, and able to do the work. It also means they can self-organize around the work (e.g., to have the option to volunteer for the work and have the ownership to determine how to do the work).  This typically occurs in a session where the work has been discussed and it's time for people to volunteer to do the work. This could be in a form of a planning session (e.g., for Scrum it would be Sprint Planning, for Kanban it would be the Queue Replenishment, and in traditional approaches, it would be a project planning session. The outcome is that two people (aka, the pair) have willingly volunteered for a piece of work.

Working together

Once the pair has been created and the planning is done, the first step of beginning the work is aligning on how the pair will work together. The pair will briefly meet to re-familiarize themselves of the work (e.g., discuss the “why”, acceptance criteria, etc.) and then discuss how they will navigate through the piece of work (e.g., through task decomposition). This includes an agreement and commitment on who will do which tasks, how they will do the tasks, and when they will do the tasks. As this is pairing, there may be tasks where the pair works together. If so, discuss and gain agreement on how this will occur (e.g., working session, etc.).

Capturing Discussion

As you pair through the sprint, increment, or time period, you should capture important conversions and decisions where the work definition (e.g., user story, etc.) is recorded. There may be ‘discussion’ functionality that can be used that allows the pair to remind themselves of the discussion. 

Incorporating Feedback 

It is important to agree on how you will notify each other when a task is complete and what types of feedback loops you will use with each other and with those outside the pair to gain feedback to ensure the work is moving in the direction of value. There should be an agreement on what feedback loops will be used (e.g., review sessions, etc.) and how will feedback be incorporated back into the work. This information can be recorded in the work definition (e.g., user story details, etc.). If the planning or backlog management tool has a “follow” feature, then activating this will help keep each other aligned with the progress.     

Sharing Results

As the work comes to a conclusion, there needs to be a way to agree that it is completed and meet the acceptance criteria. This should occur prior to sharing the results with the greater team or those outside the pair. Sharing results include identifying the venue where the outcome of the work can be shared and discussed. If you are using Agile or Scrum, the Sprint Review or demo can provide the venue for sharing the work and gaining any additional feedback. The pair should also discuss who would demo the work, collaborate on what type of feedback they are looking for during the demo, then jointly agree on whether they’ve met the acceptance criteria of the work, and what are the next steps (if any). 

Being Agile in HR with Peer Recruiting

A collaboration by Alexa Fuhren and Mario Moreira

Does a manager know better than a team who fits best to a role? How can we recruit the right people that fit best to our Agile organization? The answer is, by being Agile ourselves, particularly in the recruiting process!

In a more traditional working environment if there is a vacancy in a team, the manager approaches the recruiter, shares the requirements of the role, hands over the responsibility for the recruiting process to the HR department, and will be involved again when interviewing and selecting candidates. The recruiter is responsible for creating a job ad, posting it in appropriate recruiting channels, pre-selecting candidates, inviting the manager to interviews and making an offer to the selected candidate. The team usually plays a minor role in selecting the candidate.

Many teams in Agile operate with a self-organizing model.  This model includes much more team ownership, autonomy, as well as responsibility and accountability for all team members than traditionally operating teams. In self-organizing models, the concept of peer recruiting can be applied where the team should play a much stronger role in selecting the right candidate that fits best to the team. Due to a better person-team fit, a reduction of early employee turnover could be a desired outcome.

If teams are responsible for selecting new team members, this will change the role of the recruiter from owning the recruiting process to supporting the process and coaching the team. Depending on the knowledge and experience of the team, the recruiter will be more or rather less involved in selecting the right candidate.

Self-organizing teams can be responsible for the whole recruiting process and accountable for hiring the right candidate. It starts with creating a (new) job profile for the vacancy. The Recruitment Coach will challenge the team to figure out which profile is needed to increase their current and future team performance. When creating a job ad, the Recruitment Coach can give advice on how to make it compelling and will provide templates that are in line with corporate design.

Team members can post the job ad on job boards and in their social media channels (LinkedIn, Xing, Facebook, chatrooms, private networks). After pre-selecting the candidates based on previously defined criteria, the team invites the selected candidates for interviews, roles plays, presentations etc. They can choose to ask the manager or recruiter to interview the candidates. The recruiter’s role will be to train the team on interview techniques and how to avoid evaluation errors like stereotyping, the halo effect or the Pygmalion effect etc.

Implementing peer recruiting means moving the decision to the people who know best who fits to their teams. It helps to speed up the recruiting process by reducing long decision making processes with managers and HR.

What is in it for the company?

• Faster decisions due to less interactions with HR and the manager
• Higher team commitment
• Less turnover in the first 6 months of employment due to a better company-person fit
• Recruiter can focus on strategic work, e.g. employer branding, building networks etc., and become a valuable coach for the recruiting processes

What is in it for the candidate?

• Candidate experiences an Agile culture right from the first contact with the company
• Candidate gets to know the colleagues he will closely work with
• Job interview at eye level with team members instead of the potential manager

Peer recruiting shifts the recruiter’s role to a coach who supports the business in making hiring decisions faster, selecting candidates that fit best to the company and lowering the early turnover rate. Enabling the team to select new team members increase their autonomy which can lead to higher team commitment and higher team performance.

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

Learn more about Alexa Fuhren at: https://de.linkedin.com/in/alexa-fuhren-b745843/de

Mario Moreira writes more about Agile and HR in his book "The Agile Enterprise" in Chapter 21 "Reinventing HR for Agile"

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