One of the first things I did when I started at EstimateOne 9 months ago was to survey our entire Software Engineering team. The conversations were worth their weight in gold, however, one key theme I found was that the team was unsure what they needed to do in order to get promoted.
Since growth is a proxy for happiness at work, it was clear this was an issue that needed solving. We needed to make sure the team knew that EstimateOne was a place for growth and development (and not just the development of code).
I’ve had a few people asking questions about estimation when doing agile software development so I decided I would write down some ideas in the hope that others may find it helpful.
Firstly, there are many who argue that estimation is not a good practice to apply in software development since it often doesn’t end up affecting prioritisation, moves the focus away from iteration, and is essentially guesswork applied to unpredictable and non-repetitive work and more. The key point is that not only does estimation not offer a good return on investment but that by doing it, the team shifts…
This article will take a close look at what makes high performing software development teams, as well as what hinders them. It will cover each level of the organisational hierarchy starting at individual software developer, then a team of engineers, full cross-functional product-engineering team, wider product-engineering department, and finish at the entire company. At each level, we will see multiple examples of teams to see what factors contribute to high performing software teams, as well as less well performing teams.
Here are some things you might get out of this article:
Head of Development at EstimateOne. Builder of High-performing software teams, grower of cultures.