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!

As soon as someone gives analytical minds a number and a way to produce that number, we naturally go to work digging into its meaning. Analysis is fine when it leads to beneficial results. Many times such research leads to wasted time at best and damaging side effects at worst. Some examples:

• Velocity was average last sprint. We know we can do better so let’s push this sprint to get +10 on that number!
• The VP says she’ll take us out to the movies if we can increase our velocity by 25% this iteration.
• Team Tiger completed 30 points last sprint and we only got 23. We need to do better than them!

Before we look at these examples further, let’s take a road trip.

Driving Velocity

I live in the Phoenix, Arizona, USA metro area. Because my wife (especially) and I enjoy a famous rodent’s home in southern California, we’ve often made the 350 mile drive to that neighboring state. We know the route fairly well.  We also know that sometimes traffic, detours or other things might interfere with our usual progress.

When we arrive at the hotel our conversations about the trip never sound like:

• We averaged about 62 miles per hour this time. We know we can do better so let’s push to get +10 on that number on the way back!
• Mom says she’ll buy us extra churros if we can bump our speed average by 25% next time we come.
• My buddy Harvey drives at 80 miles per hour on this same route and we only do around 70. We need to do better than Harvey next time!

Do you talk about velocity like that after a road trip? Why not? Because the velocity is not what we are should be delivering. Let’s read that again.

Velocity is not what we are delivering.

On a road trip we are delivering a destination by a more or less certain time. While driving, velocity is important in the moment of driving, in consideration of safety and to avoid speeding tickets. No one cares if we could have gone 78 miles per hour instead of 74 in the stretch between Tonopah and Quartzite once we are in view of an artificial Matterhorn mountain!

Velocity Used Well

The three bad examples I started with all use past velocity and even some other team’s velocity. They all center the conversation around velocity, as if customers want more and more story points! Customers want working software and everything we do should be in support of delivering working software, not velocity.

I promise, if managers ask teams to deliver velocity, they will.  Most likely by cutting quality or simply increasing the scale of work size estimates, which has little to do with delivering more product.  So use velocity as an indicator, as it is used in driving.

• The team velocity now is an indicator of how much work can be done in the next sprint.
• Velocity is an indicator of what will be included within the current series of iterations making up the release.
• Velocity highlights that something is going really well or needs improvement. The improvement doesn’t come by raising velocity, it comes by making the improvement.

Let’s revisit our statements one more time, where velocity plays a part but is not the focus.

• Velocity was average last sprint. Why didn’t our new unit-test framework give us the boost we expected?
• The VP says she’ll take us out to the movies if we can get that video feature done this iteration.
• Team Tiger delivered all their stories last sprint. We need to ask them what is working so well!

There is so much more to say about velocity and how to use it. Please keep in mind the possible negative effects when we take our eyes of the product and start seeking credit for a number. And remember to deliver working software, a product, customer value, not points!

Projects need teams?

It is a very common practice for companies to manage work into projects.  Customers understand this and portfolio management, even management of larger projects, tends to naturally fall into divisions of projects.  The difficulty is that companies naturally extend this into creating a project centric view of all process.  What equipment does the project need?  Which lab facilities are available for the project?  Who are the resources with the right skills?

That last question is about people.  When we think of people as “resources” and “skill sets” we start to see them as interchangeable parts of a machine that will work on a project.  So we take a group of people, many who have never worked together, and assign them to a project and call them a team.  Because, if you are on the same project, you must be a team, right?

Preventing a team

Teams need time to learn how to work together, to figure out likes, dislikes and strengths of each member and time to develop an identity and trust.  These things don’t happen by declaration and don’t happen in one week or even one month.  When these deep interaction attributes solidify, the group of individuals becomes a team.  Great teams can take on whatever you throw at them!

The habit of swapping people in and out of teams is destructive to building these connections and high-bandwidth communication channels.  Ester Derby points out some of these bad effects:

Plucking people off the team or poking people into the team causes a re-set in the team forming process. Mess with the membership often enough, and people will stop trying. When team membership feels like a revolving door, individuals won’t put in the effort to form team bonds. You may get a group that functions reasonably well, but you’ll miss out on the team effect.

It is surprising to me that we fail to see the cost of breaking apart a team.  In the project-centric managing view, a project ends so the team gets split apart on new projects.  And we throw away the investment we made over months of work, choosing instead to pay the cost of re-building a high-performing team.

Teams need projects!

