Photo by Victor Freitas on Unsplash

Empowering Development Teams

Published on 3rd September 2019 3 min read

An empowered development team owns its work, is authorised to make the right decisions, and is able to work independently. Empowered teams are happier, create better products, and allow you, the person in charge of the product, to spend more time on product discovery and strategy. This article shares five tips to help you empower your development teams.

Show People that You Care

Empowering development teams starts with taking a sincere interest in the individuals, attentively listening to their ideas and concerns, and empathising with them. This shows that you care and value people’s perspective; it builds trust; and it gives the team members the confidence to step up and take ownership.

If people don’t feel safe, they may shy away from accepting additional authority and only do what their job description requires. In the worst case, empowerment is seen as a trick to make development teams do more work and blame them if things don’t go to plan.


Create Autonomy through Shared Goals

To help your team take ownership and work autonomously, establish shared goals. A good example are sprint goals: A sprint goal captures the desired outcome of a sprint and is agreed by product owner and development team. Having a sprint goal in place enables the team to decide what needs to be done and how the work is performed.

In order to create shared goals, involve the team members in the decision-making process. Use collaborative decision-making techniques, such as deciding by consent, to secure people’s buy-in. Don’t try to persuade or pressurise teams to accept a goal. Otherwise, the members may not take ownership. Consequently, they may not care much if the goal is met or not.

At the same token, hold people accountable for meeting goals—assuming that they have agreed to them. Be grateful for people’s effort and goodwill and acknowledge the challenges the team may have encountered. But provide clear feedback and do not allow people to sidestep or ignore shared goals.


Let the Team Own the Solution

I commonly find that product people believe that they must precisely describe the product functionality and spoon-feed their development teams with detailed user stories. While this approach may be appropriate when a team does not sufficiently understand the user needs and lacks user story skills, it should not become a habit. Instead, you should help your development team grow, acquire the relevant knowledge, and let people take full ownership of the solution or, if that’s not possible, the product details.

A great way to do this is to include the team members in product discovery and UX work and allow them to observe and interact with users. Additionally, involve the development team in the product backlog work and teach people how to formulate and refine user stories. This may increase your workload initially. But in the long run, it will reward you with a more autonomous and motivated team, and more time to take care of product strategy and discovery.

While giving people ownership of the solution is important, it is not enough to empower a development team: If a team is held back by dependencies, working autonomously is impossible. You should therefore ensure that your development team owns the software it develops—be it an entire product or a product part like a feature or component—and that it has enough people with the right skills onboard. This might require adjusting the team setup, for example, moving from component to feature teams, as well as cross-skilling team members or adding new people to the team, for instance, hiring a new UX designer.


Encourage Self-organisation

An agile development team should take full ownership of their work. This includes planning and tracking the work and identifying impediments. But it also means learning to effectively collaborate, constructively deal with conflicts, and make joint decisions. While it’s the Scrum Master’s responsibility to support self-organisation, there are a number of things you can do:

  • Ensure that you establish shared goals that clearly describe the desired outcome of a sprint, as discussed above.
  • Do not interfere with the work of the team during the sprint. This includes not assigning tasks and criticising individuals, and not changing the sprint goal once it’s been agreed.
  • Actively participate in the sprint retrospective. Offer constructive feedback, address issues and concerns, and help resolve them.

Be aware that it takes time for a group of people to become a self-organising team and that the learning process may involve setbacks and mistakes. Newly formed development teams tend to find it hard, for example, to reliably meet their commitments. You may consequently have to be patient and allow the team to use the first few sprints to learn how much work they can be accomplish in a sprint.


Give the Team the Opportunity to Learn and Develop

Finally, encourage a growth mindset amongst the team members and give people the opportunity to learn new skills, and experiment with innovative tools and technologies, for instance, by allocating some learning and development time in every sprint or scheduling hack days.

While this leaves the team with less time to progress the product, it boosts people’s motivation. What’s more, it avoids the risk that the team is so busy cranking out new features every sprint that new technologies are overlooked and opportunities to further improve the product are missed.

Post a Comment or Ask a Question

4 Comments

  • Pim says:

    Great story and ideas Roman. I was wondering something about the following: “I commonly find that product people believe that they must precisely describe the product functionality and spoon-feed their development teams with detailed user stories.”

    I tend to see a tendency from development teams requiring this very badly. Asking a PO to make a definitive, final, extremely detailed list of ‘acceptance criterions’ before they are willing to pick up the work. Now, this could be a chicken and egg question; a non-empowered team might ask this more often. On the other hand, I typically value changing details in requirements during a sprint for a specific story, because looking at the first iteration of an idea leads to learning and consequently improved ideas. This comes with a risk of not being able to complete other work, which a PO has to make the trade off for.
    Would you agree, or do you have other thoughts?

    • Roman Pichler Roman Pichler says:

      Hi Pim,

      Thank you for sharing your feedback and question. Some development teams do need detailed requirements, as I mention in the article. The key point is IMO to develop and empower the team rather than believing that the product owner should own the solution and therefore determine the detailed requirements. If in doubt, use a sprint retrospective to reflect on your product backlog grooming/refinement practices. Ask the dev team members how happy they are with their involvement and the quality of the requirements and listen to their ideas and concerns. Then decide together how to move forward and enable the team to take on more ownership.

      As you probably know, sprints should be protected from changes. This allows the development team to focus on meeting the sprint goal, and it increases the chances that the goal is met. You should therefore reduce the need to make adjustments to the stories the team is working on in a sprint. Based on what you’ve told me, you may want to look at how you validate new and changed functionality and consider using a different method, for example, demo or usability test instead of release. This might allow you to collect feedback more quickly and reduce the need to make adjustments during the sprint.

      Hope this helps!

  • Srikanth Ramanujam says:

    Shared goals is one part of it, but it comes after Shared purpose. I have found that the best teams actually share the solving of problems rather than meeting goals. Not covered here is Product Discovery. In my best teams, Scrum refinement = Product Discovery, where the problem statements that the teams are solving have been transferred to the teams to solve.

    • Roman Pichler Roman Pichler says:

      Thank you for your feedback Srikanth. You are right: Teams benefit from a purpose, an overall inspirational goal. That’s why I’ve linked to my article “Leading through Shared Goals“, which introduces a set of cascading goals with the vision at the top. I also mention product discovery and recommend including development team members in the in the discovery work, see the section called “Let the Team Own the Solution”. But I find it helpful to distinguish between product discovery and backlog refinement. The former refers to the activities required to determine if and why a product should be developed; the latter describes the work required to make detailed product decisions, update the product backlog, and get the backlog ready for sprint planning. Hope this helps!

Leave a Reply

Your email address will not be published. Required fields are marked *