MVP Agile

As scrum masters, we often adopt existing teams. We join as the newest member of the team. We are expected to enhance the process and performance. It's challenging sometimes! It takes time to gain the trust of the team! Changes also create tension because it requires people to change their behavior, which is the not a pleasant battle to fight. I've developed a four-step recipe in the past years, based on my experience as engineer manager and scrum master. I would like to share this recipe with you. Here goes:

Adopt the team.
Observe and assess the team.
Focus on the key area(s) for improvement.
Create a feedback loop for continuous improvement.

Adopt the team

I try not to change anything on day one!! I sit in and observe the ceremonies for a whole sprint. For me, there is no silver bullet when it comes to process; there is only the home-grown, organic process that works for the team.

First and foremost, I try to understand the definition of done (DoD). DoD says a lot about the team. It shows me:

Team structure

Are there different sub-team (components)? Are there difference stages/phases in a story? Do they(sub-teams) share the same DoD? Who and when can a story be closed? Are there dedicated QAs? Is there a Design team involved? Are they embedded in the team? Does a story need to be reviewed by the product owner?

Software development life cycle

Does a story need to be reviewed? Who are the reviewers? Does a story need to be released in a production environment? What is the QA engagement in the process? Are there any obvious/hidden bottlenecks?

Once I understand the DoD, I would adopt the current process. I run the daily scrum, planning, grooming, just the way the team has been doing, although I might disagree with some of the process. For me, changes bring uncertainty and require behavior modifications. Without gaining the team's trust, this might cause more damage than good.

Observe and assess the team

I would then spend some time assessing the team and identifying the area(s) I might be able to help. My assessment consists of three parts:

Team self-assessment

I conduct an Agile self-assessment with the team. The assessment would provide insight into how the team members view themselves and which area the team wants to improve the most. The assessment also shines a very bright light on how the team feels about the current process.

Retrospectives

Retrospectives tell a good story of where teams are at in their Agile journey. I try to read notes on previous retrospectives, if available. The main things I try to look out for are: repeating items, frustrations, and process proposals. I also pay close attention to the hidden signs/clues in retrospectives. For example, was the team talking about DoD but actually complaining about acceptance criteria?

My evaluation

The last part of the assessment is formulated from my own observations. I pay extra attention to to following items:

Roles. Does the product owner, team, and scrum master understand/play their role? If there designers on the team, how do they interact with team? Team dynamics - Does the team work well together, or do I need to plan some team building events?
Efficiency. How much time has the team spent on scrum ceremonies? Were they effective?
Velocity. Is the velocity consistent? Velocity speaks volumes more than just productivity. I try to understand why the velocity become the way it is.

Combining the information from these three input streams provides me a very clear idea for the team's key areas for improvement.

Focus on the key area(s) for improvement

When it comes to improvement, I first focus on this key area that doesn't introduce any new process:

Efficient meetings

No one likes inefficient meetings! Reducing meeting time and frequency does not require any process change. It immediately increases team capacity, which in turn increases team productivity and efficiency. For example: Can you get something done faster which will eliminate the need for future unnecessary meetings? If you can finish the sprint review and retrospective in an hour, then you can cut down a 2-hour retrospective meeting! This gives the team an hour of their time back to use for something more constructive. (Note: This has to be carefully wielded, since rushing through a retrospective or review might defeat the purpose of this meeting, and not yield the benefit of having these meetings in the first place. Remember, trim wisely!)

Then I go down the list of what the team has identified as an area of improvement, or a pain-point that they want to tackle first. How can I help them become better, faster, stronger?

Create a Feedback Loop

What worked for the team today might not work for the same team tomorrow! The last but the most important step in my recipe is to create a feedback loop for continuous improvement.

This is essentially the same mechanism that I mentioned in the second step (Observe and assess the team), but I establish a regular cadence for these observations/assessments.

How do I create a constant feedback loop?

Retrospectives are my main feedback source. This is a chance for the team to come back on a regular basis and answer the question "How are we doing?" or "What can we learn from our recent experiences?" or "We made changes... How is that working out for us?" Nothing beats continuous improvement!

I schedule Agile assessments every four to six sprints. I would invite a third person to conduct the assessment without me in the room. It encourages the team to provide non-biased feedback about the process.

Thats my recipe folks! Take this information and let it simmer for a sprint or two. Add your own flavor to it and make it yours. Everyone has his/her own secret recipe. I would like to learn from you. Leave your comments, opinions, disagreements, +1s, experiences in the section below and lets get this discussion started!

Thanks,

Brian