Pragmatic Agile Weblog

Agile software development in real life

Scrum READY state ?

Recently, in a post on the extreemprogramming-it list I read a post quoting the following two links

  1. http://blog.xebia.com/2009/06/19/the-definition-of-ready/
  2. http://blog.xebia.com/2009/07/04/flow-to-ready-iterate-to-done/

They introduce an interesting concept in scrum development which has to do with the interaction between the product owner and the development team: the READY status.

In the first article, READY is defined as follows:

READY is defined by the Definition of READY. It is similar to the Definition of DONE, but with the following differences. Whereas with the Definition of DONE the “supplier” is the Team and the “client” is the Product Owner, it’s the other way around with the Definition of READY: the Team is the “client” and the Product Owner is the “supplier”. Even though I will detail the Definition of READY later, in the end it boils down to one statement: READY is when the team says: “Ah, we get it”.

I thought about it a little bit and I have to say it does not convince me. The first thing that makes me hesitant to buy into it is that it introduces a sort of phase.

In explaining the use of this state, the author says:

In a self-organizing team setting a clear destination it very important: self-organization does not exist if you have nothing to organize TO. The READY state prevents team thrashing by ensuring that the preconditions for a good Sprint execution have been met.

And of course this is a very good proposition. But is a READY state really necessary in order to achieve that goal? What if for the most different reasons it is difficult to reach that kind of READY state. And why we exclude in principle that instead a team should self-organize to even overcome a lack of READYness?
One of the agile practices I like is that you want to spend your precious time on things that have enough value. This also means that you can accept a level of un-READYness under certain circumstances. For example, you do not necessarily need all user stories to be completely ready when you do release or iteration planning. The goal is first to identify what can fit a release or an iteration and only when a user story has enough value make sure that all aspects are covered, that the US is of the right size to fit the iteration, that the implementation strategy is define and maybe the tasks identified.

I also do not quite like the fact that the READY status remarks slight separation between the product owner and the team, while instead I like more to think about the PO is part of the team. The team works together also to make sure the user stories are ready and it is not a precondition to start a sprint. The last thing you probably want if you are doing scrum is that the teams are waiting on a precondition to be triggered in order to produce value, exactly like if a developer should wait to start development until an architect has done the design.

Advertisements

July 15, 2009 - Posted by | Agile, SCRUM

No comments yet.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: