I’m late! I’m late!  My whole project is late!

Can an agile project be late? What does it mean for an agile project to be late? There are really two different kinds of lateness for agile projects.  First, there’s the kind that everyone thinks of “this project will take 8 sprints instead of 6 so release it”.  Then there’s the more insidious kind, “these stories got started but not completed in the sprint”.

Read the rest of this entry »

Fixed time, fixed price development is really about managing the project across sprints to make sure that you hit the finish line at the right time. Except in the most trivial projects that can be done in a single sprint, this will involve coordinating and planning across multiple sprints until the release date.

That pretty much makes the strategic planning aspect of managing the project the most important part.  It seems like most of the time the planning runs into issues it comes down to a choice between two excuses:

1. It’s taking us longer than we thought. (bad velocity tracking)
2. We need to add this other thing before we can move on. (scope management)

Read the rest of this entry »

The interesting thing about doing fixed time, fixed price agile development is that it’s just agile development turned out to 11. All the same practices that you should do when doing any flavor agile, but usually don’t are critical to working fixed price. Probably the key practices to follow are: tracking velocity, scope management and multi-sprint strategic planning.

Scope management is the second most important part of doing successful fixed time fixed price development, or any development for that matter. Scope is essentially the “definition of done” for the business process.

The definition of done for a task is defined by the team as incorporating certain things: unit tests, integration tests, documentation or whatever. When all the criteria for “Done” are met, the task is done. Scope is the same sort of thing, just for the entire project. When all the things that are in scope are done, the project is done.

Read the rest of this entry »

I always wonder when I see another article about how it’s impossible to do Agile software development on a fixed time/fixed price basis. Especially because I’ve spent 75% of my career doing exactly that. The thing that really gets me is when people write that the only way to do accurate estimation is to have complete and detailed requirements up front. As if having 400 pages of cut and paste business speak to adhere to is going to magically solve the problem.

The interesting thing about doing fixed time, fixed price agile development is that it’s just agile development turned out to 11. All the same practices that you should do when doing any flavor agile, but usually don’t are critical to working fixed price. Probably the key practices to follow are: tracking velocity, scope management and multi-sprint strategic planning.

I realized after starting this that this is a big topic and should get split into multiple parts. So here’s the most important, or at least first part.

Read the rest of this entry »