Small-Batch Thinking

By “small batches,” I mean identifying the problem to solve, formulating a theory of how to solve it, creating a hypothesis that can prove or disprove the theory, doing the smallest amount of coding necessary to test your hypothesis, deploying the new code to production, observing how users interact with your software, and then using those observations to improve your software. The cycle, of course, repeats itself, as illustrated in Figure 1-1.

Figure 1-1. Small-batch thinking is a cyclical process.

This entire process should take at most a week—and hopefully just a day. All of these small batches, of course, add up over time to large pieces of software, but in contrast to a “large batch” approach, each small batch of code that survives the loop has been rigorously validated with actual users.

Schools of thought such as Lean Startup reduce this practice to helpfully simple sayings like “think, make, check.” People like to prepend “lean” to various software roles, as well: lean production management, lean designer, or just lean on its own. What you call the process is up to you, as long as you actually follow it.

This discipline gives you a tremendous amount of insight into decisions about your software. A small-batch process gives you a much richer, fact-based ability to drive decisions about features to add, remove, or modify. In turn, this creates much better software. No matter how many tests run green or schedule milestones are cleared, your software isn’t done until a user validates your assumptions.

Liberty Mutual’s Chris Bartlow describes the core benefit of small batches:

When you get to the stoplight on the circle [the end of a small-batch loop] and you’re ready to make a decision on whether or not you want to continue, or whether or not you want to abandon the project, or experiment [more], or whether you want to pivot, I think [being hypothesis driven] gives you something to look back on and say, “okay, did my hypothesis come true at all? Is it right on or is it just not true at all?”

The record of your experiments also serves as an ongoing report of your progress. Auditors will cherish this log of decision making and validation. These well-documented and tracked records are also your ongoing design history. This makes even your failures valuable because you’ve proven what doesn’t work and, thus, what you should avoid in the future. You avoid the cost and risk of repeating bad decisions; these are savings that can be passed on to other teams who can now avoid those invalidated decisions, as well.

Shift to User-Centric Design

The small-batch loop enables a highly effective, user-centric approach to software design. The simplest, most accurate definition I’ve seen is from Pivotal Labs:

User-centric design ensures that the software solves a real problem for real users in a desirable and usable product.

There’s little new about taking a user-centric approach to software. What’s different now is how much more efficient and fast it is thanks to highly networked applications and cloud-automated platforms.

In the past, studying and refining desktop software was difficult, costly, and slow. Outside of their labs, designers knew very little about how people used their software. Well, they knew when there were errors because users fumed about bugs. But, users rarely reported how well things were going when software functioned as planned. Worse, users didn’t report when things were just barely good enough and could be improved. Without this type of knowledge, designers were left to, more or less, just make it up as they went along. Slow, multimonth, if not year, release cycles made this situation even worse. Even if designers knew how to structure the software better, they would need to wait through each release cycle to test their theories.

Starting in the mid-2000s, networked applications, released frequently, finally gave designers a rich trove of data to continually analyze and use to improve their software design quality. For example, a 2009 Microsoft study found that only about a third of its applications’ features achieved the team’s original goals—that is, were useful and considered successful. This allowed the team to adjust its focus accordingly, improving the software but also removing time wasted working on and supporting underused features.

Good design is worth spending time on. Maxie Schmidt-Subramanian and Laura Garvin Tramm at Forrester, for example, estimate that car manufacturers improving customer experience could bring $49 to $100 uplift in per customer revenue, and $8 to $10 in the banking industry. Those might seem small per person, but multiplied across millions of customers, it adds up: $879 million for car manufacturers, and $123 million for banking.² Without a doubt, good design creates differentiation and drives revenue.

From Functional Teams to Product Teams

Traditional staffing and organization models are a poor fit for the small-batch process. Most organizations are grouped into functional silos: developers are in one bucket and project managers are in another bucket. The same goes for QA, security staff, database administrators, architects, and so on.

A small-batch approach, however, moves too fast for this type of organization. Communication and handoffs between each silo takes time: business analysts must communicate and explain requirements to developers; developers need to document features for QA and get the approval of architects; project managers need to spelunk in email and interview people to update project status; and DBAs, well, they’re a deep, deep silo to cross.

