Lean Development

I've started reading "Lean Development" by Mary and Tom Poppendiek.

I've poked around reading articles and such about XP, Agile programming, Scrum, and related wierdness, but this is the first time I've sat down to give serious attention to actuall "book larnin'" about the theory and practice ("And theory, what of theory" ...."Show me the words that will re order the world!" )

Anybody have any actual experience with any of that or have any strong opinions (reality based, we hope, but either way...)

Just for perspective, the last "Methodology" I dealt with at a serious level was "Jackson Structured Design". That was a while ago. I understand the dinosaurs of those days are no longer with us. Pity.

Agile with Scrum demonstrably increases team productivity by around 10x over RUP. It is *very* hard to get a management team to buy into, though--so it is rarely used in a form which realizes those gains. I've seen good scrum-masters call that "scrumbutt"--we're doing scrub, but...

RUP is the logical heir to the older methodologies.

XP and scrum require that requirements actually be out in front of development, and that teams be small, smart, and well-connected (e.g. in the same space or very good with remote access tools).

As far as books, well, I've only ever read Agile Software Development with Scrum (Ken Schwaber, Mike Beedle); the rest I've been coached in or read about on-line. It's a very simple system.

I just finished reading Corey Ladas' "Scrumban".

He's making a believer out of me.

The Poppendiek book had maybe 1/2 dozen actual concrete ideas and lots of very general gnomic wisdom which might be valuable, but might just be "My son, Life is a Fountain" stuff, plus lots of what I call "Hubba hubba".

Ladas' has the air of an informed and intelligent agent, seriously grappling with the important questions of how to run a software effort; aware of the history of who tried what and how that worked out, seems to have a grounding in the relevant math (queuing theory, simulation modeling, has at least heard of Petri Nets, etc) and if he's fooling, well he's fooled me good.

There seems to be a small constellation of names that come up. I think Ladas ref's Schwaber.

Ladas also seems to have a reasonable take on pair programming. He see's XP's "pair programming all the time" as one (extreme) point along a continuum from that to "never pairs" at the other, with the possibility of doing some pair programming some of the time depending on the situation and the terrain.

But isnt there a bit of a paradox here? If Agile/Scrum etc can spin straw into gold (ten times productivity over RUP) , why arent the Powers that Be insisting on all scrum all the time? Why "scrumbutt" ?

Scrum requires a very different mind-set from traditional project management. Since most project managers are traditional ones, that is, trained and have been running more traditional (e.g. "CPM" or "timelined") projects, they are loath to give up control the way you must to do scrum.

I actually had a senior manager tell me point blank that he didn't believe we could produce the way we had ** already demonstrated we could produce **. That is, he thought we were lying (apparently) about the results we had from a 24-week agile project.

In addition--if you don't run the same project both ways, it's very hard to compare productivity. So... you have to actually build metrics in advance. Most programming teams don't have good metrics of any kind (scrum teams MUST have metrics, or it isn't scrum--no way to measure velocity without metrics).

I've read a fair bit of Corey Ladas recently, and I think Kanban could well be what a couple of my teams need. I'm writing up a proposal to that effect.

As with all methodologies, you can't just change the way your team works. You've got to have understanding and cooperation from the other business units you interact with.

For further reading, I'd recommend Henrik Kniberg (very down-to-earth, practical advice) and Derick Bailey.