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:

http://www.agilecollab.com/iterative-and-incremental-is-not-equal-to-agile-key-aspects-of-agile

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:
http://www.dorlingkindersley-uk.co.uk/static/clipart/uk/dk/rock/image_rock004.jpg