Some IT shops often make the mistake of trying to fit all projects into one development process. In fact, this is the primary focus of many Agile and quality initiatives. However, it doesn't work, because the projects are actually different. A new experimental project is not the same as a big mature project. An application for a marketing campaign needs to move fast. Billing system development should be slower, secure and reliable.

Fortunately, many projects go through some predictable stages of life. If you think of software as having a lifecycle and not a plan, you will have projects that are more efficient at each stage of life. This is the idea behind the Beyond Scrum Roadmap. It illustrates some typical patterns of task management and code management.

Roadmapping and prototyping

Almost all projects start with roadmapping. You write down everything that you want to deliver. This is sometimes called brainstorming. You then sort those things in priority order. Finally, you take the top deliverables and form them into a minimum useful release. This gives you a vision of the completed system, a rough plan (roadmap) showing the order of delivery, and most importantly, your marching orders for the first release.

All projects should start with prototyping. You quickly and informally build a system to test technical possibilities and your assumptions about what will be useful.

My rule of prototyping is to use one person, or a very small team. Prototyping should be a cheap way to try anything new. It is an essential tool for any kind of innovation, in any stage company.

At this point, you are in continuous delivery paradise: just code it and show it. But your product will not be reliable.

Scrum with release branches and release candidates

After people start using your software, you want to test it before you release it. You will move to iterative releases, where you take the time to build a release candidate and test it. You might even decide to move all the way to Scrum because of the good feedback that it provides for small teams. This is not paradise. It is annoying to take big chunks of time to fix bugs and deliver complete features. However, your users will like the result.

Scrumban and Continuous Integration

If you have distributed teams or barriers to in-person planning, you will want to move to Scrumban, a planning approach that combines Scrum with lean concepts. It is a simple change: just skip the iteration plan and pull tasks when you are ready to work on them. You will start moving back toward continuous paradise.

However, you need to do some real work to get to paradise. You may find that it takes longer and longer to test and release each iteration, because your software contains more things to test. When this happens, you can solve the problem with continuous, automated testing. You will need to deploy the technical underpinnings of a continuous integration system, and move to a social structure that encourages your developers to build and run tests every day.

If you are doing long-cycle releases, you will probably stay with this pattern. You can add more teams with a "cadence" tactic, where every team releases on the same schedule.

Kanban and Continuous Delivery

If you need speed and responsiveness, you will want to take the next step to fully continuous delivery. You will be able to assemble releases whenever you want with a "take what is ready" approach. This helps you to build software faster and reduce stress at the same time. Small fixes will go through in hours or days, and big changes will take an appropriate amount of time.

You will use a Kanban technique to manage your development tasks. In the Kanban approach, you pull one task at a time to work on, and you use lean techniques to make sure that it gets finished as quickly as possible. You will need to be sure that you do all of the normal planning, architecture and design for that task, but you will do it as needed, unblocked by other parts of your schedule. You may need to change how you do product management.

You will use continuous delivery processes to test and deploy each code change. These may require innovations in automation and testing. You may find that you are giving developers more authority, adding new test pipelines, and changing the role of your QA team.

Scaling with services

With all of that unblocked planning and automated testing, you are ready to increase the size and diversity of your development team and your applications. You can accept contributions from partners, outsourcers and new enthusiasts. You can test the contributions, take what is ready, and assemble the releases that you want.

We will describe the "matrix of services" or "MAXOS" structure that the best tech companies use to scale the speed, size, and complexity of their software development and IT operations.

Here is a slide that shows the stages of the roadmap from the point of view of a team that starts with Scrum.

We will discuss these concepts in more depth in the next sections of this guide.