Saturday, November 06, 2010

XP, Scrum, Lean, and QA

Before I do this, two things up front: for one thing, I am a crappy programmer. I read code far better than I write it, and I read non-OO code better than I read OO code. Also, I am writing as someone who knows a lot about Quality Assurance and testing, and very little about the hands-on day-to-day work of modern programming. So here goes:

As a QA guy, I know this: long before Scrum and XP and the Agile Manifesto, people working in Computer Science and software development knew three things about software quality: having an institutional process for code review always improves software quality; having automated unit tests (for some value of "unit") with code coverage improves software quality; and having frequent, fast builds in a useful feedback loop improves software quality. Sorry, I don't have references handy, I read most of this stuff about a decade ago. Maybe some heavy CS people could leave references in the comments.

The XP practices simply institutionalize those three well-known practices, and for the time, dialed them up to 11. Pair programming is just a very efficient way to accomplish code review. TDD is just a very efficient way to accomplish unit test coverage. CI is just a very efficient way to get a fast feedback loop for the build.

There is nothing magical about these practices, and I have worked on agile teams that don't do pair programming but do awesome code review. I have worked on agile teams whose microtest suite runs heavily to integration tests instead of traditional unit tests. I have worked on agile teams with a dedicated build guy. I started my career working in an incredibly well-designed COBOL code base. No objects in sight. Had I known then what I know now about test automation, I could have written an awesome unit/integration test framework for that system. The XP practices themselves are not sacred. The principles behind those practices are.

But the XP practices themselves are just a small piece of having a successful agile team. In musical terms, these are the equivalent of knowing scales and chords, just basic technical practices necessary to get along in the business. Of course they are not necessary: The Ramones and Tom Petty have only a basic grasp of the technical aspects of music, but they cranked out some monster hits. Put any of those guys in a jazz jam session or a symphony orchestra and they would be completely lost. There is some nasty software out in the world that makes a lot of money.

I like Scrum, for a number of reasons. For one thing, it has an aesthetic appeal. The concepts of developing, then releasing, then retrospective speaks to me strongly, not least because they map closely to the ideas from the performing arts of practice, perform, rehearse.

I also like Scrum because of its emphasis on human interaction rather than institutional process. Scrum is lightweight by design, and leaves much room for people to act as people with other people. Scrum favors mature, intelligent adults.

Finally, I like Scrum because it is a process derived directly from the actual practice of creating software. It is described in plain English and it relies on no special concepts. It was crafted out of whole cloth by good developers in a tough spot.

I dislike Lean/kanban for the same reasons. As a mature adult, I resent having any of my activities identified as "waste". I resent not having the end of an iteration to celebrate. I resent being treated as a station in a production chain.

Unlike Scrum, the Lean principles were not derived from the actual work of software development. They came from automobile manufacturing, and were overlaid on software development in what I consider to be a poor fit. Putting on my QA hat again, there are two other popular software development methodologies that came directly from manufacturing, and the state of those methodologies is instructive. One of them is ISO9000. The fatal flaw of ISO9000 is that once a process is in place, it becomes very difficult and expensive to change that process. This is fine in manufacturing, but it is death to a reasonable software development process. The other methodology from manufacturing is Six Sigma. Six Sigma is very expensive, and while it might yield information valuable to managers, it provides no benefit to those actually doing the day-to-day work of software development. I am not aware of any manufacturing processes shown conclusively to improve the hands-on work of software development.

XP and Scrum are not nearly enough to guarantee a successful software project. For a comparable situation, just because a band has a rehearsal schedule and some gigs does not guarantee that they will be international superstars. Brian Marick at one point talked a lot about four principles that also increase the chance of a successful software project: skill and discipline, ease and joy. I won't explain those here, interested readers can find that work themselves.

But beyond even skill, discipline, ease and joy, a successful software project requires that we as creators of the software reach out and interact with the world in a way that changes the lives of those who encounter our software. It is an awesome power. In some cases, we can make our users' lives a living hell. But it's a lot more fun to make everyone happy.

7 comments:

Alan Shalloway said...

I am afraid your comments about Lean/Kanban are not really accurate. Kanban thought leaders do not refer to eliminate waste anymore for many reasons - some along the lines of what you are mentioning. Also, Lean/Kanban has been derived from other sources than manufacturing now. In our courses we barely mention manufacturing and only acknowledge Toyota as a source of ideas. In any event, I would think one would judge something on how it works and not where it camem from. Waterfall comes from software development too, you know.

Just to be clear, Lean/Kanban specifically would say not to treat you like a station.

As a QA person, I'm surprised you don't like Lean/Kanban because it explicitly talks about building quality in and strongly suggests doing up front acceptance testing.

Not sure why you are referring to Lean Six Sigma and ISO 9000 - they have nothing to do with Lean/Kanban.

BTW: Kanban does have a way of celebrating. It can be done after each piece of work is done as well as on the weekly (or bi-weekly) cadence.

You are certainly entitled to your opinion about what you like and what you don't like. I just wanted it to be clear that what you are saying you do not like is not Lean/Kanban

Alan Shalloway
CEO, Net Objectives

Chris McMahon said...

Mr. Shalloway, let us just say that our last conversation on this subject did not make me happy.

I find it interesting that you can snap your fingers and "waste" is gone.

You can snap your fingers and magical "other sources" appear.

It's as if you're making it up as you go along.

I've read Royce's waterfall paper, don't even go there.

lala said...
This comment has been removed by a blog administrator.
Tobias Mayer said...

Hi Chris,

I like the way you write about this stuff, acknowledging its history, and the formalization of good practice that Scrum and XP offer. Like you I am suspicious of the manufacturing metaphor that many try to use in software. it has a poor history, but more than that it makes absolutely no sense. Software development is a creative, improvisational endeavor -- everything is new.

Despite what all its proponents and "thought leaders" (!) say, Lean and (by association) Kanban is rooted in streamlined process more than in creativity. Unless reinvented or recast that process paradigm will actually hold us back.

There are some in the Kanban community who lead through creativity, but sadly they seem to be the exceptions that prove the rule.

But then, all names aside, there are good people doing good things under all sorts of meaningless jargon banners. Lets shed the jargon, the market niches everyone is clinging onto and then we can see more clearly the good things that are occurring.

lee said...
This comment has been removed by a blog administrator.
Anniversary Rings Diamond said...
This comment has been removed by a blog administrator.
TestWithUs said...
This comment has been removed by a blog administrator.