If creating teams around projects is the bad for true teamwork, what do we do with teams and projects?  The Agile Manifesto has an answer in it’s fifth principle:

Build projects around motivated individuals.  Give them the environment and support they need, and trust them to get the job done.

Once you have a high-performing team, define projects that they can do.  Work with your customers to create a project that your teams have already proven that they can build and impress people doing.  The costs of dividing people and rebuilding trust, communication and capabilities is very high.  And your teams who have learned how to act as one will be happier to know their joint contribution is valued.

By the way, that team who was afraid of breaking up had a happy ending.  We figured out with management and company needs how they could stay together and continue impressing customers. It was a nice beginning to that ending!

Creative Sparks

They are everywhere!  Right now, near you, is another person.  That person cares about something, cares enough that they could talk about it with enthusiasm, energy and sparks!  And even if you didn’t really care about the subject, their enthusiasm just might rub off on you.

One of the things that helps create a high performing team is diversity of opinion, personal culture and points of view.  Make sure you help team members give each other the gift of passion.  Hold learning events to present about hobbies.  Ask for book reviews or presentations on some new technology.  Heck, go bowling.  Do things that expose your people to new ideas.  One day those “unrelated” creative sparks will trigger your next market-winning innovation!

Check out more inspiring presentations at the Ignite Phoenix YouTube Channel.  What will they inspire you and your team to do?

Context

If Agile is about people, it’s surely about communication.  Let’s start by looking at a few things we know about communication:

