Documents Say…

The Agile and Scrum literature, including training classes, recommend a team size of “seven, plus or minus two.”  This means a Scrum team should have 5-9 members as the ideal size.  In Scrum this number includes the Product Owner and ScrumMaster.  There are many reasons for this recommendation:

• A team smaller than five decreases diversity of skills, opinion and background too much, which hurts creative capacity.
• Imagine a retrospective on a team of three people. There is a strong tendency toward either a regular complaint session or mutual admiration society.  Neither of these would lead to productive improvements very often.
• A large team requires too many relationships at once.  For example, every member of a 10-person team has nine relationships to maintain, with a total of 90 relationships in the team.  Add an 11th member and the number of relationships goes up to 110!
• The overhead of coordination grows with team size along with the difficulty in maintaining relevance between the members.

Experience Says…

I was once the ScrumMaster of a seven person team.  We were starting the creation of the base technology for a the company’s next generation of products.  Exciting stuff!  We hired or pulled people from other projects to grow the team as the work progressed.  At around twelve members I began asking about splitting the team, to keep the size reasonable.  We decided against it, that we wanted everyone to be aware of what was happening in this complex work.

And the team continued to grow.  Software engineers, hardware engineers, VHDL (embedded stuff) designers and so on were added.  Soon we had 26 on the team.  Yes, it was big, way too big.  We still held our daily stand-up meetings and kept them to 15 minutes or less most of the time.  We worked hard to keep meetings tight and relevant.  And we failed at keeping the energy up.

Splitting Is Good To Do

After several sprints we finally had consensus to split the team into three.  Let me paraphrase some things people said about their new team size after the first sprint:

• Retrospectives are better because it is easier to write items for “well” and “improve” because didn’t have to worry about boring other members with things they don’t care about.
• Daily meetings were not an interruption of hearing about things I wasn’t working on.  I could work, go to the meeting and go back to work with the same thread of thought.
• My team members are helping me more often now. I guess they didn’t really see when help was needed when we had such a large team.

Large or Small, Watch

Whether your team or teams are large or small, watch what is happening.  Pay attention to the information flowing in meetings and during the work.  Especially give a strong look at what is happening in the retrospectives.  Are things discussed shallow or repetitive?  Is there confusion when clarity was expected?  So some members feel alone in the team?  The size of the team may be something you can change to remove such doldrums and re-energize the communication!

The Team State

This team had grown to more than double their original count over the past year or so.  They could see that some things could be improved, some “pain points” needed relief.  Some areas we discussed:

• New ways of handling incoming Product Backlog requests, both new development and maintance stories.
• The team structure was also in question.  Do they split?  If so, how?  And why?
• The newer members were integrating well but perhaps more could be done to help them integrate.
• A few team members and many end customers were time zones away.  What does that mean for their work and getting to done?

These are more were great questions to be asking themselves.  We endeavored to help them with new vision and directions to explore.

Forgetting What’s Good

As we proceeded with the day, reviewing the definition of Scrum and working through their questions, we were focused on what improvements were needed.  Pain points were identified, discussed and solution paths planned.  This was all going well, with honest conversation all around.  And then I was taught by the group’s awesome manager during a late moring break.

He walked beside me down the hall and pointed out that we seemed to be talking a lot about “becoming a high performing team,” as if this team was not already performing very well.  The team was already known in the company as very high performing.  They delivered on time and with high quality.  They were already a great team.

I nearly stopped walking.  He was so right!  I had already seen that these people were a team, in the best sense of the term.  They interacted with respect and intent for the good of the whole.  They knew what they were talking about and wanted more from themselves.  We had spent so much focus examining the places of difficulty that the things that were right were nearly forgotten!

Remember the Foundation

Foundation by FaceMePLS on Flickr

And focusing on the improvement spots, the pain points, can blind us to the things we are already doing well.  As we improve, we build on the foundation of what is already good.  So good teams can become great and great teams can always get better because of the excellence they already have!

The next time I’m looking at pain points, I’ll remember to recognize the good work already in place, making the coming improvements possible.

The best way to make sure a poster has value for your company or team is to start out with good information.  Platitudes don’t cut it.  Real value from the information is the best measure of good content.  Let me tell you about the most powerful poster we have in our office.

Some time ago I encountered the presentation “I don’t like Mondays” presented at Agile 2007 by Jean Tabaka.  Her presentation is an excellent summary of great things that energize meetings of all kinds, and Agile meetings in particular.  (After you read this post, go watch the video.  It is well worth your time!)

In the presentation, Jean provided the content for our poster as a “Focus On / Focus Off” list about communication.  A picture of the poster is to the right, hanging in our main meeting room.  The simplicity of the content belies it’s power:

