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?