top of page
Search
  • Sarah Stewart

The Maturing Team: Going Big by Making Things Small

Previously I’ve talked about basics: User Stories, relative sizing, and how new teams determine their velocity. Now I’m going to talk a little about how teams mature beyond the basics.


First off, few Agile teams get to mature much past reaching a steady velocity. The longer a team stays together the more opportunities it has to improve, but few teams last long enough for that. Changing even one person on a team disrupts it. Maybe not to the point of starting over, but it can take a team several sprints to reach a new norm.


But even short-term teams can still make large improvements if they focus on the right areas. Here are some of my favorites.


Seize Your Sprint Retrospectives


Many teams (especially new ones) drop sprint retrospectives. I’ve worked with a lot of teams who didn’t find them valuable. Why spend a retrospective arguing over what went well or poorly if they never get to implement their improvement ideas? I’m sure I’d feel the same. But the answer isn’t to skip your retros, it’s to fix your improvement process!


Many things can disrupt your improvements. But the most common problem is picking too many. I recommend only one (or at most two, if they’re easy) improvements to implement each sprint. Teams usually don’t have time for more than that.


I made this mistake as a brand-new Scrum Master. We had seven improvement ideas in an early retrospective that all looked really easy to me. I decided, “I’m going to implement them all next sprint!” “Just pick one,” my coach warned me, but I grabbed them all. And over the next two weeks I made some of progress on four of them but not enough to fully implement a single one. The next sprint I only chose two, and managed to finish both by the end of that sprint. Barely.


From then on, I stuck to 1-2 items. If I got them done quickly, I grabbed another off the list. And many issues got resolved externally or we fixed them through other changes we made.


And some items we just worked around. Some problems (okay, a lot of problems) are outside the team’s control. Try not to spend a lot of effort on issues like this. Escalate or find a workaround. For improvements, choose things that the team owns. Getting even small improvements done is good for morale.


Do a Small Experiment Every Sprint


This is separate from your improvements, although they can overlap. Each sprint, the team chooses one thing to try that’s different: an experiment. A process change, coding change, style change, whatever the team thinks of. Try your experiment for one sprint, or even part of a sprint. If it works, add it to your team’s regular practices. If it doesn’t work, stop doing it. But choose something new every sprint. These little experiments are great way to test improvements and new processes without fully committing to them.


As an Agile Coach / Scrum Master, I make sure that my team chooses an experiment every sprint, either during the retrospective, or in the first day or so of the sprint.


Write Smaller User Stories

I’ve seen few new teams finish all their User Stories by the end of each sprint, particularly getting each story “done-done” (i.e. meeting the team’s Definition of Done: full implementation, testing, deployment, etc.).


I’ve found the best solution is to write the smallest User Stories you can that still deliver some demonstrable value. The smaller a story is, the easier it is to understand, size, and implement. Very small stories also usually have fewer dependencies, which makes them easier to test and less likely to get blocked.


Teams that write really tight stories can reach a level where instead of counting Story Points they count completed stories. I think that’s a sign of a really mature team.


For most engineers today, team churn is a regular event. But with these techniques (pursuing achievable improvements, doing experiments, and shrinking user stories), you can accelerate your team’s growth even in a shifting environment. And these skills and attitudes are portable, too! Whether you’re a Scrum Master, Product Owner, or engineer, as you move from team to team, you can bring that faster maturity with you, boosting each team you’re on.


8 views0 comments
bottom of page