Increasing a scrum team’s velocity can become the metric to focus on. A team with a higher velocity will deliver more work, faster. Who wouldn’t want that?
Unfortunately, there is a physical limit to how much a scrum team can deliver, a terminal velocity if you will, without then asking the team to push themselves beyond what they would normally be able to do or asking them to compromise on quality. It is your classic triangle of choices:
The triangle of choices represents the compromise you must make when choosing between three conflicting options. You can sit on the line between any of the three options and take the two that sit on the end of that line, but at the expense of the remaining option.
When faced with the choice though, which of the options do you compromise on? An organisation is unlikely to want to compromise on speed (of development) otherwise what would be the point of focussing on velocity? And if you’re delivering software for a customer, does a lower velocity mean a project comes in late? How does that affect the reputation of the organisation?
There’s arguably a bigger reputational risk by compromising on quality. Releasing late is one thing, but releasing poor software? If it manages to survive, a poor product will pass its notoriety down to its descendants — ask an experienced developer to support Microsoft’s Edge browser and IE6 will immediately pop into their mind. Myths persist about the latest browser based on the reputation of its great-great-great-great grandfather. Or ask Skoda why it felt the need to poke fun at itself in order to try and shake off its reputation for poor build quality.
So that leaves cost. Cost in this sense refers to people cost, but in two different ways.
The first is additional resource, and this seems like an obvious route — more people means more work can be completed and at a better quality; win all around. But increasing team size carries inherent risks. As discussed in the Mythical Man Month , additional resource on a project means additional training to bring people up to speed. This is usually conducted by a senior developer. Then there is integration of tools and workflows and integration within the team itself, with each additional person resetting the dynamic of the group. Bruce Tuckman described this in his four stages of team development: forming — storming — norming — performing (later, a 5th stage was added but this described the dissolution of the team, which is not a normal case for scrum teams). A performing team will usually drop back to the forming phase when a new member joins as everyone readjusts to the new dynamic. This reduces the efficiency of the team, even if only temporarily, the antithesis of what we were trying to achieve if we’re focussing on velocity. And what happens if the new group don’t get past the storming stage?
Another issue with additional resource is how many more people do you add to the team? There’s debate on the best size for scrum teams but the accepted figure tends to be between 5 and 9. The reason purported for a maximum of 9 people is that the number of communication channels grows exponentially with every person you add to a group. Using the formula (n * (n — 1)) / 2, we arrive at the number of communication channels required to maintain an effective group (where n is the number of people). For example:
If n = 3 then
(n * (n - 1)) / 2
(3 * (3 - 1)) / 2
(3 * 2) / 2
6 / 2 = 3 communication channelsIf n = 4 then (4 * 3) / 2 = 6
If n = 5 then (5 * 4) / 2 = 10
if n = 6 then (6 * 5) / 2 = 15
if n = 9 then (9 * 8) / 2 = 36
This can sometimes be better represented using this diagram:
Image courtesy of https://getlighthouse.com/blog/developing-leaders-team-grows-big/
In the interest of full disclosure, I don’t buy into this way of thinking; no team I know holds one to one communication in this way.
Away from cost of resource, cost can also refer to the cost of effort, i.e. how much will it cost the developers in overtime, extended effort, stress, the effect on personal or working relationships and trust? Will the developers be willing to bear the brunt of that cost? For how long?
Essentially we’re left asking our existing developers to go above and beyond what would normally be acceptable. Seth Godin refers to this as Maximising. He argues that maximising is “a short-term output level of high stress, where parts degrade but short-term performance is high”.
As developers, especially those of the pre-Agile ilk, we are well versed in pizza and coffee-fueled nights where we worked furiously to fix a major issue or get a critical piece of functionality ready. This was always in the knowledge that is was a short burst to a rare situation. In those moments we built and created things we probably thought weren’t possible at the outset, but time pressure (high stress) is a wonderful driver and the camaraderie was amazing. The business might question (and often did) why this level of output wasn’t possible all the time; are developers slacking during normal working hours? The answer is an emphatic NO! The developers I have worked with are proud of the what they do; the code they produce is a source of personal pride and suggestions that they might be slacking would be seen as a personal attack. The truth is developers are human beings, not machines, but the “parts” still degrade. Mental health, for one, is only recently starting to make headlines in the UK, and prolonged exposure to stress is a key cause of mental illness.
Maximising reminds me of the story of Henry Ford. In an effort to create the first car at a price that was affordable to the masses, Ford knew that he had to drive down costs; to do this, he needed to improve efficiency. Ford was influenced by Frederick Taylor’s work on scientific management and so brought him into his Model T production factory. Taylor set about improving production using the methods he had created (such as breaking tasks down into component parts and making them as efficient as possible). With the introduction of conveyor belts, the modern day assembly line was born, with people an easily replaceable part of an efficient machine. And they needed to be replaced; the conveyor belts didn’t slow, the parts didn’t stop coming and the pressure from management forced the workers to quit. Rather than an optimisation of the process, it became a continual, forced maximisation of the employee. At the time the answer to the churn was a level of pay unseen anywhere else in the country, meaning there was no shortage of willing men. The threat of being without work and unable to feed your family was a very real driver for people.
Does applying the same logic to the modern world, to skilled professionals with niche skills, work?
At best, a drive for ever increasing velocity will result in short-term uplift that skews the average velocity over time to levels that are unsustainable. At worst, the drive will cause conflict between the business and scrum teams, demotivate developers, decrease retention and could have health repercussions. Management may feel developers are taking an easy ride and the trust between the two groups evaporates.
A business focus on optimising scrum teams, rather than maximising them, should be the goal.
- An optimised scrum team is one that operates at optimum efficiency, not maximum output
- An optimised team is one that has mutual trust in each other and the business
- An optimised scrum team is one that can communicate effectively
- An optimised team is one that is allowed to focus on delivering high-value work to stakeholders, and not side-tracked into low-value quick fixes
- An optimised team is one that understands its responsibilities, commits to delivering on those responsibilities every single sprint, and does so knowing that the business shares that vision
If you want to use velocity as a key metric, fine but understand that it is a long-term metric that fluctuates sprint by sprint. Look to introduce other metrics, such as a reduction in the volume of rework or a reduction in the number of bugs in the backlog.
The best scrum teams are aware of the need to improve efficiency, which is why they have retrospectives built into every sprint; it is their chance to analyse their methods and improve on them. Scrum teams should be holding themselves and each other to account and ensuring retrospectives are run every sprint, with the actions followed through. Ask your scrum teams what improvements they made to their processes in the previous sprint and what improvements have been suggested in the current one — one of the three pillars of the scrum process is transparency, so good scrum teams will be more than happy to share this information with you. If they can’t, find out why and resolve whatever is preventing it.
If you want to build great products, build great scrum teams and encourage them to “do scrum” properly. Educate the business in Agile and take the time to explain why they should invest in it across the organisation. Once it’s in place, hold teams (even non-development teams can use agile) to account on whether they are adhering to the principles and carrying out the ceremonies religiously. But most importantly of all, remember that these are people we are dealing with, so don’t treat them like expendable, replaceable parts in a machine.
Originally published at Matt Asbury.