I was running a course on “facilitating workshops in agile projects” when some of the crew asked what different questions they could ask in retrospectives (instead of just “what worked and what didn’t).

We got talking about the retrospective at the end of a project.  So I published a story of sorts on how to run a retro for 70 people at the end of a project.

At the end of the discussion I promissed to publish some of my comments so I put them together in a short story about running a retrospective.  You can read it hear if you are interested:

http://www.theagiletribe.net/2010/11/04/unusual-questions-to-ask-at-a-retrospective/

I just posted an article on measuring quality and maintainablity.  But I am waiting for my tea to boil so I thought I would start a new article.

One of the things that often interests me is that teams feel like they need to cut corners this week to get their work done even though they know it will make life harder next week.

Everyone in the team would say that what they are doing and yet everyone feels like they have to do it. So why do they keep making life harder for themselves (or for the team inheriting what they do).

One theory is that people are evil and will therefore eagerly and knowlingly make the world a worse place. But I have an alternative theory – I think that people are focusing on the things we measure – the things that are top of mind.

So I think one of the causes of stress in the world is simply that people are measuring and focusing on the time it takes to complete each task in front of them, without having time to meausre (or focus on) taking the time to make things better for the team next week.

As a partial antidote to this problem, I propose that we apply an easy measure of the impact we are having on the future ability of our team (and others) to support the work we are doing this week.

In IT teams there are ways of doing this – using measures such as code complexity and function points for example.  But they can be hard and I am lazy.  They also focus on the code and not the data, the overall design or the process changes we are making.

Another approach is to create and update a system (or process) heat map. But on top of this, we can also predict the impact we are having by simply asking the team what they think will happen with the work they are doing.

I will post a couple of ways of doing this – but more importantly, why not just do it?  Next time your are in a team meeting, implementation planning session or restrospective, just ask the crew

• Whether what they are doing this week is making life easier for themselves and others next week; and
• What they would do about it if it was up to them.

I bet they can answer both questions quite clearly … and I bet life would get better if they (and you) acted on the answers.