How to build a high performing agile team
People are the most important asset of any company and great software products are created by great teams. So how do you go about building an engaged, high performing product team at your company? The first thing you need to understand is that engaged teams are made up of engaged and motivated individuals. In order to build a high performing team we should first understand what motivates individuals and build from there.
It’s not about money
Good people will leave if they are underpaid but once you pay competitively it is not money that motivates someone to go above and beyond everyday.
And it’s not about deadlines and pressure
There is plenty of evidence to show that knowledge workers respond particularly badly to being rushed. A recent Harvard business school study called “Creativity Under the Gun” examined the daily diary entries of more than 9,000 people working on projects that required high levels of creativity, and measured their ability to innovate under different levels of time pressure. It turned out that workers were least productive when they were constantly required to fight the clock. While working under extreme time pressure, they came up with fewer fresh ideas, not just on the day of the deadline but in the days that followed. Tight deadlines and a creating a sense of urgency looses its potency quickly and kills teams. We need to retire a sense of urgency completely.
It’s about Autonomy, Mastery and Purpose
Dan Pink’s excellent book Drive explore what motivates people in detail and he suggests that the secret to high performance both at home and at work boils down to three thing, the deeply human need to direct our own lives (autonomy) , to learn and create new things (mastery), and to do better by ourselves and our world (purpose).
In order to create a high performing team you need to instill these 3 virtues in your team, here are some useful techniques to do this.
When forming an autonomous team the firstly thing you need to consider is the team structure. A team can only be truly autonomous when it is fully empowered to make its own decision. Such teams are self-directed and are fully responsible for determining how to solve problems within the constraints defined by the business. Cross functional teams as popularized by Spotify’s squads own the end to end delivery of functionality — they are made up of a product owner, UX designer, developers & testers.
Ideally teams should be around 5 to 7 people in size. This ensures that they are easily managed and meetings can be kept efficient, any larger and the team becomes more difficult to manage and slows down. This picture illustrates how the number of lines of communication grows as a team grows in size, it pretty much sums things up
Establish a clear decision making process
Next you need to establish some clear boundaries for the team, what types of decisions can they make by themselves (the more the better) and what type of decisions need to be made external to the team. I find it a really useful exercise to have your team write down what type of decisions they are empowered to make and what type of decisions they feel they ought to be able to make, it can be a real eye opener.
Establish open honest communication
Open communication tools such as slack are great for establishing honest transparent communication and sharing knowledge. Emails should be kept to an absolute minimum if at all. Did you know that every time a team member has a closed conversation via email an angel cries! Whatever knowledge is shared or agreed via emails lives in a lonely inbox never to be discovered by new joiners or other team members. Do the team a favor and outlaw email!
Pull versus push model
There is a high correlation between a lack of empowerment and poor performance. A team needs to be able to manage their own workload day-to-day, be able to make technical decisions and, if necessary, to make changes to the way they work. Teams perform best when they are given a clear, commercially focused brief, and then empowered to figure out the best way to deliver by themselves. Stories should be pulled from the top of the product backlog into the sprint by team members.
Make it safe to fail
Eric Ries famously describes a startup’s runway as the number of pivots the business can make before they run out of cash. The quicker you build something, test it out and change tactics if it fails the better. Whether you work in a small or large organisation creating a culture where its safe for teams to fail is vital. Autonomous teams aren’t afraid of making mistakes, they celebrate failure and learn from it. Making mistakes early means the team can learn and adapt. In fact if a team isn’t failing and making mistakes and improving along the way I’ll bet it isn’t going fast enough. Great teams ask for forgiveness not for permission!
Fostering a culture of craftsmanship and continuous learning is hugely beneficial and rewarding to the team. A team who are focused on continually improving and learning will deliver great things and they won’t accept mediocrity or tardiness.
Continuous delivery = continuous learning
When working on a product that has a long release cycle, it is common for teams to work on several features or bug fixes before seeing any of them released to production. This is a huge problem, when things break (and things will always break) it’s much more difficult to root cause the problem and deploy a fix. On the other hand, with more frequent deployments, the time between releases is much shorter. Breaking changes are fixed while the functionality is fresh in everyone's minds.
There’s an old saying — if you aren’t good at something do it more often. Moving to continuous delivery helps teams to get much, much better at packaging, testing and releasing their changes. A software engineering team who push their code directly to production as often as they like have no process to hide behind other than the one they create an master themselves.
Allow time for self improvement
Schedule time for your team to learn and improve. Here’s a list of useful techniques
Brown bag talks — invite people from your company run an informal presentation / talk at lunchtime. The topic should be something that they are very familiar with that others can learn from. Reach out to friends at other companies and invite them to come talk at your office for 40 mins over a lunch.
Tech popcorn — put aside an hour during the week for your team to watch a tech talk or presentation online and facilitate a discussion about what was learned afterwards (Friday afternoon’s work well).
Communities of practice (Cop) — autonomous teams can lead to silo’s of information around your organisation. CoP’s are organized groups of people who have a common interest in a specific technical or business domain. They collaborate regularly to share information, improve their skills, and actively work on advancing the general knowledge of the domain. For example you could encourage a product owners CoP or a test engineers CoP to form in your organisation. From my experience CoP’s will spin up and die away and be replaced with different ones over time. It’s healthy for new ones to form and existing ones to peter outMore info here
Code kata — Coding kata’s are about solving a problem through code many times, the point of the kata is not arriving at the correct answer. The point is the stuff you learn along the way. The goal is the practice, not the solution. Plenty of kata’s available here
Hackathons — Corporate hackathons are a great way to inspire your team to work together in new and creative ways. They promote creativity, collaboration, and innovative thinking. I’ve previously written this post on how to run a corporate hackathon
Power of the retrospective
The retrospective meeting is the most powerful tool your team has to focus on mastery and self improvement. Its an opportunity to reflect critically over the previous sprint and identify area’s where the team can improve. If you find that your team’s retrospectives are getting stuck in a rut then check out the fun retrospective website for idea’s oh how to spice them up.
The third and final virtue to instill in a team is a strong sense of purpose. This all starts with a great product vision that is understood by everybody. A team needs to understand what they are working towards. Once you understand the WHY you can then clearly connect every decision you make and every feature you add to where the product is going. Your product vision serves as a north star for the team guiding their work and decision making process.
Product backlog must be intimately understood by all
A product backlog shapes the teams’s purpose. The backlog must be intimately understood by the entire team; the trade offs around which feature goes next and why one feature is more important than another must be understood by all the team.
The open window test !
Imagine your entire product backlog was written up on card and stuck to the wall in priority order and that a gust of wind blew all the cards off the wall. If you asked each team member to pick them up and put them back in priority order would they order the cards the same way? If the answer is ‘no’ then you need to share more information about the backlog with everyone.
When used effectively physical walls, whiteboards and electronic displays amplify key metrics for your team. You should surface data that will provide feedback to your team on how successful they are — depending on your line of business this could be your total customer count, sales information, site up time , bounce rates etc. When the information is beamed up in highly visible area’s around the team it serves to remind everyone of the product purpose and how things are going.
Celebrate customer feedback
A continuous customer feedback loop is vital part of shipping product — a feature isn’t fully cooked until its been validated, tweaked and tested with customers but all too often we forget to celebrate the feedback and achievements. Find way’s to regularly share customer feedback with your team. Nothing is more rewarding than hearing how a new feature you worked on delights a customer. The customer feedback loop feeds a teams sense of purpose.
Great agile teams deliver often. They get something out in to the wild and respond to feedback. Agile teams win trust from their successes and recovery unscathed and stronger from their failures. In order to build a team that can win trust you must first build a framework around a team that enables them. By shaping your teams you are shaping your delivery process. There are three virtues I believe your process should embody: autonomy, mastery and purpose.
Like this post? please give it some love & share ;-)