I have been working with many companies that would stress too much on the current team processes to support their product development in an organized way. I have often heard that Scrum Masters are responsible for the process management inside the team.
As a result, many might concentrate on the wrong initiatives and metrics, like increasing the team's velocity to have better performance or pushing the team to finish all planned PBIs no matter what.
This situation might lead to a feature factory where people tend to finish "their tasks" on time, not to be "punished" afterward. Their perception of their work is to stick to the process, not touch the running sprint and boycott the upcoming changes.
The management on their side might do everything to decrease the risks of "not completed" work, evaluating them by the number of features they deliver after the sprint.
In this situation, I can't help myself asking:
What do you think the users get from it?
Do your teams actually follow through with the customer responses?
Do they have the information on how the market accepted the delivered work?
Do you have a clear way to learn and use that learning in further work?
The development continues after the written code!
The development as a cycle never ends, and teams should still be responsible for the delivered value.
So what could you do to improve that situation?
#1.Start with the team mission statement.
Answering these 3 powerful questions might change how your teams perceive their work:
What do we do?
How do we do it?
Why do we do it?
This statement will clearly show why your team exists.
#2. Make sure the team knows exactly who the customer they are serving and what value they produce.
They might have different users with different expectations. Providing a unified solution will kill your user base, and they will feel you are working in batch mode.
#3. The team members should understand the idea behind the "Increment."
This is a sum of all Product Backlog Items completed during a Sprint and the value of the increments of all previous Sprints.
This means they should treat their sprint backlog as something other than a final destination but as a point of validation of their experiment.
So they should always look into the live product to evaluate its current state. Moreover, one of the best ways to do so is to review the current Increment during the sprint review and not only the completed work during the sprint.
#4. Instead of focusing on vanity metrics, use customer and quality-centric ones.
Those could be things like customer satisfaction, product/cost ratio, analytics on the feature engagement, usage index, innovation rate, total defects, release frequency, etc.
Make clear to the management that we must complete the vital part of experimentation and validation to deliver the value they long for. No deadlines can increase the innovation or delivery quality which might satisfy the customers. So if they stress the process, they will get a process.
#5. Learning and agreements go hand-in hand.
No one questions the importance of learning. However, if it is learning without a clear result and mutual agreement to share and realize those, it will stay on an individual level.
Team health highly depends on how people agree to work together and how they deal with the learning they get.
So spend time now to craft robust agreements, norms, and values to save you from multiple attempts to fix behavior later on.
And remember: satisfying customers early does not mean being fast no matter what.
Everyone in the organization should understand that Agile is not about being fast and crappy but about frequently delivering to validate and to increase the quality experience for the users without delays.
So shipping a feature is just a step in the learning journey.
I hope you found it helpful :)
===
Whenever you're ready, there are 3 other ways I can help you:
1. Follow me on Linkedin to get daily tips on #agile, #team coaching, #scrum master growth, #agile leadership, #agilecoaching #culture
2. Work with me 1:1 to grow in your Agile leader role or help your team and company grow.
3. Join the Agile Team Coaching Program: A targeted coaching- facilitation system to help Scrum Masters and Agile Leaders to identify team hidden obstacles and turn those into a growth plan in 30-60 days.