Why self-organized teams are so important

It's a situation that I run into with new Scrum teams all the time.

Their work is complicated you see, there's all of these dependencies for every backlog item to be implemented and each task needs somebody with a special skill and we have to schedule how each person with the correct skill will finish each task in a certain order so I need some way of planning all of this and managing it within each sprint. Before you know it, there's gantt charts up on the walls and people are calling other people "resources". This is the reason why I keep my migraine medication handy at all times.

The problem here is that the very first assertion made here is absolutely true. Implementing a new feature in a complex system is complicated and there are certainly more factors involved than any one person can manage effectively.

Luckily the solution is actually rather easy. Make the management of this complexity as close to the work as possible, this actually means removing the project manager and allowing the team to decide for themselves how the work should be done.

Now almost as soon as you start doing this you'll begin to find impediments to the team getting their work done. The most major of these is that many new features and bugs need more than just a single person to complete them, at the very least you'll need somebody to code it and somebody else to test it but you may also need someone to modify a database or code a UI or design graphics or write up a help file.

To be clear, I actually don't agree with the approach of classifying developers by specific competencies. I feel like a developer should be able to code something into an application from beginning to end regardless of which part of the app needs to be modified. This makes development much easier, a complex feature may be developed by a single person and the only reason another person may be needed is for testing or pair programming.

I do realize that this is not always possible in every organization so I invite you to the middle ground: the self-organized cross functional team.

Cross functional means that the team as a whole includes everyone needed to implement any backlog item from beginning to end, including testing. This means that the team will consist of UI designers, Backend Developers, Database Administrators if needed and definitely testers.

Self-organized means that the team decides as a group how to implement those backlog items. This means that if a feature was started by Joe the UI developer but he needs something changed by Jim the DBA then all he needs to do is tell Jim to make that change when he gets a chance, no complex scheduling needed just individuals and their interactions getting things done.

Now in order for this to work you need a lot of collaboration between team members. Please note that this does not mean that the developers spend more time shooting emails back and forth, it means that they spend more time actually interacting. Preferably with real face to face communication.

 In many cases a lot of this collaborative talk will be done during the daily standup as developers chat about what they're planning for the day and their impediments, as a Scrum Master you'll want to allow enough of this during the standup for them to plan out who they'll team up with to complete their work but not so much that it makes the standup longer than it should be. Get used to the phrase "You two should be able to work out the details after the standup, let's keep moving". Also, try to keep the team from planning their individual plans more than 1 or 2 days ahead of time, any more than that and plans become hazy.

