On a few occasions in the past I've been asked about some of the problems you can have in implementing scrum.  Something about having already made (and learned from) plenty of mistakes seems to make me qualified to give advice on what not to do, and to offer a few tips on approaches to take.

There are plenty of other resources online that can help people but trawling through mailing lists looking for the information you need but these things take time and most mailing list threads degenerate from their original subject, and newbie questions can sometimes raise the ire of others.  And then of course there's just no substitute for having a one-on-one conversation with someone else about the experiences they've had (i.e. having a mentor)

Paul, one of my former staff, left a while ago to join a large corporate in a team leader role.  It's a good opportunity and gives him the chance to stretch himself, which should be what anyone looks for in any job.  Unfortunately the organisation it still stuck using the traditional waterfall style SDLC and he has a real problem with his team members being unmotivated, uncaring and lethargic.

What to do? What to do? Well, it was obvious that the current way of doing things wasn't working so he needed to shake things up.  Having come from a scrum based environment where agile was working, and working reasonably well, he decided it might be worth a try. He's only just started the initial introduction of scrum with his team, and given their reactions I'd say he's got his work cut out for him.  Before he got started though, he decided it would be worth asking a few questions to see how things could be done.  Here's some (edited) parts of the conversation that you might find useful...

 

[Paul]: I am thinking of implementing AGILE within my team on a small scale, can this work with a development team of 4?  Also what tools could I use to track (that are free) their progress such as how many hours are left on a task level, comments etc.
I also want to provide the business after each project the differences between what we estimated for and the actual development so we can get an idea if we are over estimating or not.

[Richard]: Agile for a team of 4 will work fine.

The best tool for progress tracking is either a whiteboard (seriously!) or Excel - as you can hack a spreadsheet around to suit your needs pretty easily.  There’s other tools out there such as scrumworks from Danube but I wouldn’t get too excited about that sort of thing just yet as you need to get the team used to agile first.

I assume your tracking of actual vs estimates will be based off timesheets or some other time tracking system.  If so, try to make sure that the time tracking has a reference back to the sprint item you’re working on.  If not it can be a real pain to try and marry them back up.

 

[Paul]: Thanks for the info about the tools.    Reference to the timesheets vs estimates, we only track again project codes, not tasks which makes it harder to track so I will need another approach for tracking this.

[Richard]: You might want to try using a simple alternative then.  Maybe just another excel sheet that mimics the sprint backlog and where the team can stick in the actual time spent.  Don’t put it on the same sheet as the backlog though, as the backlog is for burn down and estimated time remaining, while the other is actual time spent.  2 very different things

 

[Paul]: Though my company cannot truly support SCRUM in the sense of requirements, priority etc (requirements are done independently to us) but be able to implement the same principle within my team.  We currently work in a Waterfall style approach (in general) and each team (being me or another team) are given requirements as a whole.  So what I want to do is to have many small sprints (lets say 2 weeks),so at the start of each sprint each developer (like we did) choose which requirement they want to do and they go away and do it.  At the end of the sprint, we go and do a demo of what they did and to show the business their progress.  Any feedback at stage would go into the next sprint.

[Richard]: Take little steps.  One suggestion though – don’t give the team the choice of what requirement to do.  Tell them the order of the requirements (you set the priorities) and get them to tell you how long it will take.  You can obviously do this sprint by sprint, but you might also want to consider getting a high level “run over the target” first.  That is, when the requirements first land on your desk get the whole team together and do a quick ballpark estimation of each item – it will give you a feel for wether the requirements are even possible in the timeframe the PM has given you.  If it is – great.  If not – you’ll have some negotiation to do.

What you should also do is track the velocity at which you are completing those initial estimates (don’t change them) so that as sprints progress you have a more accurate sense of when you’ll be done.

The demo is very important!  Make sure the PM, BA’s and the project owner (if possible) are all available to see the demo and have a hands on session.  The open communications will get you loved by all (even when sprints fail).

 

[Paul]: I was also thinking have a once a week (for now) on a Monday morning that my team gets together for 15 minutes and to discuss what we have done for last week and any issues they may have.

[Richard]: I’d strongly recommend daily.  Daily will help encourage teamwork – once a week will seem more like just another meeting and won’t do anything to build communication between people.

 

[Paul]: Once my team have got used to it, hopefully they can see how well we work together.

[Richard]: Hopefully :-)  If you remember what we did, we actually did a mini-sprint first up.  A 3-day experiment to prove we could do it, and to prove we could have something tested and demoable in that timeframe.  It might be worth trying a 1-week sprint or 2-day one first up.  Also, you should think about spending time explaining the why’s and wherefore’s of it all first.  If you want presentations or overviews you can borrow mine or use the resources from mountaingoat software (they’re quite good).

Be prepared for the first few sprints to be a bit awkward and to fail.  It takes time to get into a rhythm with this stuff.  You might also want to ask around and see if any one has worked in agile teams before.

 

[Paul]: All our project(s) are release on a three month cycle, for example, all development must be done by X date which is when we hand over to to the test team etc.  My first sprint is going to be next week (Monday) for 2 days and another 2 day sprint, then 5 days then 14 onwards (depending on project).  At end of each sprint (after the dummy run) I will get my team and the main BA in one room to perform a demonstration to them and get feedback.

[Richard]: That’s a good plan.  As long as the main BA fills the “product owner” role you should be fine, but you may need to talk it over with them first.

 

Paul has now commenced the initial sprints with his team and I'm curious to see what lessons he and his team will learn as they take this journey.

If you have questions you'd like to ask about Scrum and how to implement it the best way is ask people you know who've done it, ask in the newsgroups, or feel free to ask me.  I'm always open to talking to other people about this sort of stuff and I'd love to help you.