Scrum Team Maturity

Scrum processes are bound to fail if teams are not disciplined about the process or not technically mature to actually deliver the work committed for a Sprint.

This is why Scrum probably works best with teams comprising at least with people who are at a similar maturity level.

Scrum is not a project management process, but a product development framework, therefore it might be better to start measuring the effectiveness of the outcome of each sprint:

How much end-user value is being added to the product in every sprint?

Then let the team figure out what they would need to measure themselves to improve the value.

What actually do I mean by maturity here?

Let me quickly explain a few KPI that will show you how Scrum teams are progressing:

🏎 Velocity

It is the trend that seems too high for a while once the team gets the ball rolling and have no significant obstacles stopping them from accelerating.

For software developers, velocity is represented through the number of stories the team delivers each sprint.

In this way, storypoints would be a great tool to help teams to estimate a problem within sharing the understanding of the story by each team member. So that the team can classify the story and label by "complex," "bug," "chore," "need research (spike)," "easy."

And this kind of prioritization allows teams not only to evaluate the time estimation precisely with an accurate story points number for each user story but also to make them happier and more focused on the end value during the sprint.

👩‍💻👨‍💻 The Relationship in the Team

Here, I mean a relationship among Scrum Master, Lead Engineer, Development Team, and Product Owner.

If the separation of concern is well understood: the ticket with the task is described and written clearly. Each team-player knows what the other is supposed to do, and brings to the table the end-value to the user at the end of the sprint. Then you got a team that is relatively mature and will execute fairly successfully.

Whether it is a small start-up or a big corporation, team building can help grow the relationship on the team.

According to the University of California: "Team building is an ongoing process that helps a work group evolve into a cohesive unit. The team members not only share expectations for accomplishing group tasks but trust and support one another and respect one another's individual differences."

Because of the dramatic global issue, we all have to work remotely, which makes team-building events offline impossible.

And still, it's not the reason for not having a virtual one! Here are 5 virtual team-building activities to grow a strong remote team.

🖼 Retrospective Matter

Here is how the team uses retrospectives and how effective they utilize it through learning and incremental improvements.

The retrospective is one of the most essential scrum processes if the team cares about growth and continuous work improvement.

Throughout the retrospective meeting, teams figure out what went well, what went wrong last spring, and what could be done better in the future.

The main goal of these weekly/biweekly meetings is to recognize what the team is doing poorly, and stop doing that or adjust, recognize what the team is doing well, and do more of it.

Additionally, if some part of the process is not working well in the team context, choose a different practice, method, etc. that delivers the same value to the team, but fits much better the team's context.

The main result of the retrospective is the list of action items that are assigned to the whole group, subgroup, or a single person.

However, there are many useful tools on the market, here a few techniques that can be used for retrospective meetings:

Classic “Happy / Meh / Sad” agile retrospective
Stop / Keep / Start
KALM — Keep, Add, More, Less
Sailboat
Speed Car
Dot Voting
Token of Appreciation

📊 Measurable Metrics

Does the team have effective and impactful metrics and aware of why they are there trying to improve the measurement while contributing to it?

The ideal case would be if a scrum team will look at customer product usage and customer behavior. In essence, user flows, for example, through in-app analytics, feedback messages, customer requests via chatbots, or review on the product.

Just answering the question: Is your customer happy?

Because the primary criterion of becoming agile by using scrum is this.

On the other hand, there are common metrics for performance improvement plans like velocity mentioned before, burn down charts, etc. You can read about famous bad and good Agile metrics here.

🚨 Crises on the Team

In my opinion, it starts with the micromanagement of each other on the team. And it's only started on the team, where there is no trust between members.

You can easily recognize that if you notice by absurdly frequent meetings about the ticket status and numerous talks about removing impediments.

And it's hard for people who are good at what they do. It will be insulting to them to have to spend hours or even days on justifying their work.

So it's crucial to know and acknowledge team crisis existence and be prepared to deal with them as soon as possible. It will make the team highly meshed, mature, and experienced.

💬 Conclusion

Unfortunately, though, lots of times, measurements are focused on the speed and efficiency of a product without measuring the effectiveness.

If we are not building the right thing (not being effective), we will never be able to increase the product development speed.

Otherwise, the product development only is like a hamster in the hamster wheel. Moving fast, without moving forward.

Thank you for reading!

Now, it's your turn. I am curious about how does the scrum process lead to team maturity at your company?

---

Photo by İrfan Simsar on Unsplash

Comments

[Scott Simontis]

I wish I could better articulate how I feel about agile. 90% of the teams I have seen "doing agile development" were pretty far off the mark in my opinion. People forget that sprint commitments need to be flexible, since you can't spend forever researching how complex a task will be. These companies often also tend to be very blame-focused and obsessed with finding a team member to be the sacrificial lamb for the failed sprint. It would be kind of funny looking back except it was so toxic I knew people who were considering harming themselves just so they had an excuse to miss work that day.

Too many agile coaches run around preaching blind adherence to their ruleset, complete with cute flashcards to aid in planning. Whatever process a team chooses, it has to serve the team. We shouldn't be following rules and procedures for the sake of rules and procedures; when something fails we need to fix it or get rid of it.

Lately I have been on a project that is way out of my element. After years of doing web applications, I am suddenly doing network engineering, cross-platform desktop development, and a microservice architecture, all within the same project. The client has no idea what we need to make beyond a vague marketing speech. We're having to figure it out as we go along.

Complex projects are complex and I don't know how far product strategy can take us in these situations. As long as a team can be honest and open and trust each other, I just roll with it.

[Ilona Codes]

Thank you for sharing your experience!

Like so many other things, it's very difficult to take an ideal theory and put it into practice in the real world.

You are right; without trust, there will be no good relationship in the team, only a toxic environment. Transparency is lost. People start playing defense because no one wants to work as a team and collaborate for a goal anymore.

[Nico S___]

Thanks for writing this, is very thoughtful.

In my own experience with Scrum I've found that:

• Sprint commitments should be treated as "forecasts", rather than hard commitments that we will get done no matter what. Scope flexibility is key to Agile.
• There have always been a lot of handover of partially completed work across different team members. We need to work together as a team rather than skill silos.
• Is really hard to fit all the Scrum activities (planning, retrospective, grooming, etc), do the product work (design, development, test), AND complete the actions that came from retrospective, all in the usual two weeks sprint.

I like how you hint into measuring customer value rather than story points as a way to measure the team's velocity. I think thats one key aspect that gets overworked. In worse case scenarios teams are asked to "fix" estimates to fit with deadlines, and similar stories. We should focus on delivery value, not process artefacts.

[Ilona Codes]

Sprint commitments should be treated as "forecasts", rather than hard commitments that we will get done no matter what. Scope flexibility is key to Agile.

Completely agree! Commitment does not mean promise, and any development team cannot make this promise, because no one knows what unforeseen circumstances could unexpectedly happen.

Is really hard to fit all the Scrum activities (planning, retrospective, grooming, etc), do the product work (design, development, test), AND complete the actions that came from retrospective, all in the usual two weeks sprint.

Exactly! The whole point of Agile is "people over processes." So far, many startup companies have hired professional scrum masters; everything must be Agile religiously. And that takes lots of time for developers to follow all Agile processes, including pointless meetings instead of focus on their actual job.