Iterative development process works well for software development in general. Using a process like Scrum can however cause some problems with a high productivity platform like Drupal. With Drupal you already have a working product very early in the process, you tweak the details and in the end have an improved version. With Drupal features are cheap and details are expensive.

We like to experiment with our process and to improve it. With a company full of agile experts, trainers and coaches there are plenty of discussions around the topic. One of the recent ones has been on moving from just one definition of done to having one for each iteration of a feature. This should give us better visibility for progress and provide earlier decision points for the customer.

Why do we need this?

1. Make sure we don't do what the customer asks but what the customer needs. It's our job to meet the business need of a customer, we should be able to offer alternative solutions to the customer instead of just going for the most obvious or the "Drupal standard" one.
2. Keep better control over the project budget. We are good at delivering the highest priority items first, but not always great at knowing what's good enough. This approach will move the work to the next story before the previous story is implemented perfectly. The goal is to add more clarity on when good is better than perfect.
3. Help the team members work together in a more effective way. When we work on different stages of multiple stories simultaneously it's easy to lose track of progress. Having a clear process should help us not to do important steps too late and keep the communication simpler.
4. Allow customers more time to react on the primary decisions by pushing detailed decisions to later in the project. When the customer knows what level of detail we are dealing with they should have easier time on deciding how much time they should use on it.

In the end of the day most of our customers just care about getting the job done in the most efficient way possible. It’s not so much about technology, design or methodology to get there, it’s much more about the results.

How should we do it?

By combining iterative and incremental process into what I call development waves. It's nothing radically new, just combining many things we already do into a process and documenting it.

The basic idea is to approach a project with increments and iterations. Increments will add functionality and iterations will improve functionality. Instead of trying to get a story done-done in a sprint we will have different definitions of done for different iteration tasks. This is intended to help us find better ways of meeting the why of a story, keep the project moving forward faster and allow more innovation during the project.

The cooperation between team members should also improve with each story being split always to similar tasks based on iterations. We can also use the same methodology for epic stories and tasks.

Sprints move through increments and iterations of them in waves. In some cases multiple iterations will be done in a sprint, in some just one. Instead of working to reach the definition of done for a full story the team works to reach definition of done for each iteration of a story. This removes a lot of the extra overhead needed for quality assurance while we are still not 100% sure what the final implementation will look like. When the PO changes her mind or the team figures out a better way of delivering the story less work is wasted.

To help balance the workload of team members stories are not in sync for their iteration level. One story in a sprint may only have concept level work done on it, another user experience design and third MVP implementation. This will replace the sprint scouting we do today and make the communication around it easier. It should also make progress more visible and estimation of tasks easier when every story is always split to iteration tasks.

The goal for any project should not be to complete 100% of the backlog. Usually if that happens time has already been wasted on low value items and the same time would be better spent on either improving the quality of higher value stories or coming up with new ideas.

When a release of a project is done we have always completed the most valuable stories for that release and also done some scouting for the future. There may be some time wasted with getting started on stories that will not be implemented, but on the other hand we should be able to make incredible savings on other stories by coming up with more effective ways of implementing them.

Image credit: Henrik Kniberg, What is Scrum

The approach is to build something visible and useful as early as possible. This is true both for iterations and increments. Everything we build should immediately have some value to it and we should be able to explain that value to the customer at any point.

In the next post I'll define different iterations and how to do them.