Four Principles for Designing Your New Agile Project

Each team transitioning to agile is unique. Each project is unique. Each organizational context is unique. Why would you take an off-the-shelf solution that does not fit your context?

There are, however, guidelines for those transitioning to agile. The first is to know how your product releases, starting with the end in mind. There are more than just two kinds of products: those that release continuously, as in software as a service, and those that release infrequently, such as hardware. There’s a continuum of release frequency.

The expense of release will change your business decision about when to release your product. You want to separate the business decision from making your software releaseable. If you release continuously, you can pair your releases to your iterations or your features if you want. Your project portfolio decisions are easier to make, and they can occur as often as you want, as long as you get to done every feature or iteration.

The more infrequently you release, the more you need to separate the business decision of releasing from finishing features or iterations. It's more important to be able to get to done on a regular basis because you often have money tied up in long-lead item expenses. You have to make decisions early for committing to hardware or nonrecurring engineering expenses.

Next, evaluate how complex your product is by looking at the Cynefin model and seeing where you fall. It's important to understand what you are dealing with in order to formulate a plan.

For those who want to transition to agile, who are collocated, and who have more knowns than unknowns for their product, the four principles are:

1. Separate the business decision for product release from the software being releaseable all the time. Whatever you have for a product, you want the software to be releaseable.
2. Understand what kind of a product you have. The more infrequently you release products, the more you need a program, and the more you need a kanban board to see where everything is in your organization.
3. Make sure your batch size is as small as you can make it. The smaller your features, the more you will see your throughput. The shorter your iteration, the more feedback you will obtain from your product owner and the business. You want the feedback so you can learn and your management can manage the project portfolio.
4. Use the engineering practices. If you do not keep your stories small so that you can develop automated unit tests and system tests, use continuous integration, swarm around stories or pair, and use the Extreme Programming practices in general, you will not have the safety net that agile provides you to practice at a sustainable pace.

If you have technical debt, start to pay it down a little at a time as you implement features. Or, decide that you need a project to prevent the cost of delay for release. No one is asking you to estimate without providing your own safety net—do not do so.