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