Blog Post

Whenever you’re managing a team of developers, productivity problems may occur.

Productivity may be an overused word these days. But in the end, aren’t we all looking for results?

Hours of development work don’t come cheap these days – and yet when you ask the team about progress during a Sprint, it’s almost always a disappointment.

And you have no idea why. You’re sure more could be done. You miss your deadlines and have to explain that either to your clients, your superior, or both.

It’s a common situation – but it doesn’t have to be your reality. It is possible for you to call your devs and hear that everything is done according to the schedule. They might ask you eagerly for more work or they could get done more than you expected.

How can you reach this productive team nirvana? Here’s 5 practices that will help you manage your developers better.

This usually results in implementing unnecessary functionalities or causing huge refactor efforts in a freshly delivered release. It also undermines the team’s motivation and engagement.

Productive teams are focus on the “why”. They ensure that their goals are well-defined, known and understood by everyone. Productive teams work with their Product Owners/Stakeholders to understand the value of the envisioned features.

Action steps

Share your vision with the team, ensure that all team members understand your “why” behind the project.

Support your team on a daily basis, help them validate their actions against your goals.

2. ‘T-shape’ your team

In the world of rapidly changing technologies where specialists are worth their weight in gold, a team built on solid cross-functional foundations is fundamental for every successful project.

It’s a rare situation where Sprint tasks can be ideally mapped to the core skills of your team members. There is always too many or too few tasks for either backend or frontend developers, or the amount of work on test automation or manual tests sometimes exceeds the amount of available testers.

Competences bottlenecks tend to happen from Sprint to Sprint and cause Sprint leftovers.

The key to solving this is to build teams with T-shaped skills. The T-shape is an abstract to describe someone with deep vertical understanding in one area (such as backend development or test automation, etc.) but also with broad, but usually not deep, knowledge in other areas.

Imagine a Python developer who is great at using the Django framework but can also do a little bit of frontend and create basic E2E automated tests – that’s a T-shaped team member.

T-shaped people have a positive impact on the scalability of the team, but more importantly they can eliminate skill bottlenecks.

Action steps

Reward your team members when they improve their versatility.

Encourage and help your team to work outside their core skills and comfort zone.

Offer your team a training budget.

3. Stop starting, start finishing

The most common symptom which may indicate low effectiveness of the team is a high amount of work in progress.

High WIP causes Sprint leftovers. Usually about 60% of Sprint tasks are 70% done and 40% are 100% finished, which may break one of the fundamental Scrum principles of providing a potentially shippable product every iteration (as described in the Scrum Guide). Working on more than one task at a time also requires costly context switching.

Productive teams are aware of the true cost of multitasking and avoid it at any cost. They seek to limit WIP no matter what type of development method they are using. Keeping WIP under control is built into the Kanban and Lean approaches but it can be successfully used in different methods such as Scrum.

Action steps

Limit your tasks in progress to your number of manual testers (the WIP must be equal or less than your number of manual testers) or try the Swarming approach by applying the whole team to one ticket/story.

Visualize your tasks board and discuss it on a daily basis.

Work with the team to prepare a ‘Definition of Ready’ and ‘Definition of Done’.

4. Build trust with your team

Micromanagement is a great way to create a bunch of people blindly following the manager’s orders – but it won’t help you build a team. Total control destroys creativity and takes responsibility away from the team. It also makes the project a ‘one-man show’ without nearly no support from the team.

Good managers use trust as a basic tool for project development.

They value leadership more than direct management. Trust is their secret recipe which combined with transparent vision, a cross-functional team and reliable processes makes them the Team Six Navy Seals of modern development.

Good managers use a no-blame environment to create a spirit of trust. If mistakes happen, they use them as an opportunity to work collectively on the best process solutions for future use.

Action steps

Focus on results and account for results.

Let your team fail from time to time and help them learn from their mistakes.

Give honest feedback based on facts not opinions.

Don’t provide solutions.

Give them your time, be always around to support them.

Encourage your team to build their own processes.

5. …and continuously improve

A development team needs forward momentum. Otherwise, it might fall prey to an old truth, in words you may have heard before:

He who moves not forward, goes backward.

Johann Wolfgang von Goethe

Fortunately, modern development frameworks have improvement processes in place, such as the retrospective.

Productive teams use retrospectives for continuous improvement. They do not limit the ‘retro’ only to development process; they also focus on products, the process and improving the attitude of the people involved. The best teams understand the power of small changes.

Action steps

Fix small meaningful things by following the Kaizen philosophy.

Measure if the implemented changes improved your situation.

Motivate people to drive improvements.

Conclusion

Keep in mind that the above is just my subjective list of topics. However, I’m sure that If you use it wisely, it will improve the productivity of your teams. I also encourage you to test different approaches and tools on your own.

Gaining experience as a software development manager, I’ve realized that the development process is much more about people than technologies. If there’s one rule of thumb to follow, it’s this: everything that improves people’s interactions will improve their productivity.