Blog

Scrum Journal: Introducing Scrum with a new client

One of the things we take pride in here at OpenSource Connections is what we like to call the OpenApproach.  The OpenApproach is our implementation of best practices for software development and project management, and is largely based on the concepts of Agile and Scrum.  In addition to providing development services to our clients, we often coach our clients on OpenApproach techniques so that they can improve their own development environment and learn from our success on other projects.

Most recently, I participated in a Scrum team on our own internal software development project:  AeroWebOnline.com.  This was a very time sensitive project with various OSC developers going in and out of the project, geared towards a product launch at the AAAE conference in New Orleans.  That project was a definite success, although one Scrum lesson we re-learned was that 1 week sprints really are too short, and 2-4 week sprints are much more effective.  As both a developer and a project manager, I really find Scrum rewarding because it keeps me aware of what’s going on in the project as a whole, as well as very focused on my own development tasks.

We started the first sprint planning meeting with an overview of Scrum from this great document.


 

Currently I’m with a new client of OSC, and we’re on another time sensitive project with up to 8 developers (though most also have other project obligations), an architect, a project manager, a business lead, and 2 QA/build staff.  It’s a big project with a tight deadline and for several reasons I felt Scrum was the perfect approach for this project:

1)      The team needs to have improved communication and a real time sense of how the project is going and what everyone is doing on it, without introducing a heavy process.

2)      The business needs strong insight into the project, because the deadline is very important to them.  If the timeline doesn’t go well because developers are on too many other projects, they need to be able to see that effect directly.

3)      Developers need to be encouraged to trade tasks and to cross train, because since many of them will be called on for other projects or production support, it’s essential that the project not be too dependent on any one developer.

So I pitched the idea of Scrum to the team leadership, and we’re going forward with it.  I’ll record here some of our experiences so far, how Scrum is helping us, what we can improve on, and the team’s reaction to a different process.

We have essentially a one month timeline for the project, so we decided to split it into two sprints of two weeks each.  Last Friday we had our planning meeting for Sprint 1.  Since this was the first introduction of Scrum to the whole team, I started by giving a talk about Scrum and showing examples of past burndown charts and task lists in other OSC projects, and talking about the responsibilities of each Scrum role (developer, scrummaster, and product owner).  I used this “Scrum in 5 minutes†document as a set of talking points for the presentation.  But no, it didn’t take me 5 minutes.  It actually took about an hour of me talking and the team asking questions.

Scrum Poker cards on the table, donuts in the middle, what else do you need?


But after that, we went right into planning for Sprint 1.  I setup the sprint planning spreadsheet in Google Docs as we do with most of our OSC projects, and I served as Scrummaster in the planning meeting.  However, my goal is not to be the Scrummaster myself, but to train the client’s project manager on how to be a Scrummaster so that they can continue this process on other projects.  So while I served as the Scrummaster for the first planning meeting, she is now leading the daily stand ups, and I expect she will lead the planning on the next sprint with my guidance.

The architect for the project had already prepared his own set of goals for the sprint, and so we used those as a starting point with the team, which the rest of the development staff added to.  The team as a whole came up with their own list of sprint tasks for those goals, which took us another hour and a half probably.  There was of course much discussion about the tasks, but it was my job to make sure that discussion did not go into “implementation details†so that we did not get into too technical or indepth of a discussion.  That was a real challenge, but for the most part we did it.

Team members hold scrum poker cards close to their vest while estimating tasks for the next development sprint.


 

After all the tasks had been laid out, we moved into task estimation.  To do this, Eric Pugh strongly suggested that we try Scrum poker.  I was a little skeptical how well that part might work, but I was really pleased with the results.  We didn’t have time to order the official Scrum poker cards from Sweden, so I cut a stack of index cards in half and everybody got cards with these values on them:

?,2,3,5,8,13,16,20+,donut.

Some of the developers also had fun adding their own cards to the mix.  Chris added a pizza card when it got close to lunchtime.

Chris indicates he's ready for a lunch break with the Pizza card.


 

So how does it work?  As the Scrummaster, I would read the next task off the list, and ask everyone to pick a card from their deck.  When everybody had set a card face-down on the table, I would say “flip†and then I would read off the estimates given around the table.  The 20+ card was used to indicate you think the task will take longer than 2 days and it probably should be subdivided into other tasks.  The donut card was used to say “my brain hurts, pass the donuts.â€Â  And the question mark card was used to indicate you didn’t know enough about the task to make a reasonable guess.

Those who gave the lowest and highest estimates would be asked to make a quick case as to why they made that estimate.  Sometimes those defenses would lead one or the other to realize they had made an incorrect assumption about the task, and the team would quickly be able to agree on a reasonable estimate.  Other times, it brought out important points about the task that we then used to make a better estimate with.

Scrum poker addresses a real problem in task estimation, and I was really pleased with the results.  Normally, if you have a group of developers and ask them how long it will take to do a task, someone will speak up first and throw out a number.  No matter whether that estimate is really high or low, the fact is that most other developers are now going to give estimates somewhat similar.  Even if they would have guessed a much higher estimate, they will now downgrade theirs because they don’t want to sound like a slacker compared to the initial low estimate.

I think that would have definitely happened with this team, because I observed that the developer who was probably the most confident in his estimates was also the most optimistic in his estimates.  Without Scrum poker, I think we would have had a much lower set of estimates and we would be less likely to hit them.

Estimating the tasks took about 2 and ½ hours, and was the longest part of the process, though I think the end result was good. 

The final thing we did was to assign the tasks.  In Scrum, the best way to do this is to go “round robin†around the room and each developer picks one task at a time, until no tasks are left.

However, we had been meeting for a long time at this point and people were fading.  The project manager asked if we could just print out the task list and pass it around our desks to assign the tasks.  I acquiesced, but in retrospect I should not have given in.  At that point, I essentially lost control to enforce the process, and instead of people signing up for one task at a time as they were supposed to, developers signed up for multiple at once.

The end result of this Scrum “faux pas†was that developers stayed in their comfort zones too much, and that there is not enough cross-training among members in my opinion.  The architect took all the tasks around a rules engine, and a senior developer took most of the tasks regarding how the workflow would be implemented. 

This was a definite downside of the process in my evaluation, and one that could have been avoided had I not allowed meeting fatigue to get the best of us.  However, I think this will fix itself to some degree because some of these tasks will have to be traded around over the course of the sprint in order for everything to be done.  It’s nearly a week into the sprint and that is exactly what’s happening.

All in all though, introduction of Scrum into this team has gone very well so far.  The developers have responded well despite the fact that I introduced Scrum to them in something of a top down fashion (Ideally a movement to adopt Scrum would start with the developers, not with management, although I felt in this particular case it was critical that I get buy-in from the management of the team first).  The project manager seems to really like the process, and commented to me that “this lets me manage projects the way I want to anyways.â€Â  And the business seems excited about it because they get to keep their finger on the pulse of the project without being too intrusive on the developers.

Two days ago one of the senior managers in the company came up to me and was talking positively about Scrum and what we are doing on this team.  Although he had not been in our Scrum meetings, word about the process is getting around the company.

Halfway through Sprint 1, our burndown chart is starting to make downward progress.  The first few days were somewhat flat because most of the development team had tasks from other projects to finish up.


 

Finally, since we’re nearly halfway through the first week of sprint 1, I’ll show the burndown chart as it stands right now.  You can see that the first few days very little apparent progress was being made.  This did not surprise me, because at this point all the team’s developers except one are still being assigned small tasks or even large tasks on other projects, and so they keep having to divert attention away from this project.  Just in the last day that is starting to change and more work is getting done, so now we are starting to see a steeper drop in the burndown chart.  I think having that chart is helping to communicate the effects of side projects and reinforce the deadline of this sprint.

Ultimate success of a process is determined primarily by the end result of a project, and so it will continue to be interesting to see how this sprint and subsequent sprints will go.  But so far, Scrum is working quite well!