• Some say human communication is only 7% words while the remaining 93% is verbal and visual (http://en.wikipedia.org/wiki/Albert_Mehrabian).  While some might argue the exact ratio, I agree that face-to-face communication is by far the best way to share information and create.
• The ability to grasp abstract subjects and invent is severely damaged by context switches and distractions.
• Understanding the history and context of a subject increases the ability to be productive in that subject.
• Any change in the membership of a group (team) will disrupt the relationships and communication paths of the group.  It will take time to reestablish the previous levels of efficiency.
• Any person highly experienced in a general skill area will need to learn the basics of any specific situation before they can be fully productive in that specific situation.

Almost anyone would find the above statements as reasonable, even intuitive.  And yet, point by point, common real life situations continue every day:

• Work environments are designed such that the use of anything more than email, instant messaging and documents very difficult, if not impossible.  IT policies and work requirements force dependency on only words and eliminate the rich audio and visual channels we naturally know.
• Day after day we are required to change projects, product focus and attention.  Some engineers I know have as many as 12 or more projects to keep in the air.  Details are lost in the context switches.
• Developers and other workers are thrown into projects with no information about the purpose of the work, the roles of the people involved or the value of the product.  Instead of listening and building the confusion of purpose reigns.
• Individuals are “resources” to be plugged in and out of “teams” at will and whim.  Long term relationships with shared experiences building high communication connections never happen.
• Questions about basic information are met with chastisements from peers and managers.  For some reason people are expected to know already without any training or orientation.  People learn to not ask questions.

Innovation Sabotage

Pushing people into situations of poor communication, severing communication paths and obfuscating information will not produce real innovation.  Working harder and longer will not make up for the damage.

I’ve attended meetings where top executives tout technology and projects that will propel the company to new heights of profitability.  They point out the places in the plan where differentiating innovation will be created.  Difficult problems will be solved to create the products and success that will come.

And, the company does not allow the use of internet video conferencing.  And defines projects based on “resource” skills without regard to geographic location.  And has key projects running with no defined structure or governance models.  And considers “fire fighting” just the way the industry works.  And requires heavy sign off processes by people who don’t know what they are approving.

Many times the disconnect is both huge and invisible to the executives and even the people working under fog and confusion.

Agile Means Transparency

To be Agile means communication about everything.  Finding ways to easily share everything such that when data is needed, it is readily discovered.

• Don’t eliminate up to 93% of human communication capability, enhance it.  Put teams in their own rooms, not cubes or offices.  Design product development structures to support co-location instead of distribution of people.
• Give teams goals that don’t change all the time and members that are dedicated to the team, not split multiple ways.
• Explicitly define and publish team structures.  Allow new people to be trained on products and processes before they are required to be fully productive.  Organize the information in radiators that passively keep people in the know. Give people time to learn them.
• Projects and products come and go.  Teams should not.  Allow deep relationships to form and cultivate over time from project to project.  Soon you’ll have teams that can do anything you throw at them.
• Basic questions should be welcomed and the answers immediately available.

People Problem, People Solution

Every problem is a people problem.  Every single one.  Ask people to solve the problems.  If you are a manager, business owner, vice president, you are the creator of the work environment.  Don’t forget the people and people attributes.  The power of people allowed to communicate fully is far beyond any technology or process.  ”Individuals and interactions over processes and tools” is not just some feel-good mantra.  It is what we need to solve our problems and innovate!

Everyone “Does” Teamwork

Recently I have been participating in the interview process for a technical position.  The opening is on a customer engineering support team.  Another of the participants consistently asks the candidates that well known question:

Do you work well on a team?

If you have spent any time at all on either side of the hiring table, the “team player” or “teamwork” question seems to be a constant.  Every company I can think of talks of teams, creates teams, reorganizes teams and seeks out new employees who will be team players.  That’s because every company says they like teamwork and want more of it.

A Brief Definition

What is teamwork?  I suppose this should be a well known term since every company wants and has it.  Here are a few points that are part of teamwork to me:

• The members of the team works together for long periods of time every day.
• They are aware of what each one is doing from day-to-day and even hour-to-hour.
• Members have no fear of asking for help and many times don’t need to ask, it just comes.
• Members trust each other to do the right thing, feel able to honestly express problems and receive negative content in full assumption of positive intent.
• New work is discussed and planned with the whole team involved.
• If one member fails, the whole team takes responsibility.
• If one member succeeds, that member will praise the team for the work.

In other words, the team is a unit with members providing support and strength to achieve far more than expected.  2+2=∞.

Real Teamwork

There is a simple question to ask that can indicate if a company really promotes teamwork or not.  It’s not a litmus test but a good way to start thinking about true teamwork support:

http://twitter.com/DayleyAgile/status/27293555350

For example: A manager looks at work that needs to be done, decides the individual that should do that work and assigns that task to that specific person.  If that is the usual way of getting someone working on a task, it is questionable that the company really supports teamwork.  In contrast, a manager that looks at work and chooses between several teams for assignment is probably in a company that promotes real teamwork.

A companies actions are what creates culture and the values, not words in a slogan or questions in interviews.  The everyday actions while doing the work have to reflect the values.

True teamwork is powerful and fragile.  If teamwork is important, act in ways that re-enforces and champions them!

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.

I enjoy helping people with Scrum and Agile. The more I do it, the more I learn and enjoy it. Many of my recent in person and online encounters have had a similar flavor to them. I didn’t put my finger on it until this morning.

In an online exchange people have been discussing the Sprint Burndown Chart. Opinions on it’s usefulness, how it should be used and what it contains vary widely. That’s OK, because every team and situation is different. The point that struck me was one particular comment. This person described how their chart showed burn down of estimated hours for tasks. They adjusted the burndown each day if a task’s estimated hours to done changed, essentially including actual hours into the burndown.

For example, take a task that was originally estimated at two hours. The next day the developer working on the task reports slow progress.  The task is not done with four hours already spent. The developer now estimates the task will take ten hours. So the burndown chart data point would be adjusted up by six hours to include the new estimate.

This example shows the desire of this particular team to track actual hours. I suppose they wished to compare them to the original estimates to measure accuracy, though that did not come up. (There are several reasons that I don’t like such a way of doing things, but that is another discussion.)

Other examples along the theme have been

• eight hour planning meetings
• estimating an entire five month long Product Backlog all at once
• two days of wireframing before writing the story
• sprint tracking spreadsheets with more detail than a Gantt chart

So when I was thinking about the burndown of actual hours example and other practices of potential waste, the theme hit me:

Big Design Up Front (BDUF) of Scrum

It seems many people are trying to eliminate BDUF of products, with Scrum implementations that are designed big up front.

• They need to define every possible field that might be needed on a story card before they start using story cards.
• They want to track hours and sub-hour increments on tasks, allocated by a percent of the developers time against other tasks.
• They need backlog spreadsheets with date coded story ID’s, date last edited, comments by department in separate columns and priority votes from each of five stakeholders.
• They make up two page forms for recording the definition of done and how each maps to the appropriate use case record(s).

And they do all this before the first team starts the first sprint. Because, well, they’ll need the data, right?

Maybe they will need such tracking of information someday. Any one of the above might be the right thing to do at some point for a particular team or company or product. Does it make sense to design all this infrustructure up front, not knowing if it’s really needed?

BDUF Practices in Scrum

Finally, after weeks of discussion, meetings, documents and planning, they start the first sprint. And here they are with all these BDUF practices now part of their Scrum processes. Product Owners who have more clerk-work than product innovation-work. Scrum Masters who have to keep asking for actual hours worked. Burndown charts that require an instruction sheet to interpret. A project bogged down by the same stuff that was supposed to be left behind by “going Agile.”

Simple Code, Simple Scrum

The best code is simple, direct and no more complex than it has to be. The best products have a clear function and benefit to their customers. The best information is direct, focused and simply presented. The best Scrum is simple as possible. Just as it is not possible to know all the answers to creating an innovative product before starting development, it is not possible to know all the things needed for an awesome and highly productive Scrum process. Start simple, way simple, with just the basic pieces. Then, retrospective after retrospective, the team and company learns what they need, solves it in a simple way and gets back to the real business of creating a killer product.

Just go! You will learn what you need along the way, faster than you ever imagined!

Let’s explore this discussion further in the context of last month’s (April, 2010)  Phoenix Scrum User’s Group meeting.

PhxSUG Meeting

We announced the meeting would be a participatory simulation of a Scrum project. About half of the people in attendance had never been to one of our meetings before and many of them were very new to Scrum. We were gratified that some came specifically to experience a Scrum simulation!

We started with a brief discussion of the Scrum framework, with it’s roles, cerimonies and artifacts. With that foundation set, we dove into the activity. The project was five Sprints of the Ball Point Game (PDF)

(Here is a video of the game in action. If you have not tried this game, I highly recommend it. If you watch the video, don’t say too much when you play the game the first time. Don’t give away the secrets too soon!)

All of the meeting attendees are one team. The goal, or “product,” of the team is to transfer as many balls as possible in the two minutes of a Sprint. Between each sprint, the team reviewed performance and planed the next sprint. We had great fun and the team successfully transported all but two of the balls on the last sprint!  We then did a bonus sprint with some “cheat codes” from me, the coach, to optimize the process.  We succeeded in getting all the balls through in the time allotted!

Debriefing

In our discussion after the game, we found some interesting points:

• Changing even small things between sprints effected performance of the team in bad or good ways.
• High communication was paramount.
• Keeping a rhythm of movement in the whole team was important.

There were several other things learned, one of them was around leadership.  As the team was first getting organized for the first sprint, there was some chaos. Lots of people talking, pointing and throwing out ideas. Suddenly one of the participants spoke up and began speaking authoritatively about how the job should be done. The team followed, with some discussion, and the first sprint began. So, suddenly the team had a leader. Not by assignment but by personal energy and willingness to step up.

Dynamic Leadership

During the first planning period between sprints something interesting changed. Another participant pointed out a weakness and suggested a change to cover it. The team followed this suggestion as the previous “lead” blended into the team to make way for a new leader. This passing of leadership continued from sprint to sprint with different individuals teaching the team their ideas about how to improve and others volunteering into key roles. It was natural that the “Team Lead” changed as the needs of the team changed in the quest to improve.

This is dynamic changing of team leadership also happens in a Scrum team. Depending on the goals of a particular sprint, the team may look to the database administrator to lead or the user interface designer. Story to story, sprint to sprint the expertise needed by the “Team Lead” can alter. A team working well allows the currently needed leader to come to the front, and then fall back in favor of a new leader who has the talent or experience to handle the next focus.

When a team has an assigned Team Lead, this leadership adaptation is less likely to happen. Team members will not want to “attack” the assigned lead’s authority by stepping up. The team lead may not want to reveal “weakness” in a knowledge area and so will not allow another team member authority. Once a hierarchy is established, especially when established by higher authorities, it is very hard for those within the structure to alter their expectation of command and allow a better leadership pattern to emerge when needed.

In short, assigning a Team Lead and expecting that person to be appropriate in the role for the entire project is a form of “Big Design Up Front.” There are great Team Leads and managers that know how to foster leadership from team members. I am not denying that such excellence is possible. I am saying that such people are rare and anyone in that position must constantly push and pull against the cultural expectation that they are Lead and therefore must have the answers.

And The Team Shall Lead Themselves

Let the Team be the team lead. Then, the right leader will emerge at the right time as the team naturally strives to accomplish their work. I’ve seen it happen, just as it did the night we were throwing balls around, learning while laughing!

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!