Focus On / Focus Off

Inquiry rather than Advocacy

Dialogue rather than Debate

Conversation rather than Argument

Understanding rather than Defending

Why

We found that hard decisions in our meetings led to some conflict.  Conflict is to be expected, even desired, in creative work.  Passionate and creative people will have conflicts if they are effectively engaged.  The trick is working through the conflicts such that the customer and the team are happy with the results and each other.  An Agile team needs to learn tools of compromise, knowledge transfer and empathy to get through the conflicts that will come.

One particularly contentious Sprint Planning meeting bothered me as we proceeded into the Sprint.    We had simply postponed some of the difficult decisions because the logjam of opinion was impenetrable.  (Everyone was civil but feelings were strong.)  As we approached the end of the Sprint, I worried about the Retrospective and the planning to take place after that.  How could we quell the conflict enough to make decisions without damaging the team?

One evening, during the last few days of the Sprint, I found the video of Jean’s presentation.  I had to try this “Focus On / Focus Off” discussion!  I wrote the title and described how our internal focus changes the context of our communication.  I then wrote each “rather than” pair one at a time and asked a team member what that pair meant to him.  I then asked another team member how one would act or speak if focused on the left word and then on the right word.  I did this with each pair of words, discussion their meaning and effects.  I then asked that we each do our best to focus on the words to the left as we work through the retrospective and planning.  I then taped the easel page to the wall as a reminder.

The feel in the room softened, opened as we had this discussion.  Yes, that sounds all “warm and fuzzy” but it is true! The Retrospective was excellent and the Sprint Planning meeting that shortly followed was very fruitful.

Power

Can a poster have such power?  If you have a Scrum Team willing to work for the better of the project, for the customer, it can.  We each need occasional reminders about what open communication really means.  A reminder that our thoughts are valid and need not block all other ideas to retain validity.

Today, more than a year later, the hand written poster hangs on the wall right where it was first taped up.  It still helps us to disagree, learn and grow.  And work with each other the next day!

The feel in the room was largely up-beat but had some unspoken tension. I shifted gears quickly to start different than planned. I asked that we go around the room and each member give two statments:

• Give one word that summarizes this sprint for you.
• Describe your passion about this sprint, team, project or company.

The one-word summaries were balanced between words like “progress” or “satisfaction” and “frustrated” or “bottleneck.” (Ah, the tension comes out.) This was reasonable given that not all the stories were completed this sprint.

The passion statements were great! They ranged from love of creating new technology to the joy of shipping actual product.  We all learned interesting things about each other.

And the tension was over. Just like that, it was time to dig deeper into the sprint with clear heads and a forward view established as a great foundation for the meeting.

Personal Trill

My personal moment of happiness came during the expressions of passion. Two engineers spoke of the team’s effectiveness in powerful terms. To paraphrase:

The is the most productive team I have ever worked with in my entire career.

I didn’t think I would ever enjoy working on a team larger than 3 or 4 people, but this experience shows otherwise.

What a great team to work with!

@estherderby If there was only 1 agile practice what would it be for you? For me, it would be retrospectives as they are foundational.

I fully agree that retrospectives are the one powerful Agile practice to do if no others are yet implemented.  I posted:

@estherderby The first retrospective we had was stilted and shallow. And it improved the culture of the team dramatically!

As I posted that brief message, I knew a blog post was needed to fully explain the strong statement.

Getting To Retrospective

The team had been doing “Scrum” for some weeks.  I put Scrum in quotes because we really were not doing enough of the practices to use the term.  Key members of this team and engineering management were not fully committed to Agile and Scrum.  We were adopting practices slowly, as the acceptance of these key players allowed.  We were doing:

• Weekly Sprints
• Weekly planning meetings
• Daily team status meetings, like a daily Scrum
• Using a team board with tasks

I had been requesting that we start doing retrospectives, even just do one to try it out.  The biggest objection was the perception that it would be a waste of time on a “feel good” measure of little value.  Percistent discussion and pointing out the well known desire to gather “lessons learned” finally prevailed.  We scheduled one retrospective as a test.  Maybe they just wanted to stop me asking.  Whatever works, right?

The Culture

Prior to beginning our migration to Scrum, this team had a very traditional structure.  A brilliant engineer was the Team Lead.  He determined tasks for each of the team members.  As we started doing sprints and team level planning, this lead continued the practice of defining tasks for each team member.  We shifted to emphasizing that each team member needed to accept the suggested tasks.  The reality remained that the Team Lead was determining the work of the team.  (This practice was not Scrum, nor Agile.  A dicussion of the value of such a slow shift to Scrum is another blog post.  Or an essay!)

