There are several ways to sequence development processes and deliverables and drastically increase the pace of delivering software.

How to sequence development tasks for maximum velocity

How do we imagine projects typically work

Looking at project methodologies and execution often leaves you with a very simplistic view of things are done. Typically you imagine projects to work something like this:

According to this model,

  1. You do a piece of work (e.g. Process 1), which produces an output (Deliverable 1).
  2. This Deliverable (1) is required to initiate Process 2.
  3. Process 2 cannot start until Deliverable 1 has been completed and “signed-off”.

There’s definitely merit in this approach. It provides an element of risk management – so you don’t go back and re-do work which was not agreed and understood by all parties involved. But in reality, there are many opportunities to execute projects in a more efficient way than this.

How to sequence work more efficiently

In reality, you can execute many tasks in parallel, and also – not all deliverables are needed for other processes. So you don’t always have to wait for all deliverables before kicking off the next project process.

The diagram above, although it may seem a little messy, demonstrates a very typical way to run processes in parallel. This will have a significant effect on the velocity of your delivery. It will also drive down the cost for your development project, as follows:

  1. The scoping process (requirements elicitation) would produce user requirements – typically expressed as user stories.
  2. While the requirements process is underway,
    • You can engage the development team, validate requirements, and explore the most efficient way to execute the work.
    • Thus, the development team can provide inputs directly into the requirements process.
  3. This avoids the typical back-and-forth between the requirements and technical design processes:
    1. When “business” signs off on their requirements they may get feedback from the development to improve the requirement execution
    2. In this scenario, the requirements process would need to be repeated, documentation updated, and once-again accepted.
    3. This is also, typically, where a lot of conflicts arise between the business and development teams.
  4. The requirements process will often flow into a User Experience Design process, which would produce Wireframes, followed by UI designs.
  5. However, it is not necessary to wait for the UI designs to be completed before completing the next process: technical designs. User Interface design has very little impact on technical design, there is no dependency, and no reason for this process to “hold up” that part of the work.
  6. The UI designs are important inputs for the Front-end development work-stream, which only kicks off once the technical design has been done.

Comparing the management overhead of different methodologies

In this example, a significant amount of time would have been saved towards executing the project. This affects you in many ways:

  1. When executing tasks in parallel, it reduces the overall development (elapsed) time, so it gives you a quicker time-to-market for your project
  2. Every project has a base “management overhead”:
    • The whole team has to attend daily standups, regular sprint planning and sprint review sessions.
    • You are not only saving the overall execution time of the project but avoiding all the project overhead that goes along with it.
    • The agile software development method, even with it’s relatively low management overhead, still presents a major waste of effort if you stretch projects out longer than they need to.
    • In a typical 2-week sprint, any individual theoretically has 80 productive hours available to them. The Agile methodology will require approximately 12.5% of that time for management overhead – and that is for the entire team, including business users.

The costs of context-switching

  1. Also, key resources remain engaged with the project, so there’s less context-switching going on – which also “costs” time and money. For example,
    • In the above example, the UX design team moves directly from requirements to UX design to UI design to Front-end development without any interruptions.
    • This improved “continuity” improves efficiency, but also information loss. You are much less likely to forget key concepts if you switch directly between tasks, rather than taking long breaks between projects
  2. When resources complete a piece of work, and there is a break where to do not work – they are assigned to another project. You may need to wait for those people to complete their current project until they can switch back to your project – so there’s even more lag time introduced into the process.


If you look at the two diagrams above, you will see how the costs compound on each other. Firstly, the cost of context switching expands the overall required timelines, and then you need to add the project management overhead to the top of that.

The risks of running processes in parallel

There are several risks with running processes in parallel, however, which could completely negate any potential savings. This needs to be carefully managed to avoid a continuous flow of re-work. Even though you do not need to complete all tasks to continue with the next process, some deliverables are absolutely necessary to continue. For example to start with wireframe designs before the requirements have been completed and accepted, actually increases your risk of wasting time.

Additionally, not all software development processes are always mandatory. In some instances, you can cut certain processes out completely – and further increase the velocity of delivery. To get the most value and efficiency out of the process, you need to have a fairly good grasp of how the overall software development process works, exactly what steps are dependent on what deliverables.