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.
The post Empowering Development Teams appeared first on Roman Pichler.
Empowering Development Teams posted first on premiumwarezstore.blogspot.com
No comments:
Post a Comment