Several members of the development team were quiet.  When discussing development one-on-one, they had great ideas and interesting things to say.  When in the team meetings, they were largely silent and simply agreed with the more dominate personalities in the group.

The Setup

I chose our Training Room as the venue for the retrospective.  This is also the same room where sprint planning meetings were held.  Usually the room has four tables pushed together in the middle of the room to form one large table with 12-14 chairs around it.  For most meetings this arrangement is appropriate but for others, it is not conducive to the meeting goals.  (See http://blog.dayleyagile.com/2009/02/23/the-real-elephant-in-the-room/)

I split the tables appart, pushing them out to the edges of the room with the chairs lining three sides of the open space in the middle.  The team board showing the task cards for the sprint just ended was positioned at the front on the wide marker boards, now erased and ready for writing.  Sticky notes and pens were liberally sprinkled around the room for attendee use during the meeting.

The Meeting

During the meeting several notable things occurred.

• As attendees arrived they made comments about the organization of the room.  Some were quizical, some were intregued.  Two who brought notebook computers were unhappy at the lack of a table for thier electronic distractions.
• I asked each attendee to state what value they though they could get out to the meeting.  Their responses were interesting.  More important was getting each of them to talk so each would be more likely to speak up during the meeting.
• Each was asked to write sticky notes of what went well and what could be improved.  This minimized the effect of dominating personalities and ensured that everone had the opportunity to contribute.
• Dot voting with performed to find the top improvements to work on.  The Team Lead was particularly irritated that his three dots were not enough to force his desired improvements to the top of the list.

Immediate Changes

As I think about it today, this retrospective was not particularly effective for the practical work of the project.  We did not even execute well on the choosen top improvements.  The team member interaction started changing from that day forward.

• Everyone contributed at a team meeting, maybe for the first time.  And it was not just the individual answer at the beginning, though I’m sure that opened the door.  Every person provided sticky notes and comments throughout the meeting.
• Several times comments along the lines of “I didn’t know you thought that” were heard.  The following planning meeting that afternoon was more lively than ever.
• Right there, in the meeting, the Team Lead role began to be absorbed into the team.  This was difficult for the dominate personalities to take but the “human side” of the team started forming in a positive way.

Retrospective Power

As time went by, this team began to gel further.  Participation in the meetings and with each other increased.  The team unified further, more easily able to request changes from the larger organization.  We also had serveral meetings that dove to the heart of individual difficulties, something not possible without higher levels of trust.

Several of the dominate personalities eventually left the company, perhaps in part as a side effect of at more egalitarian team environment.  We continued to have retrospectives and attempted to apply the actions to improve our work and team.  This team eventually produced the product and has now moved on, mostly joining into a team designing our next generation project.  Retrospectives are a key part of the work and we never skip them, ever.

If you are doing a slow adoption of Agile practices and must pick only one practice, do retrospectives.  Do them regularly and with serious attention.  Daily meetings, sprints and team planning are powerful and look easier to start doing.  Real change on with the team’s human dynamics really happen when the retrospective becomes part of your habitual practice.

This morning James posed a question about sharing lessons learned between teams:

Any quick suggestions on how to facilitate a retrospective over a team attending training to decide how to teach what they learned?  (http://twitter.com/jamescarr/status/1706359397)

Scrum and other agile methods promote the practice of regular retrospectives or team reviews at the end of each interation.  The team spends time specifically evaluating things that went right and wrong during the last development sprint.  This way the team learns to get better and better over time.

If your company has several or many teams, wouldn’t it be good to spread the lessons each team learns with all of the other teams?  And, if you have a new team with developers new to agile practices, wouldn’t it be good to prevent them from “re-inventing the wheel” on their path to being a great team?  Certainly these are great goals.  To the question posed by James, what is good way to pass on this information?

As I attempted to respond, a thought struck me about new agile teams and how they can learn to be great agile teams.

• During or just after a retrospective, write down the team’s lessons as an agile story on a story card, following the template wording using roles.

As a <role> I/we should <learned behavior> so that I/we can <benefit of learned behavior>.

• Set aside a wall, literal or virtual, on which these story cards are placed.  The wall must be visible to all teams.

These lesson stories become a “Product Backlog” for producing the ideal agile team!  Heck, a department director could be the “Product Owner” and prioritize the lesson stories for the teams to ensure they are applying the lessons!  I get excited just thinking about the learning culture this could create!

I need to figure out how to do this with our teams!

I have not tried this yet, nor have I heard of the idea anywhere else.  I’m sure there are many ways to share lessons learned between teams.  Comment below on your thoughts of this “Team as a Product” idea or other ways that help share lessons between teams.