When you’re making weekly, if not daily, decisions about the product, all of this coordination also loses fidelity between each silo. Additionally, as Lean Manufacturing has discovered, those closest to the work are the best informed to make decisions about the product. Business analysts, enterprise architects, and, worst of all, executives simply don’t have the week-to-week knowledge about the application and the people who use it.

Functional organizations also encourage local optimization: each group is focused on doing its part instead ensuring that the overall outcome is good.

To address these problems, you need to rearrange your organization chart to favor product teams. Let’s look inside these teams and see what they’re made of.

Product Teams³

Each team is dedicated to one application, service, or sizable component of the overall system. Unless you use the First National Bank of Mattresses, you likely understand a retail banking system and its subcomponents: a ledger, a transfer service, a bill-paying service, new service sign-ups, loan applications, and so on. The backend will have numerous services like single sign-on, security checks, and so forth. Each of these areas maps to a product, as shown in Figure 1-2.

Enterprise architects are well positioned to define these groups. One method is to use domain-driven design (DDD) to discover the “bounded contexts” that define these teams. The entity and event trails described by a DDD analysis also help define the team’s data models, dependencies, and methods of interacting with other teams (e.g., APIs and events). “Forming those teams allows us to distill to the heart of the problem we’re focused on in order to gain competitive advantage,” says Jakub Pilimon. As we discuss later, this intersection of business strategy and technical acuity is exactly the role of the enterprise architect.

After a product team is formed, its goal is to focus on the end-to-end process of delivering quality software. Instead of spreading that responsibility across many different groups, all of the roles needed to “own” the software are put on one team. That team is dedicated to the product full-time and given the trust and authority to decide on features, schedules, and most everything related to that product. In turn, they’re responsible for running the software and its outcomes. This is analogous to how a software vendor works: the vendor’s core business is delivering a product, not the implementation of a bunch of requirements from a distant third party.

Figure 1-2. Examples of product teams by application and service.

As illustrated in Figure 1-3, each product team has three key roles: developers, designers, and product managers. In addition to these might be supporting roles that come and go as needed—testers, architects, DBAs, security staff, data scientists, and other specialists.

Figure 1-3. Any given product team has three major roles: developers, designers, and product managers.

Developers

These are the programmers. Developers also give technical input to the team, directing which technologies and architectural models to follow and build. They also determine the feasibility of various solutions: can we really do instant dog-breed recognition in real time on a PalmPilot?

Through the practice of pairing, knowledge is quickly spread among developers, ensuring that there are no empires built and addressing the risks of a low bus factor. Developers are encouraged to rotate through various roles, from frontend to backend, to get good exposure to all parts of a project. By using a cloud platform, like Pivotal Cloud Foundry, developers also use continuous integration and continuous delivery (CI/CD) tools to deploy code on their own, removing release management wait times.

Developers are closely involved with estimating the length of time that stories in your backlog will take to implement as well as in scoping stories. Similarly, developers can help product managers and designers walk through the technical trade-offs involved in deciding how to implement and design features.

Applying the principle of owning the product end to end, developers also ensure that their software runs well and can be managed in production. Some very advanced teams even have developers manage and remediate applications in product—a practice of orthodox DevOps. Having that kind of skin in the game motivates developers to write production-ready code.

You shouldn’t expect developers to be mythical “full-stack developers”; that is, experts in all programming and operational concerns. Instead, they rely on a cloud platform’s self-service and automation capabilities for most operations needs. This means, for example, that developers don’t need to wait for operations staff to requisition development environments, set up middleware, deploy releases, or perform other configuration and release management tasks.

There will, of course, be operations knowledge that developers need to learn, especially when it comes to designing highly networked, distributed applications. Initially, prescriptive patterns help here as well as embedded operations staff. By relying on their organization’s cloud platform to automate and enforce routine operations tasks, over time developers often gain enough operations knowledge to work without dedicated operations support.

The number of developers on each team is variable, but so far, you’ll typically see anywhere from two to six developers, and sometimes more. Too many more and you risk reintroducing communications overhead; this is also often the sign of decadent scoping.

Product manager

At its core, the product manager is the “owner” of the team’s software, the product. More accurately, product managers set the vision week-to-week, pointing the team in the right direction.

It’s best to approach the product owner role as a breadth-first role: these individuals must understand the business, the customer, and the technical capabilities. This broad knowledge helps product managers make the right prioritization decisions. It also gives them the knowledge needed to work with the rest of the organization and relevant stakeholders like auditors and “the business.”

