Slow It Down
Causes and Symptoms of Too Rapid Software Development
In the digital age, the demand for software, and therefore software engineers, only increases. Long gone are the days where significant delays in delivery are accepted. To meet existing regulatory and competitive demands, developers must rapidly produce more software. Yet until the cavalry arrives, the same technologist population will be pressured to meet the need.
Rapidly increasing velocity to address these requirements can have dire consequences on the quality of our products. With the going getting tough, many of these consequences are coming to light. Lately I’ve asking myself, are we delivering software too quickly? From too slow to too quick, this week I reflect on the causes and symptoms of quick-fire development, the pressures it instils, and propose solutions to address the resulting predicament.
Under Pressure
To examine the effects of the development dash, we first need to understand the causes. I’ve identified three primary reasons for our recent software build scramble.
There is more to life than simply increasing its speed.
― Mahatma Gandhi
The cliche response of pressure is definitely one. Yet the weight comes from several different places. Management pressure is the obvious one. Aggressive delivery deadlines, originating from executives or business leaders, produces a team of Atlas’s desperately holding the weight of the world on their shoulders. Programmers may feel a compelling personal obligation to deliver in these circumstances. Nurturing ownership within the squad does foster quality in the craft. But it can also lead to them meeting delivery pressures until they burn out.
Thirst for knowledge may be another contributing factor. With many established patterns and technologies in regular use, building out new features can become repetitive. When new technologies infiltrate the stack, everyone wants a shot at playing with the shiny new toy. They may therefore rush through the known tasks, dreaming of a shot at the unknown. While drive to learn and improve should be commended, sacrificing quality to get there should not be encouraged.
Insufficient planning and estimating is the final weighty nail I’ve seem hammered into the proverbial pressure coffin. Although it can be partially down to time pressures, that’s not always the case. Story breakdown and estimation are a key part of Agile practice. Yet the feeling among our squad is our breakdown requires rework. Currently sufficient detail is not put into the breaking down of stories. Additionally, stories and tasks themselves are too large and require splitting. This leads to confusion in development as developers struggle with multiple blockers, unplanned work and coordination of tasks.
Warning Sign
Identifying the causes is one thing. Detecting the manifesting issues are another. How does these factors affect the team and their deliverables? You may be fortunate that programmers will proactively raise concerns. We are lucky that our recent retrospectives have resulted in many frank discussions on identified issues. Developers have also proposed a ton of new ideas on how to address them. Regardless, squads should be on the lookout for some of these symptoms.
From a Scrum standpoint, you may see regular rollover of stories into the next sprint. Uncompleted stories are a classic indication of over-commitment in a cycle. This is expected when the team start practising Scrum. If it continues beyond a couple of sprints, or re-surges in an established team, this should be considered a sign of over-commitment and potentially poor planning.
Mumblings around compromising behaviour on quality and definition of done is another. It may come from the team, or from senior management. That initial discussion of dropping test coverage, delaying refactoring or deprioritising technical debt should be considered with extreme caution. Standing your ground on standards is far from a sign of stubbornness. Reducing focus on these thresholds sets a dangerous president that quality and stability is less important than feature delivery. Quite often this exacerbates the pressure by contributing to our final warning bell.
The most prominent issue to beware of is an increase in defect rate. Of late, I have seen these manifest in two scenarios. If we are fortunate, it will be a behavioural defect identified in a sprint review, or in subsequent user testing. If we are unlucky, and we have been, they shall present as production defects that require urgent remediation. These lead to a self fulfilling cycle of incomplete sprints, as the effort taken to address these problems will detract from development of the features to which you have committed.
Fix Me Now
As a leader, the natural, human reaction may be to get angry and push more for teams to solve problems as they appear. I’ll raise my hand and admit to making this mistake recently. Yet, playing the blame game and scolding developers like children is the wrong call. It shows a lack of leadership and control. Furthermore, it suggests taking failures as an individual loss rather than a collective responsibility. I’ve found alternative tactics to be far more effective.
As a first, be comfortable slowing down the pace of development. Discuss the current situation honestly with the Product Owner. Any defects or technical debt that have been identified to date should be documented in the backlog and prioritised with other work. Having all items present in the backlog gives full transparency to the Product Owner.
Speaking of the Product Owner, evaluate if developers are obtaining clarifications with the Product Owner often enough. For us, it has become apparent that we should be showing smaller progress points throughout the sprint to garner feedback. By showcasing small breakthroughs every few days, engineers are building a stronger relationship with our PO, and obtaining clarifications far earlier in the sprint.
On the quality argument, consider revisiting your definition of done. If individuals are discussing dropping quality thresholds, they may not be aware of the agreement. Otherwise, programmers may not feel they have committed to this software development contract. Be mindful that you shouldn’t compromise on quality and coverage metrics, but instead ratify the existing values. Also evaluate if there are items you are regularly not producing, and have frank discussions to ascertain if they are required.
Last, but by no means least, reevaluate your estimation technique. For us it has become clear that more effort and care needs to be taken on story breakdown and estimation. Think not just about task breakdown, but also story size. Perhaps you need to slice stories further using some of these techniques. It could be you need to redefine your relative sizes by re-estimating problematic stories. Or it may be as simple as committing to less points per sprint. Addressing these issues is by no means a sign of defeat. But an indication in the strength to provide true client value in a reasonable pace.
Thanks for reading! Claps, comments and insights are always appreciated.
