Your Scrum Team Might Be Too Big

January 4, 2011 Leave a comment

According to the ways of Scrum, the optimal Scrum team size is between five and nine people. Interestingly, I’ve seen this as a point of concern (sometimes contention) when I’ve coached people on Scrum. Please note that this is not a rule that must be followed at all costs. God gave us a brain, so we should feel free to use it.

While I know it’s rare, I personally have seen successful teams that consisted of 10-15 people. I belive that if a team consists of any more than 15 (or so) people, you are reducing your velocity.

Now you have a bloated team.  What should you do?  Well, first thing you should consider is to take some ideas from Kanban. Visualize the work, make the process and policies explicit, limit work in progress, measure/minimize cycle time, etc. (read more on Kanban here)   The purpose of all of this is to gain clarity on what kind of work is actually taking place.  In addition, you will gain insight into the quality of the deliverables and where the bottlenecks are.

Once you have this information in hand, you then have three choices.

  1. Split the team into multiple teams.I have seen large teams have several very distinct types of work occurring. If there are distinct types of work, i.e. completely different categories of stories/requirements with different goals, and the team is forced to act as one, then there is waste. For example, during the standup, there will be members of the team that have to endure hearing the updates about requirements that they have no interest in, nor can they contribute to the delivery of those items (usually). This is likely the optimal choice.
  2. Reduce the number of people on the team.This is the tricky one. You may find that there are people that don’t have the necessary skills, or you may find that there are too many people with one very distinct skill set. If one (or both) of these scenarios holds true, and you are sure that these folks can’t contribute in other areas, then make haste and remove the people from the team. Everyone (including those let go from the team) will end up happier and more productive.
  3. Keep everything the way it is.This is a very, very unlikely choice. I have never personally experienced a time when it was a good idea to keep one team larger than 15 people. I would love to hear from others where this has worked…well.

If you are a Scrum Master, and you are experiencing team bloat, then it is your responsibility to recognize it, determine if it’s an impediment towards improvement, then handle it.

Advertisement

Filed under Agile, Scrum, Teams

Scrum Won’t Always Work

June 7, 2010 3 Comments

Well, this is my fourth refactoring of this post. This was supposed to be a quick one! I fully intended on this post explaining why Scrum will always work. Simple! But, as I thought through this, and kept rewriting my post, I’ve completely changed my tune.

What does it mean for Scrum to “work”? I’m going to define “working” as “delivering more to your customers with higher quality than you did before and continuously getting better”.

Does Scrum always work? In my opinion, no. It depends on the type of team that is being introduced to Scrum whether nor not it will work.

The Team that Rocks

If you have a team that is consistently delivering value, is a cross-functional “team” and not a group of individuals, is continuously improving and has a good, productive relationship with their customers where the customers define what they want and collaborate with the team, then Scrum may set them back. I believe that the additional overhead in the form of sprint reviews, retrospectives, sprint and release planning, and daily stand-ups that Scrum adds may make an already high performing team less productive. The team, in some form, is already doing something that produces the same results as these activities. For these types of teams to improve, Kanban is likely be more appropriate.

The Team that Does Not Rock

I really wanted to title this “The Team that Sucks”, but I thought that would be too offensive. Anyway…Given a team that is not consistently delivering value, is not a real “team”, or has a bad relationship with their customers, I believe Scrum will always work. The team will always be better than it was before. Typically these teams have no process (even though they think they do), so anything that brings discipline and communication will allow the team to improve. I have never, ever seen this to not be the case. I admit that at times the improvement is small, but it is an improvement nonetheless. Of course one thing that’s crucial is to have a strong, experienced coach.

As far as the roles introduced by Scrum, you will have a hard time convincing me that there are times when a product owner role is not needed. I’d have to say that the #1 problem I see in “troubled” teams is the fact that they have no idea what to work on next. What do they do in this case? They start guessing. Oh, and they never really know when they are “Done”. If I do nothing else but involve a strong product owner, that alone typically propels the team forward.

As the team matures, however, they will inspect and adapt (the essence of Scrum). Many “advanced” teams may be considered by Scrum-ists to be doing “Scrum-but”, or maybe even not doing Scrum at all, since they have adapted to be the most productive and efficient they can be. Which helps verify that Scrum will not always work.

What do you think? Will Scrum ALWAYS work?

Filed under Roles, Scrum, Teams

Stop Talking, Start Drawing! A Quick and Dirty Value Stream Example.

March 25, 2010 2 Comments

Recently I was helping a team out in a sprint planning session. All development is very waterfall (that’s a topic for another post), and it follows a very well defined, albeit inefficient, process.

We were talking about how to “streamline” the process to deliver this particular product, which was nothing more than an electronic representation of a printed document.

We talked and talked. We were “talking” about the process. I decided to draw the process we were talking about so the entire team could visualize it. It is a very quick and dirty value stream map, and can be considered incomplete, but sufficient for the needs of the team at this point in time.

Below is a re-drawing of the first stab minus the “details” 🙂

