Do you build software for clients, or for internal IT customers? Speed those projects up with continuous agile. Here are tactics that we use to remove barriers to starting a project, release faster, and get value and profits earlier.

Continuous delivery is now the standard practice for small, design focused projects that produce Web sites, Web apps, and mobile apps. It's great for situations where you need to design and refine a user experience. It's also good for situations where you want to improve the product by learning from data on usage and user engagement. You can show the product, get feedback, and respond with improvements on a fast cycle. When you launch a continuous project, strengthen it by focusing on user experience design and online usage data. It is an opportunity to truly do product design, rather than just implementation.

Negotiating

Get started as soon as possible. Most development projects have a surprisingly long "fuzzy front end." If you can reduce this planning time, your customer will get value faster, and you will get paid faster.

Never do anything with a fixed scope, meaning a fixed, predefined set of deliverables or specification. You will gain two advantages

1) You will have room for improvement. A continuous project should be discovering and improving the end product during the development phase.

2) You will start earlier. It takes a long time to negotiate a fixed price, fixed scope agreement. A lot of things need to be specified and estimated. If you just get started, you might find that you finish a big chunk of work in the time that was previously required for planning.

Negotiating a budget will be challenging if the buyer wants a fixed scope for a fixed price. However, you can promise something almost as good. You can promise a fixed price and a fixed TIME. The continuous process gives you a much higher probability of delivering in a fixed time than other approaches. And, staying in the fixed time box protects your margins, because your costs are controlled by the amount of time that you spend.

You should bill for your level of effort - a specific price in each week, for a specific team size in each week. The customer can cancel after any week. You should get paid for each week of effort, and you should show your work each week.

You can promise a simple guaranteed deliverable, plus as much extra stuff as you can fit into the fixed time.

Staffing

You should accelerate your project by using all available resources. You want to engage the client with real time collaboration and response. Include your own team, anyone at the client that has useful skills and knowledge, and then grab any contractors or outsourcers that you think you can use. We call this a "blended team." I like to take over as the boss and drive this process.

Overstaff the kickoff. It's true that adding ignorant people to a software project is a hassle, and it can slow you down. However, that is only true later in the project. At the beginning of the project, everyone is ignorant. So, it doesn't slow you down to have more people. You can remove the extra people as soon as you identify the core team. However, you will have a reservoir of people that understand the project if you need them later. This is a trick that engineers don't like (because it lowers efficiency), but outsourcers understand, because it makes project delivery more reliable.

Launching

Start with builds, not designs. You want to do complete deploys or releases of all components, as early as possible. This will be faster and more efficient than a waterfall-style approach where you first do a mockup and other design work, and then build and release components sequentially.

For example, we recently worked on a SaaS delivery project that required three major technology components: 1) A new portal application to register users and create SaaS instances for them; 2) a cluster to manage the underlying single-tenant applications; 3) a proxy server to send traffic to the correct instance of the application and handle failover.

In an old-style development project, we would first design the portal and make sure that we liked the UI. Then we would build the underlying components and attach them to the portal. In this continuous development project, we proceeded in this order:

1. Set up code repositories, development environments, and build scripts for each component. The UI mockup makes up a fourth component of this system.
2. Set up a staging server containing all of the components, with no functionality. Essentially each component is just a "hello world" build. Start automated releases.
3. Wire the pieces together to create functionality. This happens in parallel with the UI design.

This build-first approach makes projects easier to manage by sharing your work. Instead of working to an abstract plan, you move quickly to requests and responses. It also motivates the developer of each component, since they know their work will be shown. And, it prevents a buildup of problems and stress at the end of the project. You will be constantly deploying the system, and the first production release will be a well-practiced non-event.

Working Together

Let the client control the sorting of the backlog. Make them feel like they are in control of the priorities. Let them add to the backlog at any time. They will find this interaction very satisfying. As they see you respond, they may become eager to learn how to submit requests that are more clear and actionable.

Your implementation team will control the flow of items from the top of the backlog into the WIP area. Your tech lead should select items when the team is ready to work on them. Keep this power for your implementation team. You will have a happy client, and a happy team.

Set up direct communication between your implementation team members, and client team members. If you resist the urge to control communication and presentation, you will get higher efficiency and a stickier set of relationships.

Remove meetings as soon as you don't need them. At the beginning of the project you will want daily standup chats to keep your team on track, and weekly reporting to speak with the client. Reduce these meetings as soon as you can get communication and responses flowing between the teams in real time. You can remove the daily standup chat and replace it with a daily written report and an all-day chat. You can reduce the number of people on a weekly call with the client to as few as two. You reduce the need for meetings if all of the work is easy to see, release status is easy to see, and team members on both sides are communicating freely and responding promptly. Any activity or meeting that you don't do is a 100% productivity gain.

Pull work forward. If there is a question about whether to work on something today, or wait until the system is more stable, do it today. You will find and fix problems more quickly. If you are under time pressure, you should be close to feature complete after half the elapsed time of the project. You will need the other half of the time to make a quality product. Cut your deliverable to meet this rule.

Operating

Measure and monitor. You should be the expert in measuring and monitoring developer productivity, releases, usage, and user feedback. These tools will help you get the most out of your continuous development process.

Measure everything in the released software. Good monitoring will allow you to release more frequently, by giving you the confidence that you can see problems and correct them or roll them back.

Here are some charts showing the launch of the project described above. We used all of the tactics. We were running builds from week two, and we did a public release in week seven. Velocity increased steadily. The Cumulative Flow Diagram shows that we controlled the amount of work in progress, and finished each task rapidly. The stair-step pattern shows that the client had a tendency to test and close tickets on a weekly cycle. However, by the end of the project we squeezed WIP and stabilized.