Less formal, more rigorous

In conversation with our head of audit, I was explaining how our agile methodology is actually a lot more rigorous than old-school project management. We are also less formal. The two are hard to distinguish at first. Let me give a couple of examples.

We are more rigorous. If we start to move our timeboxes around, our whole paradigm falls apart. If we unexpectedly discover that a feature is going to take too long to test, we push it to the next iteration instead of moving the iteration end date out. If we don’t do this, we need to re-write the release plan, re-estimate tasks, re-do resource plans and (where I work at least) replan priorities for other projects, as well as generating the same set of documentation for these other projects. This is all waste work: work that does not bring us closer to client-valued features deployed and working in production. It’s also typically the thin end of the wedge: pretty soon our teams spend more time on documentation that on getting value-adding software working flawlessly in production.

We are less formal because all documents that we use are supportive not directive. I don’t demand people use a certain Excel template for a release plan. Thinking about certain attributes for each feature and for each iteration add value in our experience, and in teams that are starting up I strongly recommend (and yes, even enforce) this. But I don’t really care how our teams record this information. I have been down the path of only checking that everyone is using the same Word template or Excel sheet and mistaking that for real value — and I won’t be going down that path again.

Technorati Tags: , , , , ,


3 Responses to “Less formal, more rigorous”

  1. Nuno Says:

    I recall everything single bit of this. Still the measure of the “being rigorous” piece is somehow tricky.

    Why shouldn’t we try finding out find a model to deal with unexpectancies instead?
    The thing is that if you by some cosmic accident find too much unexpectancies along the way your iteration plan will become a baby monster.


  2. Dealing with unexpectancies « Professional Management Says:

    […] with unexpectancies Nuno writes that “Why shouldn’t we try finding out find a model to deal with unexpectancies instead? The […]

  3. robinallenson Says:


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: