Control vs. Velocity

I’m sure by now that you’ve seen or at least seen references to Tom DeMarco’s article in IEEE entitled “Software Engineering:  An Idea Whose Time has Come and Gone.”  It’s been a week or so and I’m still not quite sure what I think about the subject.  There is definitely some tension between “control” and “throughput.”  On a tangential note, we (Dovetail) roughly follow a Kanban process.  I don’t really have a set opinion about how Kanban should be done, but what I do know is that I really like the “rolling wave” style of project work.  Moreover, even though I’ve been an XP advocate for quite some time, I really don’t miss iterations (the engineering practices that came out of XP, however,  are still mandatory in my book).  I don’t miss iteration kickoffs and retrospective meetings and endless rounds of planning poker at set times.  It interrupts the “flow” of the work and doesn’t add enough value IMHO — especially for a very small team like ours.  I think that formal iterations do set a pretty good pace for the team and allow some control from an estimation and project velocity perspective, but I think iteration process mechanics detract from productivity.  For the sake of optimizing throughput, I really like the Kanban style of “pull down a feature out of backlog and work it until it’s finished” model.  The “rolling wave” style is surely harder from a project management perspective, but does that really matter that much compared to getting stuff done?  “Retrospectives” happen continuously, and when we really do need to stop and pay down technical debt, we do.  I don’t need a set schedule to tell me to do what I already know to do.

My friend Ward Bell had some comments about DeMarco’s paper as well.

 

P.S.  The whole “Lean vs. Agile” thing is a huge pet peeve of mine.  I think Lean thinking helps put Agile practices into perspective, but I don’t see it being a completely different thing.  If you live in Austin, don’t get caught saying “Lean is the new Agile” in my presence.  I will blister your ears for that nonsense. 

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://codebetter.com/members/ScottBellware/default.aspx ScottBellware

    In my experience, Lean is indeed not the new Agile.