Delivery Process

I then asked the team if there were any opportunities to improve. The collective answer was “no, the process is already streamlined“.

Okay, sweet. But, I’ve never seen a process that can’t be improved. Ever. And I’m old.

Then I asked how “long” we stopped at each step in the process, i.e. how long each step took. Below is the same drawing plus the weighting.

Delivery Process With Weights

Delivery Process With Weights

Notice any thing interesting? Anything stand out? Well, I’m sure you caught it. The “unit test” box is 40 hours, while everything else is 8 or less. Hrmmm….I wonder? Could we maybe do something there?

Well, we explored it a bit, and found that how we’ve been doing things is throwing them over the wall so the consumers of the documentation can eyeball and test this stuff. Guess what they did if they found something wrong? They spent time creating a document to tell the developers what to change. Then, back around it went.

So, an option the team came up with to reduce the time spent in the unit testing “state”, was that when unit testing began, they would have the developers sit by the folks who actually tested the documents, then they would “tell” them what to change…then change it…then send it back to test. No emailing and creating painful documents describing what’s wrong. Just good old fashioned face to face conversation. The team is confident that they can significantly reduce the 40 hours of unit testing.

Will this work perfectly? No. There will be more opportunities for improvement…as always. But, you know what? We would have never explored this option of we would not have visualized the process by drawing it.

Oh, guess how long this took us? About 20 minutes. Yup…20 minutes. That’s it. How long did we talk in circles before we drew? Hrmmm…about 1/2 an hour, and it got us nowhere.

So, as soon as you start talking and talking and talking and talking and getting nowhere. Get off your butt, and start drawing.

Filed under Process, Teams

Scrum Needs More Than Just Chickens and Pigs

March 21, 2010 2 Comments

If you’re reading this, I assume you already know the “chicken and pig” roles in Scrum.  If not, go here to check it out.

Okay, pigs have “skin in the game”, and chickens…well…don’t. Since some people hate the chicken and pig metaphor, I’ve also referred to it is “committed” (pigs) and “interested” (chickens) (I didn’t come up with this, but I don’t remember who did).

The chickens are not allowed to talk in the daily Scrum meetings. They are only allowed to provide feedback in the Sprint Review (and of course at any time to the Product Owner, Scrum Master, or as requested by the Team).

I think there are two kinds of chickens. There is the kind that provide no valuable input. They historically have done nothing other than cause distractions. Whatever it is your building may have an indirect impact on their lives at best. These people are typically in some kind of management, or senior role.

The second kind of chicken are those folks we typically refer to as “SMEs” (Subject Matter Experts). We may or may not be building a solution for them. However, we rely on their expertise to enable us to deliver value. These kinds of chickens are usually are involved in legacy application development or re-platforming efforts. You probably won’t experience this group if you are doing new development. These types of chickens are needed when the Scrum team just does not have enough of the institutional knowledge needed to consistently deliver value.

Both of these types of chickens have one thing in common. They do not have “skin in the game”. If the project fails or succeeds, there typically will be little (or no) consequence for them. What they do NOT have in common is this; the involvement (or lack thereof) of the second kind of chicken can either bring a team to success, or to a miserable failure.

Teams will typically lump both types of chickens together and treat them the same way. It’s really insulting if you think about it. If I was *critical* to the success of a project but am labeled a “chicken”, and if I identify a risk, I shouldn’t have to wait to speak until spoken to (which is implied with chickens), or until the Sprint Review.

What do we call this third group? They really aren’t chickens as defined in the Scrum context. However, they aren’t pigs either since they aren’t the Product Owner, Scrum Master, or Team (those who do the actual work). We will fail without them.

Filed under Process, Roles, Scrum, Teams Tagged with ,

Face It, Your Memory Stinks

March 14, 2010 1 Comment

Seriously, it really does. You can’t remember everything. No matter how good you are at “Simon“, your memory just isn’t good enough.

Okay, so I’m stating the obvious. If we all know we can’t remember everything, why is it then that in soooo many meetings, nobody writes down what was decided, discovered, or uncovered? Sure, there are some folks that are writing “something” down during meetings. But, those are typically their own personal notes, the stuff that applies to THEM and not the team-at-large. They could be doodles, or possibly an attempt to look like they are attentive to what’s going on, when in fact, they are actually zoned out (I’m guilty of that). Who’s recording the important knowledge for the benefit of the team and organization?

I was observing a planning session a while ago. The team asked a business SME to come in and answer some questions regarding complex business scenarios. It was a rich, active discussion. People were learning new things left an right. It was beautiful. This dialogue lasted about 20 minutes or so. Guess how many people wrote this incredibly critical information down? NONE. That’s right, not one person wrote anything down. Sadly, I’m starting to realize that this is a common occurrence.

This is why we have the same meetings over and over again. How many times have you been in a meeting and you think, “Huh? We’re having this meeting AGAIN!?!?”. There is a very simple solution. WRITE IT DOWN, send it out, and store that precious information in a central location that’s easy to get to (can you say “wiki”?).

