Clear, concrete and transparent goals are the most important factor of every successful project. And yet, only 1 in 10 teams successfully executes their goals. Usually teams spend much more time on HOW to do things instead of WHY they want to do it.
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.
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.
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.
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.
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.
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.
Of course, there’s more to learn to get even closer to software management nirvana. Here’s a few of our articles that will help: