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.
Continue reading “Use the river diagram to communicate data”
A value stream is a “Lean Manufacturing” tool.
It is a way to identify where customers experience value and where we consume value to provide our product or service.
The approach is quite simple.
Continue reading “Using value stream maps”
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”
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?”
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”
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.
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”
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 … Continue reading Talking about retrospectives on another blog
One of tha participants from a course asked for some more information on estimating – so here is a downloadable copy of my mimi-ebook with some rough notes on estimating. Most of the material also appears in this blog somewhere and I have since updated some of my thinking (as I am continuing to do). So it would be great to get suggestions/challenges or comments for me to use in the future. Estimation toolkit – June 2010 v1.0 Continue reading Some downloadable notes on estimating
I was reading Daniel Pink’s book “Drive” and I came across a passage about predicting which teams are likely to be successful. It describes a guy who counts the number of times he hears people use the word “we” and the number of the times they used the word “they” when referring to their own company. Apparently the “they” teams are likely to fail and the “we” teams are generally successful. This made sense to me because when I have always listened when managers use the terms “we”, “you” and “I”. The dodgy managers I have worked for tend to use pronouns like … Continue reading Unusual predictors of team success
I was having a debate with a friend of mine recently. He said that all measures should be “SMART”. The term is usually used for goals and says that the goal should be specific, measurable, achievable, relevant and timely (or something similar). The problem I pointed out was that the M in SMART means measurable so the concept of SMART measures is a bit redundant. He responded that in his experience many of the “measures” he saw in place were not actually being measured and so, he claimed, it would be good to remind people to actually have measures that they will measure. I am … Continue reading Should measures be “SMART”?