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.

Facing reality

I’ve been asking myself what’s the biggest and hardest challenge in embracing agile development. There are a lot of factors in play and it is not easy to clearly see what gives us the biggest pain. There have been also different phases in our way of adopting scrum, each with its challenges.

The human factor is surely one of the most interesting challenge because there is no way to foresee how people will react to the introduction of a development process that asks them to self-organize and make the team’s goals their own goals.

The practices their-self are challenging as well. You get lost very easily when you do a lot of changes at the same time. This is particularly true when you are experimenting yourself all those changes, because maybe you do not have the luxury of a budget for someone that can help you. In any way, I strongly believe there are things you have to learn in the hard way, no help other than your experience can show you the way.

Legacy code is another big obstacle in the way of being more agile. You would like to do more, be able to confidently change things; instead, you often fall in the chicken-and-egg problem that becoming able to do so means to spend time to refactor a big chunk of code. Since it is expensive, you do not start, piling technical debts over technical debts.

But the most challenging experience of embracing scrum is facing the reality. The essence of scrum is very simple: you have a check point of all your work, assumptions, plans, in a very short time-frame. This is terrific, because you know almost immediately how you are doing. But the reality can be something you and your stakeholders are not ready or willing to know.
When you do a long term plan, you keep the hope your plan is good until very close to the end. Since the deadline is far away, you keep the feeling that somehow you can catch up. There is usually not any real and concrete reason for that to happen, but you still believe it. The scope won’t be significantly reduced until the end, the resources will be the same for duration of the project, customers will keep bugging you with bugs and requests, you will keep read tons of emails per day. But still, you believe you can make it. There is something in the back of your brain that tells you “we cannot make it, we cannot make it…”. But you don’t hear it, and you keep believing something magic will happen.

Do not get me wrong, this is done all in good faith. The best product owners are the ones that see possible what everyone else considers impossible. This makes them more reluctant to consider that a plan is not achievable. They want the teams to have a “yes, we can!” attitude and they do not want to hear “sorry, this plan is not doable”. On the other side, the teams want to make their product owner happy, therefore tend to say “let’s try and see”.

I observed a very interesting phenomenon when we switched to two week iterations. Most teams over-committed so that after one week most of the stories were still not done. Asking the teams if the commitment were still confirmed, they were still confident they could complete all the stories. I was becoming every day most worried and the teams kept being confident they could do all the USs until the very last day. There was not any real reason to this to happen… but still the teams were confident. Do not get me wrong, I appreciated a lot the teams attitude of trying to keep the commitments to what they promised to deliver, but the result was that their goals have been constantly not met and the stakeholders have been seeing the teams constantly fail on their commitments. This resulted in unpredictable velocity and in the teams and stakeholders constantly frustrated by the missed goals.

But scrum asks you to do something different: to look at your self, at your teams, at your stakeholders and do not lie. Scrums allows you to achieve your goals because you first of all have to face the reality. The reality of your team, of your resources, of your possibilities, of your knowledge. Only if you accept this challenge and you accept you have to make a plan that works given your real conditions you will be able to see your progress iteration after iteration. Only in this way you can see your weaknesses and work around them in the meantime you work to fix them.
However, sometimes this is not easy to accept. You may be frustrated and wish you have a different team, different deadlines and a different budget. You will be tempted to point your finger to scrum just because it opens your eyes.
But if you resist to that temptation and start to accept reality, you will have the great opportunity to fix what’s wrong and therefore to constantly improve. End eventually, you will be surprised to meet unhoped results.

I believe there are two factors that allow a development team to face reality:

1. Trust each other. The development team shall always keep in mind that what the PO is asking is what will make the product a successful product. POs shall always keep in mind that the development team wants to build a successful product and put all its best efforts to make it happen.

2. The development team needs to gain the confidence of saying, without illusions, what’s achievable. The team needs to learn to say ‘NO’. Plus, the development team must learn to provide alternatives. Firm ‘NO’ must be exceptional. Most of the times a ‘NO’ should be accompanied but alternative options.

What I often tell my team is that we can accept we do mistakes because nobody is perfect. What we cannot afford and to not improve. Facing reality is a precondition to improve a team.