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
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 interested:
http://www.theagiletribe.net/2010/11/04/unusual-questions-to-ask-at-a-retrospective/
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.
