Thursday, October 24, 2013

Readiness at the Starting Point Matters!

Joe started it right. He was trained and certified. He had played the role of project manager in several projects. He was ready at the starting point. And he started on his first agile project. Was that enough? May be not. Because this was his first agile project.  He was a rookie Scrum Master. But, that is how many of us start and gain some experience. Don’t we?

Couple of weeks ago, Joe’s team velocity had a dip or a double dip. Joe was curious to seek some help, ask questions and get some suggestions.  Our first meeting helped him do some of these. After our first meeting, I was involved in an external event followed by a customer visit. Joe stayed in touch with me over emails and came down to meet me last Friday. He was relaxed and confident.

The child in me started the conversation with a smile.  “Hi Joe! You are early today and you are fast. Looks like the velocity has increased!”

With a smile he responded.   

“Well, I am early. I want to fail early and fail fast!  I have something very interesting to tell you. I had a one-on-one conversation with my Product Owner. He understands.”

“Understands? What does your PO understand?”

“He understands that readiness at the starting point matters! Let me explain.”

I liked the way he put it across to me. He explained in detail about his conversation with his Product Owner. I stayed focused and listened as he narrated the whole thing.

Joe prepared for this conversation– he did enough home work. He grasped the current state of fuzziness in user stories. According to him more than 60% of user stories underwent major changes. The figures and facts presented by Joe helped his Product Owner understand the gravity of the situation. That is when they agreed that the definition of ready (DoR) is as important as the definition of done (DoD). In short, ‘Readiness at the starting point matters!

Another fantastic thing he did was to help the Product Owner understand that ‘Velocity’ is not the one and only metric to care about or worry about.

As he explained all these to me I sensed a great deal of common understanding and rapport emerging between the budding Scrum Master and Product Owner. And I was just nodding with a smile. He continued.

“Now the good news is that we are going to start another project soon.”

“Yes. That is a good news! Is there a follow-up news?”

“Well. Yes there is. But that is not a good news! My Product Owner says that the new project involves development of a complex application and the requirements are evolving. He is not sure if we can ensure readiness at the starting point. He is firm. He is not going to provide us groomed or ready user stories.”

“Does it mean that the definition of ready and definition of done will evolve day by day during iterations?”

“Yes. I think so. That is the bad news! He wants us to deliver.”

“When is this new project starting?”

“I forgot to tell you that. It is going to take a month or two. I want to discuss this with you in our next meeting.”

“Sure. Why not?”

With a sign of mutual agreement on what to discuss next time, we ended our 30-minute meeting.  Joe, with a confident look, waved at me and started walking towards his car. I am sure he will have some interesting things to discuss in our next meeting.

I am sure Joe will be in a better shape with the experience he has been getting in his first agile project. In future, he will be able to scale up and handle larger teams too.

Readiness at the starting point matters. However, can we afford to keep waiting at the starting point to get ourselves ready? Or should we move forward as we become ready? The answers to these questions depend on one thing – the definition of ready. Once we agree on this definition, we must work together without conflicting each other on whether something is ready to start or not! Obviously the definition of ready is going to be context-specific.

What do you think?


Dave Updike said...

A DoR normally refers to the state of a User Story to either 1) enter Sprint Planning in the case of Scrum or 2) active development in the case of a Kanban-hybrid. However, your point is well taken. In the past we have developed a "Release Planning Exit Checklist" but we were careful to ensure that it was flexible because every project cannot be treated exactly the same.

The scenario you present is not uncommon and is highly dependent on the maturity of the organization involved. A project that has been appropriately considered and thought about with a DoR to start Iteration 1 is great if you can get there.

However, the second scenario you present could be fraught with risks for the team. Basically when a company says "I don't know what I want but I know I want it by X date" be VERY careful. There are 2 ways to approach this 1) have a Release DoR (to begin Iteration
1) and stick to it. I believe this is the point of your last paragraph. Not a problem here as long as the organization is on board understanding that the number of Iterations will be continue to shrink while you wait to gather the information and people needed to meet the Release DoR.
2) Begin without having all the answers to a Release DoR. Plenty of Agile projects begin this way and a large segment of the Agile Community prefer this method. Will there be more re-work than Method 1 above, yep. But this method has it's advantages as well.

The key here is to A) ensure you have a "learning organization" and B) come up with an optional Minimum Release DoR that ensure just enough has been thought about to guide the first Iterations and allow product to evolve. This will come with some growing pains but this also allows your team to begin writing actual code and learn from the growing software versus waiting for the product to be "defined" without any working software. It's a line all Agile Organization have to learn to navigate.

Raja Bavani said...

Thanks David! Great insights! I agree - ensuring that we have a 'learning organization' and adhereing to DoR are necessary. Else, POs may stay in their comfort zone of providing one liners (user stories) for Sprint Planning and rely on project teams to groom user stories when Sprint execution is in progress. That hurts! When this happens, the team goes through 'a frog in warming water' syndrome and burns out when the water boils!