We know that software development moves faster when the work is split into small, independent batches. In other workflows, small batches can also shorten feedback loops dramatically – if the batches are the right kind of batch. The definition of the batch is critical. Let’s look at why.
The Batch Must Deliver Immediate Value
We’re looking at our development as a set of batches moving through a series of work activities. Applying queuing theory to this system will maximize the output of batches – and it will do so regardless of what those batches consist of. If your batch is a collection of miscellaneous work, you’ll have more miscellaneous work done at the end of day – but is that really what you want? Most of us have more than enough work already. What we want is more usable stuff at the end of the day. We’d like immediate value, not potential value – something the company can either sell, or use internally to speed up or improve its work. To get more value per day, the batch must be defined to deliver value.
Early on, some people tried treating “write a specification” or “write a design document” as batches. When they maximized their output of these batches, they got … more documents. Not more software. This led to the birth of the user story.
The User Story Delivers Value in Software Development
In agile software, the user story is carefully defined to both deliver immediate value to the customer and enable rapid feedback to the development team. Even if the user story isn’t actually delivered to the customer, the rapid feedback delivers substantial and immediate value to the company.
That’s because software teams operate in a morass of uncertainty. Their customers literally can’t articulate what they want. The team can’t accurately predict how long it will take to make new software. And every hour of coding provides dozens of opportunities to make errors which can lie unseen for months. Small, fully completed batches provide rapid feedback in all three areas, reducing overall effort and allowing the company to be more responsive.
Other Fields Have Different Types of Value
User stories are defined to deliver exactly the value that addresses issues in software development. The same definition won’t necessarily deliver value in other fields. For each field, think about what value consists of and when it can be delivered. For instance:
- In a medical lab, the batch could be a test or set of tests – scheduled, performed, results delivered to the requestor, and billed.
- A tools group might define their batch as a new tool or a new capability in an existing tool.
- An integration test group might define their batch as one which answers an important question about the state of the system. For instance, “does the integrated software perform well under load” or “what’s the likelihood of unfound serious defects”. Here, the value delivered is knowledge which will steer the progress of the project.
Is It Necessary to Always be Releasable?
Scrum and its cousins are tailored for software which will be released via the Internet or an internal network. In these projects, customer needs are typically not well understood. Releasing the software after each sprint provides highly valuable feedback concerning the customer’s wants and needs, as well as forcing the team to maintain a high level of quality.
However, in other software projects, insisting that every increment deliver value directly to the end user may not deliver maximum value to the company. For instance, embedded software projects might reap enormously useful technical feedback by creating increments which drive successively larger portions of the hardware, but the end user may be totally uninterested in those early increments.
The key to success in this type of project is to identify what is of most value to your project. What uncertainties are you trying to diminish? Which feedback loops do you want to shorten?
The Knowledge Gap Delivers Value in Hardware Development
What is a useful batch in hardware development? Again, look for the value.
Long slow loopbacks are a major barrier to agility in development of physical products. Decisions are made early with incomplete knowledge. If the decision has to be revisited, the cost of change is often very high – much more so than in pure software.
Knowledge which enables more accurate decisions can radically reduce the rework. The Rapid Learning Cycles framework splits the knowledge acquisition itself into batches called Knowledge Gaps and Key Decisions, carefully defined to deliver value in the form of accurate decisions.
The Knowledge Gaps and Key Decisions are managed in ways similar to those used in Scrum for user stories and epics – but these batches are not user stories nor epics. The value delivered is different. These batches achieve agility by addressing the issues which are specific to physical product development.
And That’s Not All…
It’s possible to speed up hardware development even more by splitting other parts of the overall work into other types of batches which deliver other types of value. For instance, system integration can often be split into smaller batches using slice-based integration. This and other ideas are addressed at more length in our book Agile Gets Physical.
And, some software projects rely on decisions which have a very high cost of change. Rapid Learning Cycles can be helpful on those projects too – see Rapid Learning Cycles: Agile for COTS Projects.
So, software has its batches and hardware has its batches. Next, we’ll look at how to manage batches efficiently and effectively using queuing theory principles in Get More Batches Done Faster.