There are many challenges in building an agile team. We hear about self organising teams, but how can a CTO ensure a roadmap is kept? We hear about #noestimates, but how can we plan anything without estimates? Failure is an important part of agile, but how can we accept failure in production? Communication is key, how can we encourage it?
In this article I will attempt to address these questions and more.
Delivering great product takes great teams but putting them together is challenging. It is easy enough to stick a group of people in a room, give them a list of tasks and ask them to complete them by a date. What is not guaranteed is that any of the tasks will be completed when you expect.
Before we build a team we must first come up with a definition of a team. What does a team mean to us? Who is it comprised of? What is its purpose?
Let us just say a team is a group of people brought together for a purpose. It will be made up of everyone required to realise its purpose. In the world of software development, teams are brought together to implement new functionality, to bring improvements to systems and to solve issues.
The purpose of a team is also important. We can define a team's purpose or goal as something that will be reached within one short iteration, perhaps two weeks at most. A team must begin with a goal and end with the delivery of the goal.
We can take this definition a bit further and apply it to building a team. To build a great team is to engage a group of people around a particular goal with enough energy to see it through to a conclusion.
Great agile teams deliver often. They get something out in the wild and respond to feedback. Agile teams win trust from their successes and recovery from failure. In order to build a unit that can win trust you must first build a framework around a team that enables them.
When pulling together teams you are shaping your delivery process. There are three virtues I believe your process should embody: autonomy, craft and focus.
Working towards a common goal requires buy-in from a team. They need to be interested enough in working together in order to achieve the desired outcome. The feeling of responsibility and ownership will strengthen their resolve to achieve a goal. They must be allowed to make mistakes so that they can learn from the pain of failure. A team must have permission to solve a problem how they see fit. This is autonomy.
Thriving on responsibility
Given to a team, autonomy is powerful in that the responsibility for delivery is felt strongly. When they can make their own decisions there are fewer reasons to not deliver and fewer blockers.
A software engineering team who can push their code directly to production as often as they like have no process to hide behind. When you can QA yourself there is no need to wait for someone else to check your work and you can therefore move faster. When such barriers are lifted a team will know that the buck stops with them and more often than not teams thrive with such responsibility.
Realisation of responsibility
Transitioning a team into a self organising structure can take time. Sometimes we find a team isn't used to such responsibility. They can be unaware of it and even actively try to avoid it.
We have noticed that process can be introduced by team members who are not ready to move so fast. We find some teams feature creep or change their goal completely mid-iteration. Such sabotage comes from an engrained sense that work is continuous, without a start or a finish.
Introducing ceremony around delivery cycles such as a showcase during and at the end of the iteration can help. Getting the team to present their work when they reach a milestone can really help a team self organise. The key is to not allow showcase dates to change so that a team has to explain to stakeholders when they haven't achieved their goal. This drives them to make changes to avoid the embarrassment in future.
Ask forgiveness, not permission
When we work with businesses where teams don't have so much autonomy as we're used to, frustration can soon ensue. Autonomous engineers quickly get frustrated at being unable to solve problems themselves.
A team must have permission to carry out their purpose.
When deployments of certain applications must be performed by a particular person, especially someone outside the team, then those used to being able to deploy anything will soon be saddened. Same goes for not having permission to create new taskboards, email addresses, etc. Teams must be empowered to do all of the above. A team must have permission to carry out their purpose.
When teams are autonomous they will make mistakes. They will often make more mistakes but they will also be fixing them faster. Making mistakes early means the team can learn and adapt. Autonomous teams may be fast to break things but also fast to fix them.
We have heard horror stories of a fast moving autonomous team having a 2 month deploy freeze on their project after breaking stuff that they could have fixed in 5 minutes. This is not the way to deal with failure, a team must have the autonomy to fail and correct such failure.
Empower your teams
A team becomes empowered when they can self organise and complete their purpose with minimal blockers from the outside world. They should be allowed the chance to show off their agility when making mistakes. Their autonomy will strengthen their resolve when they feel the responsibility and power to deliver is with themselves.
A culture of craftship is important to an agile team. A team who are excited by their ability to solve a problem the way they want will enjoy working towards a common goal. Practices such as Test Driven Development and Continuous Delivery are both indicators of excellence and also improve the ability to achieve a goal. A team who are excited to discuss their work will be having the conversations necessary to solve a problem as a team.
Love for the job
When an individual loves their craft they will be excited to solve problems. A group of excited people solving problems have a collective energy that can be felt when you walk into the room they occupy.
A good sign of a team that love their job include seeing two people sitting at one computer discussing a problem. Another perhaps when they're standing by a story board discussing their next task.
Positive energy goes a long way and can keep a team interested and undistracted for longer.
A software team practicing Test Driven Development and Continuous Delivery will be exposed to industry best practices enough to know about these methodologies and more.
Expertise within a team will accelerate the speed at which problems can be solved. If they've been practicing them for a while you may well have yourself an expert team. It can also help up skill other members although there will always be a cost to productivity when expert members divert attention to assisting others.
Thrill of craftship
The buzz in the air when you walk into a team's room is a good sign of healthy communication. Those excited and caring of their craft will be happy to discuss their techniques with colleagues who may in turn offer up even better solutions.
Walking into a room and everyone has their headphones on is a sign you may have a problem. You want the communication to be flowing.
Of course communication and craftship aren't the same thing but good communication does come with a team who are good at their craft.
Cultivate your craft
Bringing together a group of people who care for their work is key to achieving goals. The positive energy from a team's excitement is the fuel to going the extra mile and to achieving goals more efficiently. With care of craft comes best practices that will help ensure the quality of work delivered. Healthy communication means problems will be solved collaboratively with the combined expertise of a team rather than by siloed individuals. Craftship is a must for solving problems.
Bringing a team together to solve a problem is hard. The bigger the goal, the more likely you are not to succeed, so it's best keep those goals small. A team built of members who aren't always allocated to that team is sometimes a necessity but is to be avoided whenever possible as context switching isn't fun. Same goes to a team working towards multiple goals, context switching isn't fun so don't do it.
Defining a goal
Carefully defining a team's goal is crucial to their success. We find the smaller the goal the more likely we can accurately predict a completion time.
Smaller goals are easier to put live since a goal affecting a smaller surface area means there is less risk associated with change.
Undiscovered complexity is also less likely to disrupt an iteration. The smaller the problem we are solving the less likely it will explode into a massive piece of work that affects our deadlines.
A common problem we've found working with clients is that team members are often not committed 100% to a particular team.
Often team members will be pulled from one team to another to help out with a problem. Sometimes team members are actually committed to both teams. We try to stop this as soon as we can as it completely breaks focus.
We try to ensure goals are broken down enough so that we can finish one goal before switching focus onto another. This means a team member will be at most busy for a couple of days before being able to move to another team to provide their expertise.
A similar problem is that of the ronin engineer, or more simply, an engineer without a team. They are usually in charge of a piece of technology rather than working within a team.
Service desk type system operations is a variant of the ronin. This is where you have a team dedicated to a technology rather than a team such as infrastructure or deployments. We try to move these engineers into a single team. We also try and knowledge share their expertise as soon as possible so they do not become a blocker for other teams when they are busy.
Solve one goal at a time
Teams should have a single goal when they are brought together. A single goal means they can focus on solving that problem properly before starting another one.
We often setup taskboards per goal and only let a team work from that board. If other work emerges we ask teams to make note of it and bring it up in the showcase of their current goal.
When goals change
Sometimes mid-iteration a goal will change based on some learnings. You may find that another change must be made before your original goal can be achieved. At this point you cancel the iteration and pull stakeholders together to share learnings.
Goals may sometimes actually be two goals in disguise. It is not always obvious until you start work. This realisation is again a good time to stop and pull together stakeholders.
After debriefing everyone you can redefine the goal you want the team to solve first. Remember, solve one goal at a time.
Focus is paramount
Focus within a team is paramount to getting a problem solved. Just like breaking big stories down in traditional Scrum, goals should be broken down into their smallest possible incarnation. Team members should be allocated to a single team and that team to a single goal.
The framework on top of which you form teams should make team work fun. Autonomy, craft and focus are all virtues that can help you achieve this.
A team needs to know they have the power and responsibility to solve a challenge. A team needs to be excited about their solutions, conversating and learning from each other. A team needs small focussed goals in order to deliver on time.
I'm interested to hear what your experience is with building agile teams. Does the above ring true for you? What virtues do you foster when building teams?