It’s the start of a new year, and everyone is thinking about how to improve themselves and their work. I’m not here to offer a list of resolutions to take on, or tips to make the most out of 2017. My message for the coming year is simply this: keep working on your team.
It may barely seem worthy of writing about. But, it is. Just as iterating, measuring, and improving are the heart of creating great software, so it is with teams and their processes. A team that doesn’t keep trying new things stagnates, and its processes become “legacy”.
Conversely, a team willing to try new things, ditch old habits, and pick up new ones will be more effective and ultimately, happier.
Most teams at Atlassian are agile. The great thing about agile methods is that they emphasise personal interaction over rigid processes. Work is about the people getting it done, not the methodologies that are applied to it. But, people can get attached to old ways of doing things. Here’s how you can shake things up, and why it’s important to keep improving.
Your team will be more efficient
If you’ve ever done a retrospective, then you know this to be true: you learn what you should keep doing, stop doing, and start doing, making your whole team run better.
But sometimes, retrospectives aren’t enough, and your team needs a larger refresh. Making incremental adjustments to areas that are not working perfectly won’t get you there. It’s like fixing bugs when what you need is a different feature.
Don’t be afraid to experiment with new ways of doing things as a team in the pursuit of efficiency. Pair programme for the whole sprint? Ditch Jira and go to paper cards for a while? Have your stand-up in the park? These things in and of themselves may or may not make you more efficient, but if you keep iterating, you will discover what works. At the very least you can cross out ceremonies that your team isn’t getting value from. And that’s progress, too.
You help your customers
At the end of the day, your team is producing or supporting products that benefit your customers. Iterating on efficient ways to run your teams and sharing what you’ve learned is a legitimate investment in your product.
Better team processes will directly or indirectly mean better products. We all have an influence on our products, even if we don’t work in them directly. My team has discovered a lot of new use cases and customer experiences by dogfooding our products and testing them out in ways they haven’t been used before.
Your team will be happier
“This is the way we’ve always done it” is the forerunner to stagnation. Just because it worked once, or worked in other teams doesn’t mean that it will keep working in your current team, with the current set of individuals. Of course, start with the parts of your team processes that obviously need improvement, but keep questioning all parts on a continual basis.
By iterating and changing, the team is investing in itself. The feedback I’ve had over the years is consistent: trying things and striving to improve makes people feel good and brings the team closer together. The funny thing is that even when teams are trying things that are not working well, they still feel better for having tried. The key is to make it a truly team-based effort, rather than relying on one individual (lead or otherwise) to come up with all the ideas. Agree as a team to give an idea a go (even if not everyone is convinced that it will work) then assess its effectiveness together.
Where to go from here?
So you might be thinking, “Great, this post is high on generalities, but low on actual ideas. I can’t just invent new ways of doing things!” But ideas are the easy part, they are all around; with your teammates, your colleagues in other teams. Think of how they are doing things differently, or have done so in the past, and try a version of that. Here are some ideas from my team and others at Atlassian:
Agile Slam: We have a forum called Agile Slam, a time when team leads share their good and bad process experiences within a wide group. Leads take turns picking a ceremony or aspect of the team and discuss what they’ve tried, what has worked and hasn’t, and then open it up for feedback from others. We try to walk away with at least one thing some people would like to try differently, and we use the first part of the next session to share how that went. You may already have a forum to discuss things like this, or you may like to start one. Even if you are copying someone else’s idea, your implementation will be unique to your team. And don’t discard ideas because they didn’t work for other teams – spend the time understanding what the strengths were, and see if it applies to you. There’s no one size fits all; otherwise we would all be building software in the same way.
Stand-ups: A great way to start iterating on your team is with your team ceremonies, like stand-ups. A stand-up helps teams, both technical and non-technical, give focus to the day and help each other where need be. How you do them is ripe for constant improvement. You can tell a stand-up has become stale when updates are mechanical and people waffle or zone out. There are a variety of formats teams use here to shake things up. Some teams “walk the board” by traversing the scrum board left to right, some teams go with the yesterday/today/blockers format, others have tried “one commitment for today” only. The most important thing is that teams change and evolve these ceremonies over time based on the circumstances and feedback from the team.
Physical wallboards: Even though there are many tools for virtual collaboration and productivity, there is still a place for actual physical wallboards. One of our team leads is especially creative in representing information on progress and important markers in a project through the use of drawings, themed boards, and design elements. Visual project representations have more character and feel more personal and engaging. His team has really responded to it. Since he has shared this idea with other team leads in our Agile Slam forum, a variety of creative physical wallboards have blossomed to complement Jira project tracking. It’s a great example of how simply sharing ideas and encouraging iterating can produce new team habits.
Pair-programming: One of our teams introduced mandatory pair programming for a while, but changed its format every so often. Pairing was only for half the day for a while, sometimes the pairs stayed together for the whole sprint, other times pairs changed after each task. Pairing is a great way to share knowledge and can be a great productivity boost, but also comes with logistic and social pitfalls (spending long periods in close proximity to a colleague is not everyone’s cup of tea). By one team iterating on elements of this and sharing findings with other teams, more teams are now adopting pairing in some form.
Sparring: Instead of walking over to a teammate’s desk to get their feedback on an idea or a piece of work you’ve got in progress, set up a sparring session with your team, where you can bring your ideas to the ring. Sparring originates from the design world, but teams at Atlassian are starting to use this technique to get peer feedback on technical design/approaches to larger pieces of work. It also works well for teams that do a lot of document-based work, like HR. For instance, before publishing a new company policy or job posting, spar on the copy with your team to make sure it’s clear and easy to understand.
Everyone on the team should be thinking about continuous improvement. But if you are a team leader it is extra important that you provide the impetus and encouragement for your team to iterate and change. And if you’re really struggling with how to improve your team, get some ideas based on your team’s pain points, or learn how to run a health monitor to assess where you can improve.
Get more ideas in the Atlassian playbook