What do you like and what do you not like about the scrum process?

Question

I'm on a team that uses scrum for our development process. We are currently trying to revamp certain aspects of our process to address some of the problems we've noticed lately. In doing so, we are exploring what it is that we like about the scrum process in general as well as what we don't like in order to help us identify what we as a team values in our work. We figure that if we can identify what we value, then we can come up with implementations that revolve around the values to help new solutions stick within the team.

With that said, I'm really interested in how other people view the scrum process. What was it that you really like about it? What was it that was frustrating and felt like it was too much overhead or non-productive? Specific examples of successes and failures are fine, but I'm interested in a much larger view where discussion revolves around pitfalls of scrum or where scrum really shines.

Thoughts?

Answer 1

I don't like when managers implement scrum process as just quick release cycle, with all other aspects the same or worse as waterfall.

Answer 2

This is a pretty broad question! Here's my take.

I think what Scrum is really good at is teaching organizations to love agile / iterative / incremental / lean software development. For a company that's used to a command and control hierarchy of project management, the empowerment necessary for teams to succeed at being truly adaptive to their customers' needs is a massive cultural shift. Scrum makes all this approachable for organizations, with clearly defined roles and processes.

Basically, to me, it buys a team of programmers the space they need within all the politics and bureaucracy of a big company to get on with doing XP.

However with this empowerment comes responsibility. Scrum does not mandate any of the XP engineering practices, but without core practices like CI, TDD and refactoring, any scrum team will splutter to a halt after a few iterations. I personally think it is quite irresponsible for this not to be explicit in scrum's 'rules', and that would be one of my criticisms.

My other criticism is with task cards and task planning. I have yet to see a team where this was really effective: usually there's a very tiring day where you try to think through everything you'll do on the whole iteration, then you get going and find you actually needed to do something different. Measuring progress through task burn-downs feels like a good way to get teams to collaborate and bond (especially if you disavow task ownership) but ultimately it isn't a reliable way to track the progress of a team.

I place a lot more emphasis on burn-up of value or story points, and these days usually get the team to do a daily update a big Cumulative Flow Diagram chart of where we're at with that instead. The tasks stay on people's to do lists, but they don't go on the board or get managed by anyone.

The key practice, of course, is retrospectives. Mike Cohn's counter-argument to my earlier point about the XP practices is that with retrospectives, teams will end up inventing / adopting XP anyway, and this does have some validity. Certainly regular introspection is the best way of all to make sure your team is and continues to be as effective as it possibly can.

Answer 3

I think in my experience the key is to understand how those from the business and management choose to implement parts of Scrum and/or Agile, or in other words their interpretation of the buzzwords.

I like the idea of daily standups where everyone says what they did yesterday, what they plan to do today and what roadblocks they have as this creates accountability assuming there is respect and honor for lack of a better term to say it.

The task cards and their evolution can be useful for others to see what is going on, as well as for someone to get the idea of whether or not they have something nailed down. Cards do make for their own communication channel to some extent which can be good or bad depending on how you view it.

Retrospectives and Iteration Planning meetings are generally useful as a way to get everyone onto the same page as well as allow for feedback about the process to help improve it from whatever angle someone sees it. Having a good leader is essential here I think as these meetings can be less than productive if the team goes on a tangent or two.

I find retrospectives to be very similar to post-mortems that I've had at a previous workplace. I find them to be very useful for a couple of things:

1. Seeing what others find to be commonly good or bad. Was testing a big issue? Was new employees coming in when there was only 2 weeks or less in the project helpful or not?

2. Allows everyone to have their say. This can contribute to a sense of belonging and teamwork that can be useful at times when you want someone to burn some midnight oil or work late here and there.

There is the challenge of keeping the daily standups to be quick, but if there is a certain amount of practice done then it becomes more natural. To some extent the process around Scrum can amplify good habits and bad habits depending on how it is used.