Agile teams poised for success

1 11 2006

I wrote before about agile projects.

Big topic. Plenty of far more authoritative material around than I could ever write about.

But what I take from it, which is often what I write about is the behaviour of it, in various applications.

Here’s a different application for you.

Teams can be agile too.

Teams in my experience, irrespective of size, get too often caught up in over engineering processes.

Who’s heard this one?

“I need our team to be able to have redundancy built in should people leave. Therefore, we need all our processes documented and stored”.

I see from that exercise little else except pain and suffering, and a massive overhead in administration.

Now, the key point here is that I actually support documenting processes. As a manager, you need to have redundancy built into your tactics catalogue, because your team won’t always be there. Hell YOU may not always be there!

In the past, I actually wrote up some processes which had the following things:
– title
– scope statement
– change control panel
– authorisation blocks
– impacts
– external factors
– technology requirements
– implementation specifications
– background statements
– and so on.

Now, for major procedures this level of depth and rigor may have been appropriate, or for major teams (call centres and the like, where it would be warranted to handle procedures this way).

For the majority of teams though, where turn over is less of an issue, and where cultural learning and procedures may be more effective, I’d suggest the following:

Engineer less, record more:
Is there something wrong with giving the process a simple name, drawing a simple diagram with some words on it, and then saving it to your group drive / web space / something?

“oh but it looks bad!”

I don’t care. Process mapped, saved and available. less than 1 hour. Low cost. cheap to re-do. Easy to read, easy to edit.

Over-engineering is a great way to make something look really great, but make it utterly ineffective.

This thinking can be applied to many facets of a teams operation. Not just how the procedures are written.

Think about applying the less is more concept to specifications. How about to communications? Reporting? something else?

I guess the underlying thing here is you don’t ALWAYS have to have everything looking great and perfecto. Look at my posts! they are unstructured and would make most editors gag and choke then email it to their mates to have a bit of a chortle.

I get the last laugh, I can write quickly, change things quickly, meet needs and be timely. And my approval process doesn’t infuriate me with endless refinements and changes.

Some might call it wishy washy. I call it agile and lightweight. It lets me get more done.

I’ve found that responsiveness of myself and my team is valued more than having elegant procedural files.

By the same token, I have to be responsible and engineer when its needed, and draw when its not.

When I’m in doubt I always fall back on old reliable.

What’s actually needed by my end users?