You may also consider a couple other options for increasing collaboration (and therefore the team's ability to self-organize) by removing the cubicles and allowing the team to work in a single room with no walls separating them. This way if a developer needs somebody else for a particular change or task they can simply ask them without having to visit their individual office or cube. When doing this (or when deciding on teams in general) keep in mind your individual team sizes, a team larger than say 9 people will begin to find it difficult to communicate as a group effectively and you'll actually begin to hinder collaboration rather than help it. The ideal team size is 7 plus or minus 2 and the same should hold true for your team rooms.

Finally, it never hurts to encourage the team members to become cross functional as a whole. Introduce the team to pair programming. It's up to them to adopt it or not or to modify it into something that fits their own team culture but the more they can see of code outside of their own specialty then the easier it will be for their team to take on complex work.

Scrum: The Test Heavy Backend of a Sprint

You might hear me mention at some point that as a Scrum Master, I don't really care about the technical details that make a product backlog item done. I only really care about some form of measurable daily progress and the fact that these backlog items actually get done.

So, does that mean that the method for building said software is unimportant? If all you care about is Scrum and that which Scrum defines for you, then yes, it's unimportant. If you care about actually making working software (which is the real goal), then it's not just important, it's vital.

Ask yourself this, why do you always hear about test driven development, pair programming, code coverage and other software engineering techniques when talking about Scrum if Scrum, as a framework, doesn't define these things at all? Because, they solve problems that Scrum teams will likely run into. When a team builds software with traditional project management, there are certain problems that tend to hide themselves (or at least make themselves easy to ignore). Scrum brings these things right up to the front and forces these problems to be solved.  Most of the time these problems are technical in nature and should therefore be resolved by the Scrum Team (not the Scrum Master).

This is one of the reasons why eXtreme Programming (or XP) is often paired with Scrum. Many of the techniques found in eXtreme Programming tend to solve problems that a Scrum Team is likely to uncover.

Let's talk about only one of these problems/solutions for now.

When a team first starts developing in short iterations (which Scrum has you do), they will probably fall into a very common trap. They will finish writing the code during the first part of the sprint with the assumption that the latter half will be spent testing. Here's the thing, this could actually work if you didn't find any bugs in testing, but you will. So in reality, you'll have the latter half of the sprint to find bugs, fix them, retest them, and fix any new bugs that the fixes introduced. It's a confounding problem because individual bugs can't be anticipated and therefore make estimation a nightmare. What we need is some way to normalize the time we spend on quality in the software, so we spend less time chasing bugs.

Let's try this again; let's say I'm a developer in the middle of a sprint and I pull a backlog item from the sprint backlog, but instead of immediately writing code, I take a second to chat with a tester about how we'd like to test this when the item is done. While we don't know what the code will look like yet we do know what the finished code should do so we create a test case together and I go about writing code to make that test case pass. Once I'm done writing my code, I know that it'll pass the test we wrote but I pass it off to the tester just to get another set of eyes on. He confirms what I already know, which is that the backlog item is Done and we're that much closer to finishing up the sprint.

In both cases, we still tested, but by writing the test up front, we can gain some insight right away on how the code should be constructed.

Notice that I'm not telling you what tests to run, only that you should define the tests before development. The tests themselves may be anything from writing an actual unit test before writing the actual code or it may be as simple as a conversation of "I'm going to do X, Y and Z when I test it" before you sit down to make X, Y and Z possible in the product. The more detailed the test plan is up front, the less likely that you'll run into last minute surprises and that makes everyone's life easier.

Related Posts:
Your First Scrum is Going to Suck
What does a Scrum Master Do all Day?
What is the Deal with Story Points when Estimating?

No New Post Today: Go watch the OnTime v11 Launch Live

Hi Everyone, I normally try to have an article up and written at least every Tuesday but I decided that just this once you might be better served by watching the OnTime v11 (The Scrum tool that we make at Axosoft) launch on Axosoft.com. Our CEO Hamid will be demonstrating the tool and talking about everything that went into making it our biggest and most ambitious project ever. Starts at 11:30am Pacific Time tomorrow, see you there!

Organizations Against Scrum: Iterations First

"Scrum doesn't work here"

"We tried Scrum and it introduced a bunch of problems"

"We failed a big project because of Scrum and management doesn't want to try it again"

I hear these things every now and then and they stick in my brain. My first thought when somebody says something like this is that Scrum didn't cause any problems, so much as it exposed problems that were probably already there. As you can guess, this can cause some mild discomfort in any development team.

For instance, you say, "We never had enough time for testing at the end of the sprint"

And I hear, "We trade quality for speed in development and we immediately see the effects of that decision within a sprint". Essentially, you're seeing that you actually do not gain any time by hurrying development in the beginning, you just push it off until later and that's uncomfortable for your PMO to hear (although your developers have probably been telling you this for years).

That isn't a problem with Scrum, but it is a bad habit your organization has developed over the years and Scrum will pull that out into the open for you to fix. This is not a failure of Scrum, in fact some would argue that it's the whole point of doing Scrum to begin with. If you fail to fix your testing problem, then it's likely that you'll feel the effects when testing comes around anyways. This would be true in a waterfall project as well, the only difference is that the time between the issue and the consequence is longer in a waterfall environment.

I could go on with at least a dozen or so more examples, but at least with this post, I'm not going to go into the myriad of different ways that you can force a development project to fail using Scrum (that's a very long post for a future date). I'd like to talk about how to reintroduce Scrum to a wary audience.

Don't call it Scrum.

Yup, it's that simple. Start with something basic like building in iterations. You can even grab work from the schedule based on due dates to decide on your sprint backlog if you can't get a product owner to provide priorities. Start building in iterations and inspect and adapt after every single one of them.

The iteration (or sprint) is the cornerstone of Scrum and also the hardest part to do because it exposes problems and this can cause some discomfort. You'll discover things like how poorly your team estimates or how bugs really affect the productivity of the team (this often hides in the latter part of a waterfall project and is quickly forgotten by the time the next project rolls around).

Solve these problems over your first iterations, earn some credibility and then start implementing more Scrum and Agile concepts. Remember that when attempting to convert a skeptic, the best way to start is to show them something concrete rather than asking them to take a leap of faith.

*Disclaimer* I'm not suggesting that you introduce Scrum to your team like this, if you're new to Scrum then try to do things close to the correct way as possible. The iterations first method should really only be used if your organization is specifically entrenched against Scrum to begin with and you need to establish Agile. *Disclaimer*

Related Posts:
Implementing Scrum - The Top Down Approach
Implementing Scrum - The Bottom Up Approach
Your First Scrum is going to SUCK!

Don't Crap in the Product Backlog

I've got news for you, if your product backlog has so many items (stories, features, bugs, back log items, call them whatever you like) that you feel the need to create a web of dependencies that you then need to visualize in a chart or use some other huge time sink, then you're doing it wrong. There's too much crap in your backlog and you're drowning in it.

This is an astoundingly common problem and one I deal with on a daily basis as I interact with various Scrum teams. Here's what the problem looks like:

1. Change wording in system options from "Foo" to "Bar" in random context menu.
2. Move dropdown menu in system options from "Bar" tab to "Foo" tab.
3. Simplify security settings for "Foo" in system options menu.
4. Other random change to system options that is too small to ever make it into a real sprint

Multiply this by every feature in the product and you end up with a backlog spanning 100s if not 1000s of things to track. The problem here is that any tools you use to manage this behemoth product backlog is really just masking the problem bigger; you're getting lost in the details and missing the bigger picture.

Don't look for ways to manage everything, look for ways to make everything simpler and the problem will solve itself.

So what should those 4 backlog items look like?

1. Optimize the system options menu

That's it. Each of those 4 original backlog items are bullet points inside of the bigger one and I've effectively shrunk the amount of crap I have to manage by 75%. Do this with your entire backlog and you'll get something you can actually refer to in conversation with the team.

Product Owner: I'm thinking we should probably get around to the menu item in the backlog

Team: The whole thing or just parts? I took a peek at it last week during Sprint planning and it was getting pretty big, that's one of the reasons we didn't do it then. Has it changed much since then?

Product Owner: I've changed it a little since then, but I don't think we need the whole thing done by next sprint. I'll pick out the bits I like and send it to the top of the priorities, but we've been putting those changes off for too long already.

As opposed to:

Product Owner: There's a bunch of menu changes in the backlog I'd like to try to get some of them done in the next sprint.

Team: There's work for the menu in the backlog? We never got a chance to look at the whole thing during sprint planning. What kind of changes are we talking about? I haven't had time to even look at any of the menu changes yet.

In the first example, the Product Owner can refer to something in the backlog and the team knows exactly what he's talking about. In the second example, the conversation needs to refer back to an artifact, list or tool for even general conversations.

You'll notice by the way, in the first conversation, the Product Owner wasn't afraid to pick out the bits in the backlog item that should be implemented, in effect, he's splitting the product backlog item, but he's only doing it when he needs to. The same thing will happen with the estimation; the team will estimate the new backlog item that's high enough in the priority for them to do. The other will probably sink lower into the backlog and doesn't need to be estimated until it makes it to the top again. If the item needs to be split again to fit it into the sprint then it's usually handy to have the Product Owner around so he can help figure out which half needs to make it into the sprint.

So, what about when feedback comes in? After all, the backlog is filled directly (if possible) by the stakeholders and those ideas are likely to be fairly small compared to our new larger items. The product owner should look at each and every backlog item that comes in and if the item doesn't seems similar enough to other backlog items, it should be assimilated by another item.

More objects, more moving pieces means more administrative overhead for the Scrum Master and the Product Owner (they have enough going on as it is). Like most things in Scrum and for that matter like most things in life, make things as simple as possible (but not simpler) and only add complexity as the need arises.

Related Posts:
6 Things a Product Needs to Know
Should Your Scrum Team Stop Using Story Points?
5 Big Issues when Scaling Scrum