Use the river diagram to communicate data

I run a lot of workshops, including planning workshops and retrospectives.  Sometimes the crew votes on things like “what is the best feature, or how did we go this time.”

But sometimes we collect data and then want to discuss it as a team.  And this presents a challenge – I like data in a spreadsheet and I like pictures on the wall but sometimes it seems hard to capture numbers in a useful way in the workshop.

But do not fear – the River Diagram is here and this is exactly what it is for.

river1

Continue reading “Use the river diagram to communicate data”

Advertisements

Manual regression testing may not suck so badly after all

I often work with good developers and one thing I notice about all good developers is that they seem to love the idea of building robots.

Bad developers see problems and sit there waiting for someone to come up with a solution in enough detail for the developer to transcribe the solution into code, much like an old fashioned typist takes dictation and types it onto a page.
So if a bad developer noticed that their house needed cleaning, then he or she would simply complain that someone should clean it. Then if you point out that it is their house that needs cleaning then they will either claim management won’t let them clean or that the problem is more complex than it seems cannot be solved.

In fact even if you ask them to try and clean, they will just start to reveal that cleaning is “more than vacuuming” and could involve the removal of micro-particles that only quantum physicists could possible manipulate. Indeed, they will contend, it is unlikely that anyone really cleans their house and the only practical solution would be to upgrade to a new cleaner house.

But good developers are different. A good developer will notice that the house needs cleaning, work out that actually cleaning it less fun than designing a better way to clean houses and immediately begin working on the design for a new robot.
Continue reading “Manual regression testing may not suck so badly after all”

A daily status meeting? Really? Now you want daily performance measures? Really?

I run agile training courses and I often preach the benefit of a daily standup.  The idea is that it is 15 minutes a day where everyone in the team lists

  • What they have done since last time
  • What they will do today
  • What obstacle or issue is in their way

It works really well in my slides but now I am trapped in the real world temporarilly working on a real project. Do I really want a daily meeting?

Continue reading “A daily status meeting? Really? Now you want daily performance measures? Really?”

Measuring the impact on production support

I was running a course in agile development when I mentioned that one of the good things about agile is being able go live with something valuable sooner.

One of the class asked whether you can measure the benefit of going live sooner.  “Of course,” I replied, “and of course you should be doing so”.

Some of the group asked if we measured value in features deployed or some other way. So we had a good discussion around measuring value.

But then one of the group told us that his project was about “simplifying IT” and so his agile project manager had told her that, since the project was not adding any value to “the business” the only real measure of success was whether they deployed the features they were supposed to deploy.

But this seemed a bit silly. So we agreed that adding value to IT was in fact adding value to the business, since IT is part of the business.

Continue reading “Measuring the impact on production support”

Agile governance and the problem with measuring self-organising teams

I have been in some interesting conversations recently about agile development teams and sound organisational governance. 

One of the challenges faced by organisations is that the traditional measures used to monitor and control teams are not necessarily suited to the style and approach of agile teams, while agile approaches may seem to remain silent on, or even discourage, the outside governance of project teams.

imageimage

Fortunately this is not a new problem and people have been discussing it since self-organising teams (or work cells, or self-managed teams) first appeared in management theory.

Continue reading “Agile governance and the problem with measuring self-organising teams”

Talking about retrospectives on another blog

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/