It is sometimes beneficial to ramp up a large software step by step. This promises doing earlier business, reducing risk and gaining momentum. Just slicing a large development into arbitrary pieces will however not work well. Teams need a bit more strategy so that each delivery is useful and provides significant value. This article introduces business scenarios and 6 slicing patterns that help product owners and agile teams to align incremental product development with growing the business.

Rather than working for years and then rolling out a software system in a big bang, teams try to deliver value step by step. There are many good reasons for this, e.g:

• Reduce to needs: When providing products to customers and users, teams learn what is essentiell and what not. They provide just what is needed and remove dreams and wishes.
• Gain momentum: Creating products that work well, people like and use is rewarding and motivates team and stakeholders. Thus earlier releases, earlier boosts of motivation.
• Manage complexity: Splitting up a product development in smaller steps reduces complexity of the individual step. Development teams can tackle higher complexity.
• Anticipate change: People start adapting as soon as they use a product and even change what they do and how they do it. With quick releases teams can observe such changes more easily and adapt their plans.
• Reduce risks of migration: When an old product is replaced with a new one, gradually moving users and customers to the new product allows to test and optimize the new product, while the old one is still working.
• Do early business: With a release, companies test the market, win over early adopters, gain fans and start spreading the word. They might even earn money earlier.

The promise sounds great – it just needs a bit of strategical thinking (quite a bit, actually, and some clever technical solutions).

A business scenario – a step to grow a software.

The promise above is based on the assumption, that a team can build a fraction of the system envisioned and bring this to users and customers. They need a useful vertical slice of the overall solution. This slice provides some features, interfaces with only some of the other systems, can be used for some process steps by some of the users and brings value for just some of the customers in only one spot on the market. In itself, it is valuable enough that customers and users are willing to pay back, e.g. in form of money, recommendations or feedback. Such a slice is a business scenario.

Incremental product develop follows a string of such business scenarios that lead a team from making some business with a small product to making real business with a mature product.

Robot automation

When developing a solution to automate sheet bending with an industrial robot (see the case of a relevant UX problem), the development itself was part of an overall strategy. The company first tested a hypothesis with a cheap solution provided to “friends and family”. They learnt about what really mattered to their customers. Based on this experience, they developed a mature product. Looming on the horizon is already the next evolutionary step: the integration into a smart factory solution.

For the development of the mature product, splitting by customer types reduced complexity: Job shoppers produce different pieces in quite small batches with stand-alone machines. They want to quickly create an efficient enough automation. Mass producers integrate the machine into an assembly line and invest quite some time to maximize the throughput of their assembly line. Splitting by customer type went along with splitting by product: The different bending machines were targeted for different customer types. From a development point of view some highly complex features could be delayed and much less hardware needed to be supported.

Trade shows play an important role in this industry. Thus using those windows of opportunity and presenting the new things at a trade show was a crucial step on the road to the market. Not everything needed to be ready for the trade show. Knowing the scenario to present made it feasible.

Finally, there are a lot of technical difficulties to be tackled: e.g. robot simulation, 3D drawing, generating and executing the program with the robot and the machinery. The earlier the team could tackle these risks, the better.

A working development strategy thus was:

Sketch	Using paper, pencils, cardboard and other simple materials, the team sketched out possible solutions and tested them with stakeholders, experts, customers and users. The goal, come up with a good approach.
Spike	Evaluating the technology and putting it together into a first working prototype to learn about the known unknowns. In this case: the robot simulation and whether commercial tools were powerful enough.
Skeleton	Getting the process ready end to end, i.e. from creating the automation in the software, downloading it to the machinery and running it. For starters, something very simple, e.g. moving the robot from A to B, is good enough. With this, the team found some unknown unknowns.
Trade Show	Adding features needed so the company can demonstrate the process at a trade show and learn about customer’s reactions to the product.
Beta	Completing the process to a degree so we could run tests with “friendly” customers (job shoppers). Here a few more of the unknown unknowns pop up.
Small	Enhance and complete the features to launch for the small machine for job shoppers.
Large	Enhance, add additional features and hardware support to launch for the large machine and for mass manufacturers.

Sports event management

For a step by step migration to a new core system, a sports association sliced their releases along business capabilities. With this, the employees could use the new system e.g. for inviting guest and organizing travel while the registration process for athletes was still handled with the old tools. Data migration, interfaces to other systems and the number of features were drastically smaller.

