Tag Archives: techincal debt

Craftmanship over crap?

Uncle Bob (A.K.A Bob C. Martin) posted an interesting thought about his keynote from Agile 2008.   The idea was a metric for code quality as measured in “WTF’s per second”.  That is, during a code review, how many times you see code that makes you say “What the F***?”

I like that idea, but I don’t agree with the proposed 5th Agile Manifesto Statement “Craftsmanship over crap” or “Craftmanship over Execution”.  Like all Agile statements we don’t NOT value the item on the right, we just value what’s on the left more.

I’ve always thought that the underlying principal of Agile practices, particularly Scrum, already preach about quality software.  The goal is always potentially shippable and bug-free software so maybe it’s the optimist in me, but shouldn’t the programming methods used in Agile development (pair programming, TDD etc) already police against writing crap?

If developer A writes crap and then code reviews it with developer B, I would fully expect developer B to point out what’s wrong.  I don’t think anybody wants to churn out crap for the sake of getting something done and  I can only see lack of knowledge or experience being the culprit.  This lack of knowledge or experience should be able to be fixed through Agile processes.  If a team member is struggling, help them.  If a team member is knowingly churning out crap, try and help them or boot them off the team.

I don’t think we need to update the Agile Manifesto to state the obvious.

To Estimate Bugs or to Not Estimate Bugs, that is the question

Is it a bug or is it an improvement?  Well, that debate will happen during any project but the purpose of this post is to iterate why bugs (legit bugs) should not be estimated in Scrum.

First of all, if you’re using Agile development techniques, you shouldn’t have any bugs to begin with but in the event bugs are introduced in a project, according to Scrum, they float to the top of the product backlog and take priority over all other work.    Quality is not negotiable.

So to answer the question, no, bugs should not be estimated.  The items on the backlog have been estimated and are the items that deliver business value.  If a bug is introduced and then estimated, the Team has essentially ‘double-dipped’ their estimate for a backlog item since that bug would have been a result of one of the backlog items.  This will throw off your velocity and make it look like progress is being made towards items that deliver business value when that is not the case.  There could be situations where your velocity is zero and that’s fine.   The Team will learn and adjust their development methods to produce zero defects.

The job of the Scrum Master is to make this situation transparent to the Team, product owner and stakeholders so there are no surprises.