May 2007

The Archives

Uncategorized
Scrummerfall
05.26.07 | Permalink | 45 Comments
I’m the middle of a Scrummerfall (http://www.agileprogrammer.com/dotnetguy/archive/2006/07/08/16855.aspx)

Euphamisticlly defined by Brad Wilson:
Scrummerfall. n. The practice of combining Scrum and Waterfall so as to ensure failure at a much faster rate than you had with Waterfall alone.

Perhaps this:
Scrummerfall. n. The practice of combining the meetings of Scrum with a Waterfall process. This ensures that the team doesn’t have to change the way they work while adopting Scrum.

Right now I’m at the tail-end of a project with a first-time Scrum team. Here is where we’re at.

100% Code Complete!

I still have no idea what the phrase “code complete” means (other than the title of a great book by Steve McConnell). Making this declaration with 35 bugs open is meaningless. The team front-loaded all feature development, postponed testing and deferred bug fixing. We’re still finding bugs.

Here are some symptoms to this approach
- Broken window syndrome: Developers come across bugs (while doing other bug fixing) which they dismiss. “yea, it’s not supposed to work in FireFox yet.”
- Increased project risk: The team explicitly scheduled 6 weeks of bug fixing time. No portion of the system is in a working state when “Code Complete” was declared. It’s unclear how much work is remaining to gauge if the system will be in a shippable state by the deadline.
- Time wasted on integration. To hit the “Code Complete” deadline, merging with other branches was deferred for two months. Several days have been spent just doing the merge. Bugs related to the merge continue to fall out.
- Other teams have to use our buggy system for full end-to-end testing.
  People actually like the bug triage process. For some strange reason, folks are finding comfort in seeing a big number get chipped away at over the course of several weeks. It’s not seen as wasted time.
- Low Quality, Little Automation
I believe a core Agile principle is to deliver a high-quality system at frequent intervals. When a team is doing the Scrummerfall there is no pressure on keeping a system healthy. Why invest in automated tests and automated deployments when there are two (or three) Sprints at the end dedicated to testing and bug fixing?
If a team is delivering a high-quality product at frequent intervals, it’s because some investment has been made to ensure that the quality always remains high. Usually, that means testing the system all the time. Testing is painful. When all the features in the system are verified by hand each iteration (”yup it still works”) someone eventually says “enough is enough” and begins automating tests. In the Scrummerfall there is no pressure to have a high-quality system at frequent intervals. Deployment, testing and bug fixing are deferred to the end. The pain doesn’t happen frequently enough for someone to try to fix it.
Mike Cohn likes to say, “The deadline [of the Sprint] is sacred.” I like to say, potentially shippable is sacred.
Uncategorized
Satisfying the need for perfection
05.11.07 | Permalink | 12 Comments

Kent Beck mentioned something in his book about a programmer who made elaborate iron pieces to satisfy his need for perfection - because he couldn’t find it on his team. I have seen others who work on open source or outside projects to get that need out of their system.

On truly excellent teams, I haven’t felt compelled to pursue outside programming activities. And now that I think about it, those folks haven’t felt that pull either.

When they did feel the pull, they would build something for the team. Sometimes someone would work on making the development environment better. Everyone was grateful for making their work lives better. Other times, some sub-system was slow, but not slow enough to justify the effort improving it. Someone would tackle that tricky problem - for fun - in their spare time.

When I am involved with difficult teams, my level of outside work increases. I’ll start hacking, writing, or get obsessive about something else. I need a ‘fix’ of getting something accomplished.
Uncategorized
Some teams thrive on the test and fix cycle
05.11.07 | Permalink |
Even if they won’t admit it, it seems like some teams like the test & fix cycle of a project

Programmers:
- They like the immediate positive feedback that they get from the team when they fix a bug.
- For some programmers these tricky obscure problems are fun. They love tracing through the code, poking at the database to find the problem.
- It gives them the sense of accomplishment when they can find and fix issues. They get a pat on the back when they crank-out 20 bug fixes in a day. They don’t get a pat on the back when the feature was implemented.
Project Managers:
- There are finally concrete numbers on the project. (87% test coverage, 62% pass, 38 bugs…) Those numbers can be tracked, charted and a prediction can be made on when the project will be ready to launch.
QA:
- This is their show. They get a chance to drive development efforts. There have been pent up frustrations over the past few months, with
- They are proud of the number of bugs they find.