In addition, employees were grouped around types of events. Each event is essentially one product of the association. Each group took care of one specific type of event. Thus by tackling each event in turn, the team reduced the number of stakeholders to talk to and users to support drastically. The small number of users allowed to release a new feature with just an acceptable comfort level and then enhance it from real live feedback.

Preparations for such a sports event can run over a couple of years, some activities coming early, others later. Providing features right for the up-coming activities allowed users to profit from the system years before the whole breath of features was actually implemented. It just needs a good understanding of the window of opportunity.

Startup an App

Looking from the outside on a couple of great software packages provided on the web and in App stores, one strategy pops-up every now and again.

The companies seem to grow their business by first providing a really cool digital service, quite often free of charge. Because the thing is simple and fun to use and really useful, even though it may lack some important features, their fans use and tell others about it. The user base grows and some of the users are willing to pay for the service. In addition, the private customers bring the tools into their business context, quite often through the back door. By adding features that really support operations in a business, for example user management, security and integration, the tools now become more and more attractive for businesses as well.

This strategy seems to work especially well for products, that enable collaboration and communication or any other social activity. These tools have an inherent spreading mechanism: Because one person likes the tool, this person will invite others and they will become users. If they like it, they will do the same with yet other persons. The formula is quite simple:

great service  x  easy sign up  x  social activity = growth

6 slicing patterns

Reviewing the three examples, I propose the following six patterns to vertically slice up a large software into business scenarios. As the examples show, the combination of the patterns make it work.

#1 – by market: Tackle each market or each customer type separately (even each customer, in some cases). Obviously, this needs to be in-line with market communication and the business plan.

#2 – by capability: Usually, companies are structured around capabilities and processes. Tackling them strategically is a very good way to cut a big system in sizeable steps. Especially as the units are quite often also build around capabilities.

#3 – by product: As seen, tackling each product separately can reduce the number of stakeholders to talk to, to train and to support. It allows to learn from real usage with less risk.

#4 – by window of opportunity: For most development, timing is important. Knowing the window of opportunity and what is really needed by when allows again to provide features just in time. The system can be used, even though major features are still missing.

#5 – by interfacing system: An airport steering center coordinated the many companies at an airport and developed a system that integrated systems from the different providers. Slicing by source system worked well: Each of them brought new data and possibilities to the users, simplified their work and was thus desirable to have. The teams only built features that matched the data actually available over the interfaces.

#6 – by increasing the level of quality: Finally, a good strategy is to build up a product (or a single feature) using a risk driven approach with increasing level of quality:

1. Story: Sketch out the idea and test it, so you know what is really important.
2. Spike: Start with a spike or even several spikes – if, an only if, your engineers doubt that the available technology allows to create the product at all, i.e. the product is still in the clouds.
3. Skeleton: Get the key technology to run (in a very simple way with very little functionality).
4. Essential: An essential product has all the features and functions needed so you could call it a product of a kind. In most cases, the essential product offers only a small amount of the features that people would expect from a safe and enjoyable product and what marketing wants to sell. Still, the essential product already contains the key excitement factor (see From exciters to liabilities).
5. Compliance and comfort: Increase quality and comfort to a degree, that the product complies with regulations, is safe to use and users enjoy the product and use it productively.
6. Viability: Enhance so the product can compete on the market.

To be aware of

Incrementally introducing a product has drawbacks and pitfalls. Here are some key ones:

• Bad press: Users and stakeholders will talk about a product. If the product is not good enough, they will also spread this word. The result is high pressure and difficulties to roll-out to new users and customers.
• Cost of parallel operation and the never ending story: When replacing a current product, operating two systems in parallel comes with a significant price tag: operation, maintenance, synching data and state between the two systems. This can get quite disastrous, when the old product stays on forever, e.g. because teams delay the retirement of the old product in favor of adding new features to the new product.
• Throwing away too much: When incrementally delivering value, teams also build up the technological foundation behind the scenes. However the world around a product changes and incrementally delivering a product even accelerates the changes. It needs some exceptional brains to anticipate such changes and build up the foundation just capable and simple enough.

Conclusion

For larger developments, teams can benefit from growing the software system step by step. With each step, the system provides more value and enables yet another business scenario: E.g. another customer type, another process or capability, supporting another service or product. Each step makes use of the windows of opportunities and builds up the level of quality.

A sequence of business scenarios is most powerful, when it is in line with how the company wants to grow the business with the product. Business scenarios bring a strategy to development and link market events with the features to develop.