Frank Carver's musings about software and life
I’ll say up front that I have some major issues with the idea of estimation in agile processes. There are plenty of alternatives to traditional time/manpower estimation which are at least as useful in delivering real, useful results.
However, if you are working in a context which values estimation, Adrian Wible has some interesting points about whether it is wise to re-estimate incomplete stories each iteration
Adrian’s Tech Blog: The case against iteration based re-estimation.
Stephan Schmidt writes
Agile is mostly driven driven by managment and consultants, seldom bottom up by developers.
I found this very odd, and completely contrary to my own experience. From the perspective of someone who first encountered agile approaches in the form of Extreme Programming the problem is almost always how to explain the obvious developer benefits in ways which management will understand.
This phrasing of agile for managers seems to be the purpose of Scrum. I tend to recommend that puzzled managers read up on Scrum, but puzzled developers start with XP and Test Driven Development, which provide some much more tangible developer advantages.
via Code Monkeyism: What Developers Need to Know About Agile.
In tough economic times with a lot of people out of work and employers cutting back on training budgets few can afford the kind of big-budget, fancy hotel courses which were the staple of corporate training even just a short while ago. So Tobias Mayer has started a no-frills way to get “certified scrum master” status and spread the agile/scrum way of working. He calls it WelfareCSM.
The cost is essentially $50 (to the Scrum Alliance for the certificate) plus a voluntary contribution to cover any room costs etc. Sort out your own food and transport. Even for those of us who regard agile certification as a dubious concept this is pretty tempting.
Reading between the lines, though. It appears that the different agile “camps” may be slipping into a battle for mind-share. If Scrum certification becomes more widely available and understood, then alternative approaches (particularly XP, but also all the other adapted, customized and home-brewed agile working practices) may seem to have less value to employers and clients.
Hmm…
A pleasantly witty yet insightful post about how different processes and methodologies can suffer similar problems, and how this relates to the individual learning journeys of practitioners.
We don’t use scrum as such, but we still face the issue of team-member absence during fixed iterations. It’s a tricky one to deal with, especially as absence comes in both predictable and unpredictable forms.
InfoQ has a nice summary of some of these issues and some solutions. There is till no “silver bullet” for this, though. Losing staff will almost always mean losing productivity, which in turn means that iteration (“sprint”) commitments will need to be renegotiated, which works best if stakeholders are informed as soon as possible.
We had a small discussion at work a few days ago about the difference between Scrum and Extreme Programming (XP).
My take on the distinction is that Scrum is essentially a management technique, while XP is essentially a development technique. They certainly have a lot of overlap, but the different emphasis leads to some different recommendations. There’s no “40 hour week” in Scrum, for example.
Jason Yip contends that Scrum stops where actual development work starts.
For interest, a while ago I reviewed both the original book on Scrum and a clutch of XP books for the Java Ranch “bunkhouse”.
Back to thinking about stories in the agile software development sense.
For the first time this iteration we have reached a situation where two stories were left incomplete at the end of the iteration. I could give a bunch of excuses about changing priorities during the iteration, but the point is that agile processes are supposed to be able to cope with this kind of stuff.
So now we are at the point of deciding what to do with these stories. Luckily, the guys at Elegant Code are also facing this problem, and discuss some options in a recent blog post.
Elegant Code » What to Do with Left Over Stories
In our case, the discussion is still proceeding. From an agile purity point of view the suggested approach of throwing the part-completed stories back into the pot for re-estimation, re-prioritisation, and re-scheduling is certainly compelling.
In my experience of doing software development for non-developers, risk is one of the most difficult things to deal with. It’s so easy and tempting for customers to think and plan in terms of the definite “I will have feature X by date Y”, that the risk of X not being available by Y gets quietly ignored. Any such failures come as a complete surprise, even when the details of feature X were not even known at the time an estimate was made.
Several development project management methodologies try to cope with this, and Scrum is probably the most well known. Here’s an InfoQ article about risk and scrum.
I have recently discovered a new blog to follow: “notes from a tool user”. The author, Mark Levison has plenty of opinions on agile software development.
Standout recent articles include: