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?

Velocity Dip or Double Dip – What to do?

Joe is a new to agile software development.  A year ago, he attended training programs on agile methods and learned more through his sporadic reading on topics related to Extreme Programming, Scrum, etc. He did not get an opportunity to practice though - he continued to play the role of project manager in other non-agile projects.

As you know, 70% of learning happens through practice, hands-on experience or problem solving.  About two months ago he got that opportunity he was looking forward to - his first agile project started.  A month before the start of this project he completed a certification program which provided him additional awareness and may be some confidence on how to lead agile projects and work with agile teams.

His project follows practices from Scrum, XP and other methodologies. He is a rookie Scrum Master.  This is the first time he and his team members are putting several agile practices into practice. They are experimenting and exploring. They are trying to make sense out of their experience iteration after iteration.

Last week weeks ago, Joe met me.   He wanted to discuss about the teething issues in his project. He needed my suggestions or thoughts on such issues.

We met on time and spent the first five minutes in catching up with some general topics.  Then he started on one of the issues in his project.

“Velocity is pretty much the same as throughput.  Is that correct?”

“Yes. You can say that. In simple terms it is the units of work delivered per iteration. What has been your team’s velocity? How is it trending?”

“Not good.  We are not seeing any increasing trend. It is pretty much the way the global economy is. Initially it was a single dip. Now we see a double dip!”

He smiled and I did too as I continued with my questions.

“So, tell me about your team. How is your team moving forward? Are they …”

“Well, the product owner is anxious.  Well, he is upset.  Yesterday we had our iteration planning session.”

“Concerned about the double dip?”

“Yes. Every dip is a matter of concern! How do we handle this situation? What do you suggest?”

“How was the team retrospective? What has the team reflected on?  Do you believe you can sustain?”

“I think so.  Our product owner knows the root cause.  User stories are not stable.  We have to do a lot of back and forth in refining most of them. That is tough.  This impacts our productive hours during the iteration. In spite of this he expects us to maintain an upward trend in velocity. He asks pointed questions on our velocity trend. Tell me. Is it this double-dip bad? What should we do?”

This is when I took a pause and then assured him firmly that it is ok to have a double-dip.  Why not?   A dip in the chart is okey as long as you collaborate enough, be transparent, identify root causes, implement corrective actions, resolve issues and move forward in the right direction.   ‘Fail-fast-fail-early’ is something we need to encourage and feel happy about.

Next, I asked him, “What are the success parameters in your project? How do you measure success? Is Velocity the only parameter or do you collectively look at other metrics?”

He understood where I was getting into. With a nod, he responded.

“I understand what you are talking about. I think we have not established a common understanding on our success parameters. We do not have a sound governance mechanism in place. I have a fair understanding on what to do now. I am going to take this up and discuss with our product owner.”

With a smile, I ascertained his approach. I think he wants to solve problems,  improve and reach the destination.

Before we parted, I shared with him my thoughts on the signs of collaborative spirit and my experience on how to build rapport with a remote product owner.

Joe is confident. He is going to meet me again.  I will come back to you on that meeting soon.  He met me after couple of weeks to discuss about an interesting thing  -  read the next post to know what happened in our meeting. 

Related Posts:

Metrics and Measures: What is the difference?

Software Project Metrics and Agility 

A Dip in the Chart – An Agile Story 

How Can We Make Software Engineering Curriculum Interesting?

'How Can We Make Software Engineering Curriculum Interesting?' This was the topic of our panel discussion in the workshop on software engineering education and training (WSEET) -  a pre-ICSE 2014 event. The objective of this discussion was to explore different ways to  make ‘Software Engineering’ course interesting.

Think about the class room sessions on Requirement Analysis,  Estimation Techniques, Project Planning, Methodologies, and so on!   Are these sessions too theoretical?  Why aren't these sessions interesting? What do we need to improve and make it interesting?

Here are some ideas and suggestions that emerged out of our discussion.

1. Class room interactions on software engineering supplemented with hands-on projects to small groups of students is a way to combine theory with practice.
2. Learning from open source projects is an opportunity that never existed a decade ago for students.  Downloading open source code, studying the code, adding new features or enhancements will make it an interesting learning experience.
3. Making class room sessions interactive instead of presentation driven monotonous lectures is a must.
4. In order to get an understanding of what happens in the industry it is good to consider invited lectures (by industry experts), and  learning from recorded video sessions of international experts.
5. Case study based learning (similar to the Harvard Business School model) is very appropriate in software engineering courses. Students can learn from both successful and failed project case studies.

There were several other related suggestions.  According to the 70-20-10 formula,  70% of what we learn comes through practice and it makes lot of sense to supplement class room sessions with projects, hands-on practice and several other techniques (such as case study based learning or invited lectures).

These days it is very easy to ensure that software engineering curriculum of a university is second to none in the world. We have access to the curriculum of top universities. We know the top reference books and students have access to lots of high-quality material on the web. Eventually, making the curriculum ‘interesting’ is a delivery issue.  There are 3 groups of key players or stakeholders who have to play their role to make it interesting.  Here are these groups.

Administrators or senior management of educational institutions:  Their role is to provide the infrastructure with adequate computing facilities and support partnerships with industry and provision incubation centers.  In order to do this it is necessary to revisit the mission, vision and goals of the institute from time to time.

Faculty members:  Inspiring teachers pull students.  If we want our course to be interesting, we need to carry an interesting personality and attitude.  We cannot afford to settle down with the same old reference books and examples.  We must be lifelong learners so that we do not stagnate. Because, when we stagnate we become dull and uninteresting.

Students:  Students have to be curious, interactive and inquisitive.  Students must be willing to read, interact, and collaborate.  They must be ready to solve challenging problems and stay away from the temptation of doing just enough to score grades.

With these measures, I am sure learning software engineering can be very interesting. 

What do you think?  Do you have any ideas or suggestions?