Lead the Change you want to see in the World

A collaboration by Kyle Cahill and Mario Moreira

In the beginning, the world was filled with doers.  There was so much to do that there was only time to get things done.  These were the no-nonsense types who like to just get on with it. They like to act first.

Then the second type of person came into being called the thinker.  Thinkers were the armchair philosophers. They are great at stepping through the arguments. They are awash with mental models and can run the thought experiment in their heads. One's ability to critically analyze the situation starts with uncovering the problem and this means ensuring the right question is asked. As Albert Einstein (was thought to have) said: “If I had an hour to solve a problem I'd spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.” Einstein understood that hard thinking was to correctly identify the problem so that the solution becomes easy and addresses the real problem.

Over time, the third type of person emerged who has an extra skill. Not only can they think and act, but they are also talented communicators. Communication is easy to understand the concept but hard to do effectively. Communication at its essence is the imparting or exchanging of information. The ability to effectively communicate ideas can determine if the idea succeeds or fails. Often in today’s business world, you must win the war of ideas and this war is won not just by having the right idea but also by communicating it effectively.

Finally, the world evolved to create agents of change. They are the doer, thinker, and communicator combined. And they have a fourth attribute, they can help people and organizations transform by focusing on better outcomes and motivate people to take ownership of the change.  These are the people who propel the world forward, crush inertia, and break the chains. If you want to change the world (or anything for that matter), you need to be this type of person, who can think of ideas in context to the right problems, communicate well, be the doer to propel the change, and the motivator to get others to be the change.  It is the consistency of the actions that can remove inertia and break the chains that will change the way people work…forever.

-->

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). 

Agile - Is it Real or is it Fake?

At the World Agility Forum in Lisbon Portugal on September 29, a panel of leading Agilists focused on “Shifting perspectives to know what is Real (agile)” The panel was made up of Chet Hendrickson, Steve Denning, Nigel Thurlow, and Mario Moreira.  We discussed “What is fake Agile? What is real Agile?”

What is real Agile?  It starts with an alignment to the Agile Values and Principles.  Without understanding and embracing the values and principles, whatever a company is doing is certainly something but can it really be considered real agile?

Agile is more than mechanically applying Agile processes. This I refer to as “doing Agile”. More important than choosing a particular process of Agile, is the art of learning how to live Agile values and principles, to transform Agile mechanics into Agile mindset. This is what I call “being Agile.” 

Steve shared that fake Agile is really a reference to “Agile in name only”.  Since many companies want the badge, he indicated that to understand if companies are Agile, you need to look beyond what they are saying and look at what they are doing.

Nigel discussed how companies feel the need to get on the Agile bandwagon and do Agile as it is the trend.  He stressed the importance of understanding the benefits that Agile can bring and focusing on this instead of Agile itself.

Chet shared that there may be something much worse than fake Agile and that is “dark Agile”.  This is using Agile as pressure to get more work done or impose Agile on a team and not remove any of the constraints leading to numerous anti-patterns. 

Mario talked about a concept akin to fake Agile which I call “FrAgile”. This is when Agile is so minutely applied with little focus on the Agile Values and Principles that it quickly becomes brittle, lacks vigor, and shatters once there is tension applied, leading to a regression to old ways of working.

It was a healthy and collaborative discussion leading to a clear awareness of how fake Agile is damaging the good name of Agile.  Instead, it is time to bring pointed awareness of what is and isn’t agile and advocate for “being Agile” and the outcomes it can bring.

For more on Fake Agile, consider reading:

• Understanding Fake Agile by Steve Denning  
• You may be FrAgile if… by Mario Moreira 

The importance of Meeting them Where they Are

As I work with teams, leaders, or executives when applying Agile, often times what they ask for is not the first thing they need.  This is why bringing a “meet them where they are” mindset is important.  When you meet them where they are, you can bring the kind of coaching, education, and feedback that better fits their role and experience.

In most cases “meeting them where they are” means to understand where mentally (both intellectually and emotionally) they are in relation to the topic, in this case Agile.  This may mean attempting to understand their level of Agile knowledge, experience with Agile, and motivation or willingness for Agile. Sometimes meeting them where they are is physical meaning you join them in their workplace, their daily stand-up, or any space you may observe their interactions to better understand where they are.

This approach can help you understand the common ground. This helps the Agile coach know where they are and where they can go from there. It helps a coach determine how to engage in a way that is sensible and motivating to those they are coaching.  Example of meeting them where they are include:

- If a team has only just begun to form, it may be better to educate them on what it means to be a team, the Tuckman model, and on what it means to form before you expect them to perform well. 

- If a new team wants to give and receive honest feedback to each other, it may be better to first initiate icebreakers and connecting activities so that team members can get to know one another and build psychological safety and trust first.

- If a team or company wants to embark on an Agile journey, before you educate the team on how to do Scrum it may be better to first start with a discovery activity to gauge the current knowledge of Agile, Agile experience, and willingness to apply Agile.  This can help you better adapt the level of Scrum education they need.

- If you learn that the team is fairly Agile savvy and have applied Scrum already, but are having challenges with decomposing work, then you can meet them where they are but experimenting with story mapping.

Meeting them where they are has multiple advantages but the primary one is that you can determine what they need first.  When you meet them where they are, you can bring the kind of coaching, education, and feedback that better fits their knowledge, experience, and willingness.