Scrum Breakfast

Last week I wrote, "Story Points are not uncontroversial" and lo, and behold, not a week after I made the comment, I posted essentially the same arguments to the Scrum Development mailing list in response to question about how many man days are there in a story point. Dave Rooney of Mayford Technologies wrote back:
"I generally agree with Peter's points..., except that estimating any development effort in hours is a mistake, plain and simple. You are mistaking 'precision' with 'accuracy' in that case, and any estimation is bound to be incorrect.

"What you need to do is to measure the team's *actual* output, and feed that back into the measurements as the velocity. These measurements need to begin as soon as development starts, and need to be made continuously. That's the only way to introduce any accuracy into your estimates."I think there are two perspectives here.

On the one hand, I'm totally in agreement with Dave that estimatin…

Useful as they are, Story Points are not uncontroversial nor is this problem of creating a "reference kilogram" for code trivial.

One problem we had on the WLC project was that we had two fundamentally different kinds of work to estimate: HTML Publishing and Software Development. Although we had attempted to have one reference Story Point for everyone, this proved to be elusive. After a few Sprints, I noticed that we had much less effort per publishing Story Point than per development Story Point.

A second issue is that some stories are intellectually complex while others are just time consuming. If Story Points represent complexity, then a simple but repetitive task should get a low number. This is unsatisfying, because such a story will put a higher load on the team, just because it takes so much time.

A third issues was that some developers just did not like Story Points and insisted on estimating in days.

After we had some experience with Story Points, we had an empircal mea…

When I present Scrum to customers, I often hear, "yes but we do RUP, that's iterative, so it's Agile, right?"

I spent some time looking at "Project Management with Rational Unified Process" by Gerhard Vergsteen (in original German) and "Projektmanager", published by the German Society for Project Management. Two thoughts:
The RUP Book got to chapter 3 before it even mentioned people. Then it spent the rest of the book telling "Workers" how to do their jobs in very minute detail. (And yes, even within the iterations, the waterfall lives.) I looked for the word "Responsibility" (Verwantwortung) in the index of both books. I didn't find it.I just gave a presentation on Scrum to a group of potential customers in the public sector, one of whom believed quite strongly that good people make good product managers, regardless of the methodology. He's absolutely right on one point. People make projects succeed, not methodologies. A…

During the February Scrum Breakfast in Zurich, the question arised, "How do I explain Story Points to Management?" A good question, and in all honesty, developers can be an even more critical audience than managers.

Traditional estimates attempt to answer the question, "how long will it take to develop X?" I could ask you a similar question, "How long does it take to get the nearest train station?

The answer, measured in time, depends on two things, the distance and the speed. Depending on whether I plan to go by car, by foot, by bicycle or (my personal favorite for short distances) trottinette, the answer can vary dramatically. So it is with software development. The productivity of a developer can vary dramatically, both as a function of innate ability and whether the task at hand plays to his strong points, so the time to produce a piece of software can vary dramatically. But the complexity of the problem doesn't depend on the person solving it, just …

Done. This brings me to my own little pet project, the FingerSpell Flashcards.

I have a hobby. Sign Language. There is really no reason for me to have this hobby, but I have long been curious about using signs as a means of communication.

There are a lot of challenges in learning a sign language, one of which is the speed in which native speakers can sign — I suppose that's not that different from a learning a spoken language, actually.

The finger alphabet is not the same thing as the sign language. Sign languages are a much more efficient way of communicating ideas than simply spelling out words. The alphabet is still important and is used mostly for names and places, but also for words that don't have a dedicated or well-known sign.

Not finding a good tool for learning to finger spell, I wrote one. It was a double learning experience: I have gotten much better at finger spelling and I got to cut my teeth on AJAX. After showing it to colleagues in class, I was really motivated by…

A few weeks ago, jp pointed me to an interesting article about the various levels of done:
"A feature is not "done" until all of the following can be said about it:
"All unit tests are green.
The code is as simple as it can be.
It communicates clearly.
It compiles in the automated build from a clean checkout.
It has passed unit, functional, integration, stress, longevity, load, and resilience testing.
The customer has accepted the feature.
It is included in a release that has been branched in version control.
The feature's impact on capacity is well-understood.
Deployment instructions for the release are defined and do not include a 'point of no return'.
Rollback instructions for the release are defined and tested.
It has been deployed and verified.
It is generating revenue.

"Until all of these are true, the feature is just unfinished inventory."

At one level, the definition of done is one of the key parameters in the Sprint contract between Product Owner an…

The next Scrum Breakfast in Zurich is dedicated once again to a report on practical experience. We are fortunate to welcome one of the most experience Scrum Masters in Switzerland, Jiri Lundak, who will talk about
Scrum in the Public Sector: Practical Experiences
Two months ago a 4 year project development project came to a conclusion. Along the way, it transitioned from being a traditionally managed project to being a Scrum Project. His talk emphasizes the problems (and also the successes) of using Scrum in public sector projects.
Topics:
Hurdles a software company faces, when it decides to become agile
The challenge of staying agileLesson learned
Bio:
Jiri is the head of Software Development at Löwenfels Partner AG in Luzern. The company is specialized in developing software for the Swiss social security agencies.
With over 20 years of experience as a software engineer, architect, team leader and project leader, he has been working with agile software development since more than 9 years, …

Yesterday, Marcello Leonardi gave a talk about his experience as developer and Scrummaster in namics' WLC project. It was cool — 25 people, mostly experienced project managers. Some had just started with Scrum, a few had been using Scrum for awhile, and others were just thinking about starting. But all had interesting experiences to share.

Marcello talked about the WLC project. Marcello started as a developer about the time I took over the project, and took over as Scrummaster after about 8 months. On the one hand, I felt like a proud father, because I introduced Scrum to the project and after 22 Sprints, 3 major releases, and a Best of Swiss Web award, the project is still going strong.

On the other hand, after hearing Marcello's talk, I realized that the project is doing better now than when I ran it. Had I made wrong decisions? Left out something important? Could I have done a better job? Saturday, I wrote "Why would anybody want to be [confronted with their own weakness…

Just found this article about Scrum at Yahoo. Gabrielle Benefield, Yahoo's top coach in Agile practices describes the process, and how it speeds up Web application delivery:

Q: Why settle on Scrum?

Gabrielle Benefield: Scrum is great etiquette for an organization. What happens is that if you want something that's very lightweight that can make a huge impact quickly, and be really simple to implement in its simplest form, Scrum is the way to go. It's really successful when you add on the engineering practices, things like some of the extreme programming techniques where they do a lot of testing, where you continuously build your software--things that improve the quality a lot. So Scrum tends to focus on a lot of collaboration, getting the team working, getting prioritization clearly defined, and then you add the engineering practices. And there are things called Lean that came out of the local processes from companies like Toyota, when they manufacture cars--ways of ridding w…

Why does a company (or a team) decide to use Scrum? Adopting Scrum means implementing change, and fairly substantial changes to boot. It brings bad news to the surface and forces management, the team and everyone else to confront their own weaknesses and shortcomings on a monthly basis. Why would anybody want to do that?

There are obvious symptoms of projects being in trouble: Missed Deadlines, Cost Overruns, You haven't had a release in a year. Management or the customer is losing confidence in the project. Staff turnover. Threats and ultimatums. Escalations up the management chain. All are sure signs that things are not right.

But there are also subtler warning signs: "I have been asking for that feature for months!" "We need exact specifications." The project leader curses when her cell phone rings. These are early signs that communication is breaking down and worse problems could follow.

You adopt Scrum because you want a genuine improvement and you know that …