So my current team is doing Scrum. We are on our 2nd iteration, so it’s something quite new, but I’m already seeing some signs that worry me. Before I get to them, though, I’ll document here some interesting reactions I’ve received from people when I mentioned “scrum” (in a completely different context – I had tendinitis not too long ago and I told my techie friends that it was the result of my fight with the scrum master):
“Oh, you do Scrum? I’m sorry… We do it too and the only interesting things we’ve delivered happened when somebody just got outside the iteration and worked on things in a scrum-less fashion”
“Are you doing Scrum? No? Great! Run away!”
“Scrum? Argh…”
Yes, these were real reactions of people that will be kept anonymous. So all these people had the experience and had their reservations. Why? Well, now that I have some experience with it I’m starting to get an idea why. But before I get to it, I’ll try to smooth it out by talking a little bit about what I think is great about it.
- Visibility: You know what is going on most of the time. If somebody is struggling to get something to work, you know at the time the struggling starts and not 2 weeks later when this person can’t deliver what they said they were going to.
- Nimbleness: Because things are sort of decided day-to-day, it’s easier to readjust plans midway. Things change all the time in most industries.
- Communication: Sometimes considered the most important aspect of Scrum (or any Agile methods). It forces you to discuss things with everybody all the time. It encourages people to argue and move as a group. This facilitates integration and sharing of information and experience throughout the team.
- Well-defined end: by forcing deliverables at the end of the iteration, it forces people to just get it done with. Considering a project finished, especially when it involves “fuzzy” things, like UI and operations support, is hard.
There is more I could add to this list, but I think these are the most important positive aspects. Now onto my concerns:
- Distancing of the specific person on the team to the project: because all projects are “shared”, each team member ends up losing that maternal connection to the code that is generated. It’s not something that is yours anymore. You lose the will to just stay late to get something extra done, as nobody else is doing it anyway. Your personal life might appreciate it, but I’m not sure this fulfills the coder inside you.
- Focus on deliverables generate internal operational mess: it’s hard to explain to a client why you chose to take 5 days to do something that you could have done in 2 just because you claim that this will make your life easier to deliver something that is only scheduled 2 months from now. Or because you think that if you choose the slower way you will get something that will be easier to deal with in cases of operational emergency, even though this might only happen 2 years from now. I think I’ve been through operational headaches enough (I was just on call) to know that the more you can build already thinking of operations on failure modes the better. You can never predict all failure modes, but covering as many as you can is the least you should do.
- Very long iteration planning meetings for something that is very likely to change in the future. This is aggravated if the team is quite efficient and has a lot of things that they can do in the iteration. You plan them all (for example, we have something like 9 projects planned this iteration) with 1-2-day long tasks, taking many hours of your month to do that and then, in about 2 weeks you find out that half of the things you’ve spent all this time to plan will be pushed out because something else showed up. Maybe this is more of a failure of my own team, but I just think sometimes there is too much of a granular task focus and building 50-100 granular tasks in a meeting is tiring and very error-prone. So if it’s going to be wrong, why do it this granular this early on?
Anyway, we’ll be moving on with it. We’ll learn with it, we’ll deliver a lot of things, and then we’ll adapt the process to whatever really makes sense to the problem space we are dealing with.
Is this a joke post? It is positioned as “I’m worried about scrum”, but I think it’s more positive than negative.
You list 4 good things and note you could list more. You only list 3 bad things. Your first bad thing seems to be a complaint that scrum keeps you from wanting to work overtime. Why can’t the “coder inside us” enjoy life outside of work?
Granted I’m an advocate of agile including scrum and xp, but I also know it’s not right for all environments. My advice… make sure you have a good coach helping you through the transition, and keep trying. I found that it takes at least 6 iterations for the team to start getting it. Hopefully your iteration is short (2weeks or even 1week) so that you can get through this learning cycle quicker.
Other advice besides coaching… look into non-scrum agile philosophies like XP, Crystal, etc. Scrum solves certain problems, other agile techniques will solve different problems. XP is more for the “coder inside you”. Scrum is more about aligning the coder to the manager and creating a happy relationship. (My oversimplification.)
Good luck.
Thanks for the comment.
I do want to be more positive than negative about it. I think that in theory makes a lot of sense. But, like all theories, when applied you have to adjust it and we are certainly still adjusting to it. Actually our iterations are not very short (whole month=long iterations), so it will take us some extra time to adjust.
I guess my background as a researcher and “framework engineer” is quite contrary to the concepts of “writing small things and release fast”. I never actually had a client drooling to get new features on the product. So there are lots of things that I need to learn to adapt to.
I’ve studied XP before and even did some of it. I had a co-worker that was very excited about it and would spend his day refreshing his XPlanner report page. But soon the team ended up assigned to so many different projects at the same time that it made very little sense to have an “interaction planning” meeting in the morning, as nobody was really interacting with anybody and most of the time everybody were bored with what the other people were doing. And without interactions, we just moved to a centralized status keeping (through our manager) and scheduled architecture review meetings so that people could spend an hour on context-building and explaining what they were doing. It worked. We delivered a lot of interesting things!