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:
To read more about Chris LeBlanc, visit: 

Sunday, December 6, 2015

There is no Success or Fail, only Learn

I have been in discussions both in-person and on twitter with colleagues on whether we should use the word “fail” or “learn”.  This was in context to projects (aka, releases, increments).  Did they failed or did we instead learn.  I also realized that the term “fail” is somewhat subjective (e.g., did the whole project fail or just parts of it?).  The overwhelming agreement was that “what did we learn” was a better way to discuss the findings or results. This lends itself to a shift in mindset, to a continuous learning environment that recognizes that there is value even in the negative feedback.   We can learn from that feedback and adapt for better results in the future. 

Then it occurred to me, the term “success” was also a bit subjective.  I recall reading a Standish Group Study where those projects that were “deemed” successful, 45% of the features were never used.  Another 19% was rarely used.  This meant that projects deemed successful built 64% never or rarely used features.  That seems to be a very loose definition of what “success” looks like.  In addition, how many projects are deemed successful because it met the scheduled deliver date yet few customers upgraded to it or bought it?  Is there a benefit to use the term “learn” in place of success?
While it may sound feel like the terms success or fail are the way to traditionally judge a project, release, product, or service, we lose sight of the most important result of the work, the feedback and what we learned from that feedback.   This learning helps us adapt to achieve better results.  If you are working in an Agile context where there are short increments of work, there is the benefit of continuous learning where you can continuously adapt for better business results.

I would suggest in the modern lexicon of work, when a project, release, or increment of work is done, it is much more important to ask what was learned instead of classifying it as a success or failure.  This strengthens the mindset within the organization that there is a value in feedback and the most important thing is what did we learn.  It also emphasizes a discovery mindset where what we think a customer wants is really a hypothesis that must be explored.  It is in the learning that can help us lead to better business results in the future.  So next time people talk about a project as a success or failure, instead turn the discussion around and ask “What did we learn”?  

Sunday, November 8, 2015

Are Google’s OKRs compatible with Agile?

A collaboration by JP Beaudry and Mario Moreira

Recently, someone asked us if we thought that the Objectives and Key Results (OKRs) used at Google and applied at Intel in the 1970s is compatible with the Agile mindset. In order to refresh our understanding of OKRs, we reviewed the Rick Klau presentation on How Google sets goals: OKRs. After examining the characteristics of OKRs, and with a few open questions, we are of the opinion that for the most part, they can be used in support of the Agile mindset. 
To provide a basic understanding, OKRs is a technique for setting and communicating goals. The first part, the objective, is the outcome that is sought. While the second part, the key results, is comprised of 3 to 5 specific and measurable pieces of evidence of progress against the objective. OKRs can be cascaded and refined at various levels in an organization. In order to allow people to be bold and think big, the guidance is that only about two thirds of OKRs be completed within a given period of time. To promote transparency, everyone’s OKRs are publicly accessible and graded.

Now back to the key question – Are OKRs compatible with Agile?  Based on our examination of OKRs, here are some reflections:

AmbitiousBy design, OKRs should only be met or succeed about two thirds of the time. This lines up well with the general desire for organizations to be more innovative. There is a broad agreement that innovation is inherently uncertainty/high beta, and that a certain amount of failure/learning is inevitable. A goal of imperfection makes it safe for people to take chances

MeasurableMeasurable outcomes are critical in determining whether one is getting closer to the stated objective. This is well aligned with Eric Ries’ concept of Validated Learning. It also plays well with Mario Moreira’s framework of a Lagging-to-Leading metric path

PublicI’m sure the public display of OKRs does wonders for creating alignment on priorities. This is because it makes it so much easier for all stakeholders to notice, and more importantly correct, misalignments. So much the better if the full cascade from strategy to team-level user stories is visible in one place. 

GradedGrading OKRs forces participants to confront reality. Without an explicit process step where results are confronted, it’s too easy to skip the learning step. Without the result-driven feedback, roadmaps cannot be updated.

Because we haven’t worked with OKRs on a sustained fashion at scale to date, we have a few open questions on how they would fit in an Agile environment:    

Individual or Team
At what point does the individual accountability get in the way of teamwork? Most Agile organizations spend a tremendous amount of energy creating high performing teams. It seems that individual OKRs could undermine teams

Local or Global Optimization
A corollary is how to prevent local optimization that could make top-level objectives more difficult to attain. Would OKRs promote a narrow view?

In summary, it seems to me that the Objectives and Key Results (OKRs) technique has several characteristics that make them compatible with Agile environments, and few obvious downsides. The fact that OKRs are also used at LinkedIn and Twitter seems to provide further evidence of their usefulness in innovative environments. 

If you have experience with how OKRs can be used in an organization that values Agile and the discovery mindset, please consider sharing.  Bonus points if you can shed some light on the open questions in the article.  


To read more of JP Beaudry's articles, visit:   

To read more of Mario Moreira's articles, visit: