I agree with your position. In my experiences the PO as part of the team is integral to success. Early on, we were pretty strict about product owners not speaking in stand-ups and found this caused all sorts of issues. We have external clients, and these product owners represent the customer. If we are not listening to them do we not defeat the purpose of rapid feedback cycles. When we changed this to make the account managers (product owners) a more integral part of the team with a voice, we saw immediate improvements and reduced cycle time.

A great post – always useful to check what we are doing within our own team with some of the practices that other people are finding key to their SCRUM!

One of the elements we love the most is our SCRM Wall – check it out at:

http://www.buildmasters.com.au/2008/08/01/a-victory-for-scrum/

The visibility acpects of SCRUM are the thing that have helped us the most with the successes we have had on our program. Both in terms of aiding collaboration within the team and making what we do visible to the other stakeholders (who are many!).

We love SCRUM!

The idea of tasks being either done or not (binary) is something I use all the time after reading about it in a Steve McConnell book many moons ago. It works.

With regard to Scrum Masters – I am still of the strong opinion that you need them. The team may well be self-organising but the Scrum Master comes into his/her own when they are faced with constraints that the team need to be resolved in order to progress. A good Scrum master will chase those constraints down and get them fixed allowing the team to press on with what they are good at, and most likely enjoy doing the most – developing and delivering software.

I completely agree with you on all of your points mentioned above. However, if you just blog and not do anything about this, then eventually the ideals will be forgotten, I feel instead we should start our own alliance challenging the Scrum Alliance and come up with a more flexible process that will better suit challenging business environments.

I have introduced SCRUM in my organization and had many challenges and issues when following traditional SCRUM process. SCRUM cannot go alone without agile engineering practices, it has to be truly combined with TDD or some other form of Agile development to truly make it an agile process.

I have been using all your ideas except #3 with many teams over the past couple years. The notion of tasks being either done or not (binary) is something I’m aware of and have described as an alternative that the teams may want to try. They haven’t yet, but this goes to a point I’d like to make. I think I do best as a coach if I teach folks the fundamental principles underlying agile (and lean) and then encourage them to view all practices from the various flavours of agile as things for them to pick from, as they work to better apply the fundamental principles.

So I want to chime in with a vote to say that yes the differences you have noted from ’standard’ Scrum have definitely also been applied (by myself) to more than a dozen teams on different types of projects, and they worked well. By the way my teams aren’t feeling that updating task hours is a sneaky type of micro-managing. This practice is their choice to use. I can see how some could feel that way in other circumstances though.

I’d also like to say that increasingly I have found that this approach of teaching the fundamentals and then letting the teams and their managers experiment with practices is the way to go. I do start them off with a set of practices because when they are brand new to agile they need some structure. But I make it clear that when they’ve gotten through a few successful iterations, they can and should start experimenting and use the retrospectives to evaluate the results.

There has been some mention of the programming (or engineering) practices and how they fit. I advocate for teams to get going with those but I cannot push them to do it. So I help them to understand that some of the issues they are seeing are a result of not doing enough of that. I’ve been successful getting the engineering practices going in this way.

I agree with Joe Little’s comment that telling folks they cannot start agile until they first perfect a list of technical practices can be a real non-starter. On two counts:
1. – They don’t want to be told how to do their work, even by a very knowledgeable coach
2. – You always have to “meet them where they are”, i.e. whatever their current state is, you need to be able to help them find a way to start doing some kind of incremental steps that make things better today than yesterday. That’s the creative spark that a good coach provides. It’s totally situational and cannot be packaged up as a book or training course.

I share the concern that Scrum lets teams get going without those technical practices, and the mere fact that they survive the first iteration seems to confirm for them that they are already doing all they need to. I’ve found that it works to be patient and keep giving the message that:
1. – Yes the technical practices do require an investment but are well worth it
2. – When you do enough agile testing, you can get rid of those slow approval & signoff procedures
3. – Without strong developer-written tests, the team will eventually become unable to deliver because of technical debt, dooming the team and project
4. – The biggest component of an agile team’s speed comes from the strong engineering practices

Thanks for writing up this clear description of your thoughts on how Scrum needs to evolve.

– njv,
agile coach specialising in embedded systems

I am new to Agile-Scrum and I work in an digital advertising agency. The typical projects we run are all internet based, from banners campaigns and games to websites bulding (flash or HTML, sometimes with backend systems).
I have some issues that I would like to understand how to fit within the Agile scrum methodology:

1 – In some cases we have a 3-4 week turnaround in projects.
How do you calculate the lenght of a sprint?

2 – the resourcing for the projects usually means that the people working in a project will have more than one project to work on.
If we use scrum does it mean that each project memeber working in 3-4 different project will spend 2h each day(15-30 min for each project ) in morning meeting?

I wonder how would you apply a scrum methodology to this kind of projects.

Let me know if there is any book or website you can suggest for internet based projects.

Cheers

Giuseppe