Building a high-performance agile team sounds simple. But when you wade into the detail, getting teams working together to ramp up delivery while maintaining high levels of service can seem a daunting task. It doesn’t have to be.
In this post I’d like to share 3 simple principles that we’ve used to help put together agile teams that:
- include a blend of customer and supplier people
- cover a range of disciplines (from services designers and developers to delivery managers and business analysts)
- deliver at speed
Together, these principles improve collaboration and achieve team goals. They help the team see where delivery is headed, which raises the confidence of everyone involved.
I believe these principles can be applied to any digital delivery in any organisation, whether on a project already underway, or one just beginning. They’re certainly the foundation for much of our service delivery work at Made Tech.
1. Break down silos
If you’ve ever worked in or around an agile team this won’t come as a surprise, but siloed ways of working must be removed. That means breaking up specialist teams built around disciplines, and putting those disciplines together into delivery teams.
This helps your teams to:
- stay in continual sync to maintain focus on the next objective
- identify problems and blockers, and deal with them, quickly
- share ideas, skills and learning
There are a number of ways we do this:
Work in the same room. It’s important to get everyone collaborating in one room. These days, a virtual room like Microsoft Teams or Google Meet is fine.
Use an agile framework. We always adopt a suitable agile framework such as Scrum to help teams identify needs, refine them into user stories, divide work into sensible iterations and deliver on our goals as one team.
Iterate continuously. Iteration is often used in the context of improvements to a service, but it’s important to iterate on ways of working too. Nothing is ever perfect, so we keep looking out for tweaks we can make to improve how we work to make sure our teams are productive and happy.
Communicate openly. We always try to foster a culture of open working and transparency within the team, including by making space to share thoughts, feedback and ideas on a regular basis. It’s important this is done in a safe, no-blame culture, which is something that has to be continually worked at.
2. Automate testing
Once you’ve removed silos, automating testing is an ideal next step. We tend to see this as a distinct second step because, often, testing tends to be one of the most siloed disciplines within digital teams.
In older modes of delivery, teams of developers would build a feature, then throw it over the proverbial wall to a team of testers. Once they’ve picked it up from their backlog, the testers try that feature out, lobbing feedback back over the wall to the developers as needed. That process is repeated for every feature that needs to be built.
A problem with this approach is the risk involved at the “over the wall” stages. Mismatches in communication, expectation and the change in responsibility can be avoided by approaching testing differently. But worse, when you try to scale this way of working to test hundreds of features, you have hundreds of regression tests every time you need to ship a feature.
Factor in the various choices a customer can make as you build out the user journey, possible interactions with integrated services, extra language requirements and more, the scope of the service and the need for testing grows exponentially. Meanwhile, budgets and the team’s ability to get work done do not.
The answer is to automate testing so that this ever-growing need for testing can actually be done. These are tests that need to be coded just once by the team, but can be run every time a change to the service is made. To say this is a worthwhile time investment is an understatement: once in place, any automated tests you write will continue to pay dividends over the lifecycle of the project, so it makes sense to automate everything you possibly can.
A crucial step towards doing this is sharing skills between roles, and particularly between developers and testers. Basically, your developers need to understand testing, and your testers need to be able to write automation code.
I’ll resist a Field of Dreams analogy at this point, suffice to say that, if you set up this collaborative skill-sharing, you’ve essentially created the circumstances necessary for the team to make automated testing happen.
3. Change slowly
This is hugely important: implement any changes you make to your team’s way of working slowly. One way to explain why this is important is to think backwards, starting from those ways of working. These are tied up with people’s roles and hence their professional identities. This is very important to understand and respect.
People’s ideas and preconceptions will inevitably be challenged, so it’s important people see the benefits of new ways of working first-hand and at their own pace. Change will necessarily affect culture as much as working processes.
Agile is arguably more a mindset change than a process one. It’s vital to get everyone aligned as to the desired outcomes the team hopes to achieve, and then to understand their individual role in making that happen.
Regardless of which agile framework you adopt, it’s important to do so considerately. A great way to start the process is to kick off with domain knowledge-sharing sessions. This helps everyone to reinforce their own value within the team, as well as gaining insights that can benefit the team as a whole.
The nature of agile means that, in time, this process accelerates as the benefits of agile working become clear and self-reinforce, as well as highlight opportunities to course-correct.
Happy, effective teams
By putting these 3 principles into practice you should be well on your way to building a high-performing, agile team with the host of benefits that come with it. I’m just going to touch on a few here.
One major benefit to this approach is the trust that it builds within the team. This allows them to self-organise, encouraging sharing of skills, knowledge and work to be done, which keeps everyone focused on the goal of building a high-quality service.
A second benefit is that putting different roles and skills side by side not only enables more learning, but also builds empathy, which leads to a happier and more effective team overall. Automating testing, too, can only help team morale by increasing confidence that defects will be found, not to mention reducing the time needed to do so.
This all adds up to a higher-quality codebase that’s easier and more enjoyable to work with, increasing staff retention in the team while reducing maintenance overheads and cost of ownership. To put it another way: everyone wins.
To find out more about how you can apply these principles, break down barriers of communication, and introduce new ways of working please get in touch. Or you can read more about our approach to Digital Service Delivery and Embedded Capabilities.
Or if building high-performing teams from the inside sounds like it’s for you, view our open roles and learn more about a career at Made Tech on our careers page.
