Archives for category: Agile

I got asked recently about the role of architecture in agile development. Basically, the question boils down to some variation of “Is there a place for architecture in agile development?” This is a common and mostly misunderstood question. It seems like it gets asked on every project. It’s based on a faulty assumption: that architecture is something that is stand alone, that can be bolted on to a project.

To talk about agile architecture, you first need to understand what architecture is. Once you know what architecture is, and what it isn’t, the question changes to “How can you do good architecture in agile development?”

Read the rest of this entry »

I'M LATEI’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 »

One of the arguments that I see a lot in favor of Test Driven Development is that it helps deliver higher quality software more quickly. The more I projects I take part in or observe, I realize that this is only half true, and less than half true for Agile projects. I’m not saying that TDD has no place in Agile projects, just that it has a very specific place and time.

Read the rest of this entry »

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.

Read the rest of this entry »

Engineering Long-Lasting Software: An Agile Approach Using SaaS and Cloud Computing, Alpha Edition

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:

  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 »