On Quality and Speed. Next steps to take after going agile
By: Mikkel Ravn
Tags: Programming, Startup, Continuous Delivery, Agile, Software Development

On Quality and Speed

Photo by Kevin Bhagat on Unsplash

Agile frameworks promise both higher quality and increased delivery speed. But applying a run-of-the-mill agile framework to your software development teamwork is only a first step.

What follows is a summary of a decade of readings on what your next steps might be. References included.

Quality from rapid feedback

So, your development team has a definition of done to guard quality?

Fine.

But as you probably well know, quality is not something you achieve at the end of a two-week iteration by running the produced output through a checklist. Software can do arbitrary things, and often does, even if design and code look plausible. With software, quality is a result of feedback. And because every line on your screen, every thought in your head might be subtly flawed, you need that feedback to flow continuously. Otherwise, you and your team will end up wasting time dealing with poor quality downstream. The further it flows, the more time you waste.

Your IDE provides immediate feedback from incremental compilation and static analysis. Your pair programming mate points out inconsistencies and misconceptions as soon as you type them in. Your unit test suite will tell you in seconds if the code you are writing doesn’t do what you intended, or if your latest change broke existing functionality. These are some of your primary guards against poor code quality. And they have one thing in common: they are fast.

But even they are not fast enough. Just because the code you write is technically perfect doesn’t mean the feature makes sense to your users. Or that your work is aligned with the rest of your team. You need earlier feedback informing you whether you are building the right thing. Only then does it make sense to ask if you are building it right.

Quality starts before coding. Together with your product owner, you define the outputs that you believe will lead you to desired business outcomes. You gather feedback from quick and cheap experiments. Once you’re confident you are on the right track, you work with domain experts and testers to flesh out the details. You need enough detail to be able to write down an informal spec with examples. The feedback from that exercise is invaluable, as misunderstandings are uncovered and removed before being engraved in code and other artifacts. And you can then take those examples and make them executable, driving detailed design and coding from there. Designing your APIs and classes in parallel with automating specs and tests provides the feedback you need to do high-quality detailed design: It’s hard work to automate tests for bad design.

Further down the line, your CI server provides feedback on whether your latest code push can be built and integrated with changes made by your teammates, and whether the full suite of automated tests is still green. You want that kind of feedback within minutes. If you have many tests, CI pipelining and parallelization should be used to avoid delaying feedback.

Your friendly reviewer might look at your code and provide peer feedback within hours. A nightly stress test will have fresh results for you tomorrow. Next up, the system may be deployed in a staging environment and made available to on-site users. Testers might perform manual, explorative testing. You might run a demo for your product owner or prospective customers. Later still, you can employ basic DevOps practices like production monitoring and A/B testing to inform you how the change fares after going live.

As long as feedback is good, software changes are shared in progressively larger circles, impacting more and more people and having consequences further and further into the future. The outermost circles contain your future users and customers. Rapid feedback is a means to ensure you get your work out there as fast as possible while identifying and containing enough cases of poor quality to keep you out of trouble.

Some of the above practices might slow you down. You may find that writing unit tests, pairing, and doing reviews make individual code changes flow more slowly from your hand. Practice helps, a lot. But still.

What you need to recognise is that this isn’t about you. It’s all about the team and the speed at which it can sustainably deliver value to customers. Optimising that forces you to limit the collateral damage caused by poor quality.

Recommended reading

Forsgren et al: Accelerate. IT revolution press, 2018

Gothelf & Seiden: Sense and Respond. Harvard Business Review, 2017

Adzic: Specification by Example. Manning, 2011

Humble & Farley: Continuous Delivery. Addison-Wesley, 2010

Delivery speed from visible work

So, your development team has post-it notes representing tasks up there on the board, and a nice burn-down chart next to it?

Fine.

But boards and charts are severely underused, if they mainly serve project management purposes. Reminding everyone what we are working on and when we are likely to be done can be useful. It just doesn’t move the needle.

The main point of making work visible is continuous process improvement. To achieve that, your board needs to adequately reflect work as it actually happens. So if a team member is interrupted for half a day to fix a burning production issue, there needs to be an item on the board to represent that task. Make it bright red. Count the red ones by week or by iteration. If their number is too high or increases over time, level up on your feedback loops.

You also need boards that show the full value stream. If your team is delivering to a down-stream team for integration, QA, or operations, then the “Done” column on your board is not done in the sense that customers are now getting value from your work. Rather, it probably means your work is collecting dust in some queue elsewhere in the organization. If that queue is not visible anywhere, chances are that the waste it represents is not on anybody’s radar. That’s a shame, because there may be a substantial cost of delay attached to each queued item.

Frequent interruptions and long queues are just two types of information you want to glean from your boards. Others are batch size (related to the speed at which items move across your boards), amount of work in progress (the number of moving items on your boards at any given time), and bottlenecks (items stacking up in front of some busy resource).

You need this information to improve delivery speed. You need to visualise and track the flow of value through your organization to discover and remove impediments.

In particular, high levels of work in progress can be surprisingly inefficient. Software teams, however, seem quite capable of ignoring this type of waste. Maybe because work items are non-physical, so they are not piling up on the factory floor. Maybe because branch switching, recompiling, redeploying, refocusing your mind, resolving merge conflicts, and retesting feels like doing real work.

Work items often exhibit high variability. Some features can be completed in hours, others take months. But a work item stuck “in progress” for two months is not flowing. And the flow metrics you collect provide little insight due to the variance involved. Work break-down is key here. You may find it useful to separate discovery work from delivery work on your boards. Discovery work is where research, experiments, solution design, and work break-down happen. It is unpredictable in nature and you handle that by iteratively taking small bets to buy yourself more information.

Once you settle on something to build, you produce a stream of small, well-understood work items to be delivered. Delivery work can then happen at a more predictable and faster cadence. In essence, delivery work establishes and aligns detailed understanding, tests, code, and documentation before pushing a work item through your CI/CD pipeline all the way to production. Where needed you can use a feature toggle until enough work items have been delivered and you are ready to unveil the new feature to your users.

The holy grail in flow thinking is atom-sized batches, produced immediately after conception and delivered to customers as fast as they can be consumed — often meaning multiple times daily. Some organizations are getting close to achieving that, and it is probably hard to exaggerate the advantage they have over competitors with yearly release cycles.

Recommended reading

Goulding & Shaughnessy: 12 Steps to Flow. Flow Academy, 2018

Kim et al: The Phoenix Project. Trade Select, 3rd ed, 2018.

Humble et al: Lean Enterprise. O’Reilly, 2015

Hammarberg & Sundén: Kanban in Action. Manning, 2014

Reinertsen: The Principles of Product Development Flow, Celeritas, 2009

More next steps

Speed and quality are critical to success. But you also need your teams to move in a concerted fashion and the ability to take sharp turns when required. You’ll find more next steps in the companion article On Alignment and Agility.

Resources