In organizations that are transitioning, this role also serves as a barrier between the all-too-fragile new teams and the existing, legacy teams. The product owner becomes the gatekeeper that keeps all of the “helpful” interest and requests at bay so that the teams can focus on their work.

Designer

One of the major lessons of contemporary software is that design matters a tremendous amount more than previously believed...or, at least, budgeted for. Although nice-looking UIs are all well and good, effective software design is much more than looks. The designer takes responsibility for deeply understanding the user’s needs and challenges and how to create solutions to overcome these challenges. Designers are the architects of the conceptual workflows that make users productive.

The designer focuses on identifying the feature set for the application and translating that to a user experience for the development team. As some put it, design is how it works, not (just) how it looks. Activities might include completing the information architecture, user flows, wireframes, visual design, and high-fidelity mock-ups and style guides.

Most important, designers need to get out of the building and not only see what users are doing with the software, they need to become intimately familiar with those users and their needs. Peripateticism is helpful for all roles, of course, but vital for designers.

As discussed earlier, supported by platforms like Pivotal Cloud Foundry, the small-batch process gives the designers more feedback on their design theories than ever. This makes it feasible and worthwhile to embed designers on product teams.

Design has long been neglected by most organizations, which often find design skill severely lacking. The design role is critical to good software, however, so leaders need to quickly budget for and find designers.

Case Study: No One Wants to Call the IRS

You wouldn’t think a big government agency, particularly a tax-collecting organization, would be a treasure trove of good design stories, but the IRS provides a great example of how organizations are reviving their approach to software.

The IRS historically used call centers to provide basic account information and tax payment services. Call centers are expensive and error prone: one study found that only 37% of calls were answered. That is, the IRS hung up on more than 60% of people calling for help! With the need to continually control costs and deliver good service, the IRS had to do something.

In the consumer space, solving this type of account management problem has long been taken care of. It’s pretty easy in fact. Just think of all the online banking systems you use and how you pay your monthly phone bills. But at the IRS, paying delinquent taxes had yet to be digitized.

When putting software around this, the IRS first thought that it should show you your complete history with the agency, over multiple years and types of transactions. This confused users and most of them still wanted to pick up the phone. Think about what a perfect failure that is: the software worked exactly as designed and intended, it was just the wrong way to solve the problem.

Thankfully, because the IRS was following a small-batch process, it caught this very quickly and iterated through different hypotheses of how to solve the problem. Finally, developers hit on a simple finding: when people want to know how much money they owe the IRS, they want to know only how much money they owe the IRS. The team removed all the lavish extra history from the UI. When this version of the software was tested, most people didn’t want to use the phone.

Now, if the IRS was on a traditional 12- to 18-month cycle (or longer!), think of how poorly this would have gone. The business case would have failed, and you would probably have a dim view of IT and the IRS. But, by thinking about software in an Agile, small-batch way, the IRS did the right thing, not only saving money, but also solving people’s actual problems.

This project had great results: after some onerous upfront red-tape transformation, the IRS put an app in place that allows people to look up their account information, check payments due, and pay them. As of October 2017, there have been more than 2 million users, and the app has processed more than $440 million in payments. Clearly, a small-batch success.

Transforming Is Easy...Right?

Putting small-batch thinking in place is no easy task: how long would it take you, currently, to deploy a single line of code, from a whiteboard to actually running in production? If you’re like most people, following the official process, it might take weeks—just getting on the change review board’s schedule would take a week or more, and hopefully key approvers aren’t on vacation. This thought experiment will start to flesh out what you need to do—or, more accurately, fix—to switch over to doing small batches.

Transforming one team amd one piece of software isn’t easy, but it’s often very possible. Improving two applications usually works. How do you go about switching 10 applications over to a small batch process? How about 500?

Supporting hundreds of applications and teams, plus the backing services that support these applications, is a horse of a different color, rather, a drove of horses of many different colors. There’s no comprehensive manual for doing small batches at large scale, but in recent years several large organizations have been stampeding through the thicket. Thankfully, many of them have shared their successes, failures, and, most important, lessons learned. We look at their learnings next, with an eye, of course, at taming your organization’s big-batch bucking.