One of the causes of death march project is poor story definition. Whether you call them stories, features, tasks, items or whatever, defining good stories is essential for success.
The ACID principle from database design applies to stories as well as databases. Atomicity, Consistency, Isolation and Durability. These principles apply to story design as much as they do to anything else.
It’s an interesting primer on Ruby on Rails, test driven development and agile development. It’s geared at undergrad computer science students and does a good job for that.
However, as an experienced professional, I was looking for many of the chapters that aren’t written yet. For example, the chapters on creating testable javascript and writing maintainable client side code were missing. In a nutshell, wait for the beta edition if you already know rails.
I thought that it was an interesting experiment in lean writing. The idea was to write just the chapters that you need now and see what the interest is in the other chapters. It will be fun to see what happens in future versions of the book.
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:
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.
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.
Scott's Thoughts 