Tag archive


It’s Not a Bug, It’s a Feature

in Agile/Agile Engineering by

featureI know everyone who has worked in or on or amongst a development team has heard the saying, “it’s not a bug, it’s a feature.” When said, it is usually followed by some laughter, sometimes remorseful laughter. Heck, you’ll even hear the users beat you to the punch when they say, “that’s a feature, not a bug – right?”

Ding. Ding. Ding. Mr. User, you are absolutely correct!

Anything that goes out the door is a feature of our product (or anything we release to our users is a feature). Now whether the feature improves the value of our product or service, or if it detracts from the value — they are all features. We chose to release our software — we may have known about the problem or we may have known that we did not test enough or we may not have had the awareness of a unique usage scenario – no matter what we chose to release and everything in the product is a feature. Couple the concept of releasing bugs in our code with the premises around technical and design debt, well now our heads are exploding as producers of software.

Now, you are probably saying, “yes Matt, we get that … but what’s your point?”

Well a lot of organizations struggle with the concept of balancing the amount of bugs (and technical debt) in the software that we address versus the amount of new features and enhancements that we add. We often find that stakeholder who is all about the sexy or the cool — looking for that differentiator that users want.  As a delivery team, we are quick to say to the stakeholder, “you don’t get it, users aren’t going to like this and it’s going to costs us more to fix later.” This statement is 100% correct. The stakeholder, who may have a case of “rabbit ears” responding to a big prospect need and he or she may not have visibility or understanding about the extent of the technical debt within the software.

So what do we do about it and how do we find balance?  There are four things that I’ve seen work really well:

1. Make all bugs and technical debt part of the backlog. I run into folks that will manage bugs in one system and stories (requirements) in another. They need to be together — remember a bug is a feature, it’s just a negative one. You can write the bug as a story. The bugs should be ranked and treated like any other member of the backlog.

qualitychart2. Create Metrics and make them BIG AND VISIBLE. A chart that demonstrates number of bugs by severity on a specific day is not too useful to communicate this problem. But, a chart that shows a trend over the last six months the # of bugs found with a corresponding chart series that shows # of support calls for the same period and with another line that shows % of maintenance renewals — well, now you have a powerful story. How about a chart for measuring quality that is based on the number of known bugs released / number of support calls? Or, similar to this the number of new features released / number of support calls. And, how about a simple number — the percentage of our total backlog that is associated with bugs and technical debt. I guarantee a high number will get someone’s attention. Make these charts part of your team’s information radiator, post them on the wall in the break room, or start making them part of that weekly project report.

3. Conduct frequent Extermination Hack Fests. Establish one day an iteration as a bug extermination day or maybe ever three iterations, use multiple days for this activity. This is not just about having an hardening sprint, it is about allowing the engineers (architects, testers, and developers) to team up and knock out bugs with the only consideration that once you start working on a bug, it must be fixed or an approach designed to fix, by the end of the Extermination period.

4. Align resolving bugs and technical debt with strategic goals. Almost all companies have goals associated with customer satisfaction, or growing our footprint within our existing customer base, or establishing market leadership. These goals are not achieved by putting out crappy product. By leveraging the metrics above, value can be placed and impact measured of resolving bugs and paying back debt to achieve strategic goals. Be sure to measure improvements and investment against the goals as it surrounds bugs, and make it known when the team has an Extermination Hack Fest that resolves 15 customer found bugs which will improve our positioning on customers paying ongoing maintenance.

These are the four I’ve seen.  What have you used to get over the tug-of-war between new stuff vs. bugs?

Top 10 Top 10 Agile Lists

in Resources by

Top10Top10A while back I stumbled upon a clever blog post that showed the Top 10 of Top 10 lists and given my lack of creativeness today, I thought I would put together a Top 10 of Top 10 Agile Lists. I took this on and felt it would be an easy task given the amount that folks are talking and writing about agile. Well, it really wasn’t that easy, but I did find 10 Agile Top 10’s that are worth a read. Check them out, and please share your thoughts and links to other agile blogs that you feel are good ones:

#10 10 Misunderstandings About Agile Development. Written by the folks that maintain the Scrum Project Management blog, this is a clever and funny blog that tries to dispel some of the misgivings of agile. My favorites are “We do not want testers in Agile Development” and “Agile will likely be too chaotic to track progress.”

#9 Top Ten Agile Analogies. Damon Poole (founder and CTO of Accurev) is a funny guy without writing this blog, but he of course delivers with this one on Do it Yourself Agile blog. My favorite from this one is an anonymous quote, “Agile is like being pregnant, either you are or you aren’t.”

#8 10 Contracts for Your Next Agile Project. This is not really a top 10 list; however, it is a solid list of 10 contracting methods you can use if you are starting/contracting on a project that will be an agile project. It’s a good read and a constant question I hear while working with teams.

#7 Top Ten Organizational Impediments. This blog was penned by Craig Larman and Bas Vodde, this top ten list lays out some of the issues that slow or prevent organizations from successfully using agile as a software development process. Much of the list centers around the organizations that say they are agile but they are not serious about it. What I mean is that they are not aware of the commitment they must make.

#6 Top 10 Estimation Best Practices. I like to say that we make estimating way too complex; however, we all do it and we do make it too complex. This blog from Leading Answers (Mike Griffiths) takes a fairly broad brush and paints out 10 guidelines surrounding estimation. The best point made is “Agree on what ‘It’ and ‘Done’ Means”. This is where the conversations for agile requirements should be centered and estimation will be natural and easy.

#5 Top 10 Essential Product Owner Characteristics. Peter Saddington does a great job maintaining AgileScout, and he has done a good job helping to hone the skills of the ever important Product Owner role. This top 10 list does a great job spelling out those things to look for within a good product owner — the best one here is “Collaborative by choice.” To me, this characteristic is make or break when it comes to a good Product Owner.

#4 Top Ten Reasons to Love Agile Testing. This is a favorite list of mine. One reason is that a team that has embraced Agile Testing best practices is usually a successful agile team and the second reason is that it is a fun list.

#3 Top 10 Agile Development Traps. Found on BrainsLink.com by Vin D’Amico, this blog posting should be shared with all developers as part of their training and indoctrination to agile development. I’ve seen multiple teams fall into these traps.

#2 10 Agile Strengths. John Goodpasture writes a great positive blog about why Agile has worked for him. He stated that his first post about agile weaknesses went negative and I must say, you are not alone. A lot of folks write negative slanted blogs about agile and it was bought for me to find many positive top ten lists. I don’t get this because I see that when Agile principles are applied and used, the long-term results are positive. Nonetheless, thanks John for writing a positive top 10!

#1 Top Ten Things Programmers Hate About Agile. And to wrap up this top 10 of top 10’s, Damon Poole provides us the perfect satirical top ten to make folks reflect on why they think they don’t like agile. It’s a great list in that it pokes good fun at some behavioral aspects of developers/engineers which often lead us to dislike the fun change that Agile introduces. Nice job Damon 🙂

If you have a top 10 list to share, please post a comment and a link.

Go to Top