Skip to main content

Agile or Iterative and Incremental

Mike Cottmeyer Chief Executive Officer
Reading: Agile or Iterative and Incremental

Many companies want the benefits of agile but are not ready to make the organizational changes necessary to take full advantage of the methodology. Companies want to say they are agile… they want to derive the benefits of agile… but they are not fundamentally ready to do the heavy lifting required to really make it work. People want to hold onto predictive planning. They want to hold on to functional silos. They want to hold onto matrixed teams. People want to keep their specializations and spread their time over multiple concurrent projects.

What does a concept like velocity mean in such an environment? What about empowered teams? When I talk about iteration planning, daily meetings, and retrospectives; people can’t comprehend how they will do this with every project they are working on. They fear they will spend all their time in meetings, and you know what… they are right. Agile assumes team. It assumes you are part of a cohesive whole that plans together, works together, and delivers together. Agile trades the big up front design, heavy documentation, and predictive planning for collocation, teamwork, and collaboration.

You can’t collocate, work as a team, and collaborate when you spread across so many projects. You can’t stop doing heavy project documentation if you aren’t willing to replace it with high bandwidth communication between team members. To get that level of communication and collaboration, people need to be in the same room, they need to know each other, and they need to work together on a daily basis. People need to be part of a real team; not a collection of loosely coupled individuals.

The bottom line is this… you won’t get the speed and adaptability you are looking for unless you are willing to make the tough organizational changes that allow this to happen.

You can still get some mileage from delivering software in two or four week cycles, daily interactions between project members, and frequent project reviews. You can make use of loosely coupled requirements, prioritized backlogs, and rolling wave planning. There is value in understanding the definition of done and making sure that once you’ve delivered, you have really delivered. Managers can do product planning, release planning, and iteration planning without being particularly agile.

Even though you won’t get the speed and adaptability of an agile team, you can still derive some benefits from iterative and incremental delivery. Just keep in mind that while agile prescribes iterative and incremental delivery, not all iterative and incremental delivery is agile. Agile adds all the aspects of team, collaboration, empowerment, inspection and adaptation. For a good article on the difference between incremental and iterative vs. agile, take a look at the following post I found on the AgileCollab blog:

For a siloed waterfall team, this might be a good first step. It would definitely move the needle toward becoming agile.

What get’s confusing is when we equate iterative and incremental with agile. Agile is incremental and iterative but it is also a value system… a way of structuring teams… a way of treating individuals. Agile is an approach to engineering products, a technique for managing projects, and philosophy for leading organizations.

It is valuable for leaders to know how to define what their teams are doing. It is valuable for teams to understand where they are in comparison to where they want to be. We can take baby steps towards greater organizational and project agility by implementing some of the practices. If we declare victory before we’ve done the hard work, we risk never meeting our goals and diluting what it means to be an agile organization.

We should acknowledge where we are, understand where we want to be, and ask ourselves if we are really willing to make the changes required to get there.

Image Source:

Next Delivering a Great Presentation

Comments (4)

  1. Kevin E. Schlabach

    I totally agree that iterative or incremental does not equal agile… and I also agree that companies can benefit from iterative or incremental approaches in advance of figuring out how to fully go agile.

  2. Mike Cottmeyer

    This ‘realization’ is going to influence how I teach and coach. I go on client sites and start teaching ‘agile’ when people are not really operating in ‘agile’ environments. My intent is to focus in iterative and incremental and then let them know what kind of changes it will take to be ‘agile’ Thanks again for the reply.

  3. rfleming

    Great insight. I think it’s not only valuable for leaders to know how to define what their team are doing, but they must make the effort to define the plan. If the leaders don’t have the expertise to define the plan, then they need to seek training or outside help.

  4. Mike Cottmeyer

    Thanks rfleming. Knowing what you intend to achieve is powerful. Knowing how you are going to get there is powerful. Knowing how far you’ve got let to go is powerful.

    Putting the agile label on a team that isn’t there yet can be pretty damaging.

    I am not knocking anyone or proposing agile litmus tests. Let’s just get real about what we want to achieve and what it will take to get there!


Leave a comment

Your email address will not be published. Required fields are marked *