Frank Carver’s musings about software and life
Every now and then we have a discussion about bugs, whether and how they should be fixed, and the relative importance of each bug compared with key missing features. Solutions range from the naive to the overcomplicated, but at least nobody yet has suggested something like the following…
Our agile team is finding some things challenging. In particular deciding how to prioritise and work on “bugs” in the midst of a pool of prioritised and scheduled feature stories.
“Agile In Action” has a nice summary of an approach to software development. Most agile practitioners won’t find anything to object to.
AGILE IN ACTION: The Energized Way
Our first problem is with the second bullet “Work with clients every day“. As a team we would love to work with clients every day, but there seems to be a thick layer of representatives and proxies in between us and real customers. This is made especially difficult as we are currently serving the needs of several customers with a single product, and resolving customer differences is proving tricky.
Our second problem is with “Fix defects as soon as they’re discovered“. In principle this seems obvious, but the trouble we are having rests on the definition of a defect. As an agile team we keep up-front specification to a minimum, and in-effect treat every delivery as a prototype ready for customer feedback. Plenty of people in the company have opinions on such prototypes - things they think it should do, things they think it should not do, and things they think it does wrong. Any of these could be considered as defects (and indeed many of them are raised in our bug tracking system.) If we stopped new work to make all these changes we would (a) greatly reduce our feature velocity, (b) bypass the prioritisation process used to “Deliver the client’s highest-value stuff first“, and (c) leave us stuck in a mire of conflicting opinions.
We certainly do not ever want to deliver “broken” software, but its a fact of life that some “bugs” are lower in priority than others. Some “bugs” are also lower in priority than new features, but this is more of a business decision than a development decision. Working out how deliver prompt, appropriate and minimal software in the face of such a slew of opinions is proving contentious.
I’d be interested in reading any suggestions or answers to these problems.
I’m not generally a fan of “debugger” tools. They seem laborious, manual and clumsy compared to the speed and precision of unit tests. However, it’s not always easy to decide what test to write to localise a particular bug. Kent beck offers a technique he calls the “Saff Squeeze”.
This slightly provocative post examines the role of QA (a.k.a testing) in various view of a project lifecycle and considers how we might react to a QA team which reported no bugs.
Well. I already know (or maybe “hoped” is a better word) that Lego is not just for kids. But any article about both Lego and agile software development was bound to catch my attention.
This article is about the idea of using Lego bricks for time tracking and bug prioritisation/organisation. Personally I think the suggested use for time tracking is the better of the two, but the whole article opens up another avenue of using everyday objects to improve the process and environment of work.
InfoQ: Lego Is Not Just For Kids Anymore
…Now I just have to convince the hard-nosed company finance boss to invest in a bucket of Lego bricks 