Whose responsibility is it to make sure something is documented during these meetings? It’s everyone’s, including yours. If you see that information is just disappearing into thin air, don’t hesitate…ask “okay, so who wants to take notes?” If you get no volunteers, then announce that you will do it…and then take care of it.

Filed under Process, Roles, Teams

The Cross Functional Team vs. the Functional Community

November 9, 2009 1 Comment

An agile team consists of everyone it takes to deliver value to the customer.  The typical team consists of analysts, developers,  and testers. Of course the team is not limited to these roles.  The team could also include technical documenters, DBAs, or whoever else has a hand in creating value.

In traditional organizations, “team” is defined as a functional group.  The development “team”, the “testing” team, the “analyst” team, etc.  This makes sense in a traditional, waterfall-ish environment.

In an agile, cross-functional environment, it is not helpful to define “teams” around functions.  Okay, “maybe” its okay in a production support capacity, but that’s still pushing it as there will still need to be cross-functional work with production support.

Teams have a common, unified goal. Functional “teams” do not.  For example, a functional “team” that consists of a dozen Java programmers, with each programmer on a different project, can hardly be called a “team”.  They have no common goal, other than to adhere to the (hopefully) high development standards that have been put in place.

I propose that instead of calling these functional groups “teams”, we call them communities.  Here’s a simple definition of community that I found on dictionary.com: “A group of people having common interests“.  The Java “community” will work together to make sure that they have common standards of excellence, share knowledge and experiences, and provide each other guidance as needed.  However, these people will have different goals, depending on the project on which they have been assigned.

Filed under Agile, Roles, Teams Tagged with , , ,

Sprint Planning When Everyone’s New

March 2, 2008 Leave a comment

We were working on a legacy product written in PowerBuilder. There was one engineer that had been around for a while, about 6 years. Another had been around for a little less than a year, and the rest were brand new. The entire QA team was new. They weren’t only new to that project, they were new to QA. There was also a team of business analysts. Most of them had been around for several years, but there were only 2, and this was a big project.

As to be expected on teams such as this, the process was very waterfall-ish and chaotic. The team waited for the BAs to create “the specs”, and QA waited for engineering to do the coding. Lots of waiting.

It was my job to implement Scrum at this company. We finally had a product backlog that was prioritized, but that was about it. Even though that was such a small accomplishment, it made a very positive impact on the team. Before this, the team never new what to work on next, and usually worked on things that had to be abandoned later.

So, we have a product backlog. We still hadn’t conducted a release planning or a sprint planning session. I decided to start with a sprint planning session.

Sprint Planning Session 0 = Miserable Failure

Our first sprint planning session was a disaster. First of all, the QA team did not show up. I almost just canceled right there, but I thought I’d continue this disaster.

We projected the product backlog (which was in excel) and started going down this list. The goal was to define “Done” for each item, and also to decompose it into smaller tasks, with each task less than 16 hours.

We got stuck on the first item. Everyone said “I’ll have to go back and look at the spec” for every item we brought up. And if there wasn’t a spec, it was just impossible. Everyone just stared at each other like deer in the headlights.

I also heard the engineers say things like “we’ll have to go into the code, it will take a couple of days to break this down”. Or “there is no way we can break down this 180 hour task” (yes, they had estimated the product backlog items in hours).

We canceled the meeting about 15 minutes into it. While I was very disappointed that it failed, I was excited to have a new challenge. In addition, it was great that I learned something about the inner-workings of the team. How do you conduct a sprint planning session when no one knows how to implement the features in the backlog?

Sprint Planning Session 1 = Moderate Success!

I was sure that the team just needed to do homework. But, after talking with the old timer, I realized that homework was not enough!

The code base was extremely unstructured. It had grown over the last 12 years into something really ugly and barely maintainable. Not even the engineer with the most experience would have been able to come up with sprint tasks that were 16 hours or less. I got some great advice from someone on the yahoo scrum group, about maybe using spiking to help decompose the backlog items. While I love the idea, there was no way we had time to do this on every item.

So, here’s what we did. We encouraged team to do some research on the upcoming features.

Then, in the sprint planning session, the team self-organized into smaller teams, and dug in deep on the features. We printed specs out for them, and of course had the BAs there (which were ultimately playing the role of product owner).

The engineers had their laptops so they could look into the code if necessary, I suppose doing “mini-spikes”.

This time QA showed up, but they were there in bodies and not in spirits. But, that’s a subject for another post.

We still did NOT come up with a sprint backlog. I was a little disappointed in that. However, the team came out feeling like a true team, and with a clearer understanding of the sprint ahead of them. We also had a clear commitment (which the business broke, again, for another post).

It was a definite step in the right direction. While we weren’t able to derive the sprint backlog, the team bonded during the exercise. The team also understood what they needed to deliver (they just weren’t sure how at that point). In addition, we realized where our problems truly existed.

Filed under Scrum, Teams