Introduction
Reopened issues and developer feelings don’t mix well, a recurrent phenomenon I’ve seen on all projects I’ve worked on. Some might feel they’ve worked “in vain”, being reluctant to restart it all over again.
Reopened issues are bound to happen
There is a thin line between taking ownership of your current project and remaining professionally detached at all times. The only thing that matters is the value the customer gets for any given issue, even if it takes more steps than you previously anticipated. In software development the change is the only thing that never changes, that’s why you’ll always have to deal with reopened issues. Reopening an issue is not necessarily a bad thing, as you’ll soon find out.
What you can learn from reopened issues?
The QA is doing it’s job
There’s a good reason why we employ a “Testing” column on our Sprint boards. A task must obey the rules depicted by the “Definition of Done” policy, otherwise it might not deliver the promised business value. The sooner you test it, the least expensive the fix gets.
The clients are not sure what they want
Some clients have difficulties visualizing a flow until they are actually interacting with it. From a management point of view this is a waste of resources and it should be addressed accordingly. If it happens frequently then a “cheap mock-up” might be worth considering.
A chance to challenge your design
From a technical perspective the design is challenged to adapt with minimum effort. If you always have to rewrite everything to accommodate any unforeseen change, then you should definitely question your current architecture.
A test for the peer review process
If a task is reopened without a change of specification, it means the current technical solution is not properly functioning. The peer review process is aimed to prevent such situations, so you should check both the original problem and the review process.
Recurrent reopened issues may indicate a brittle component design
A bad design always surfaces in the form of reopened issues. If you happen to work twice as hard to accomplish a given task, you might reconsider your design or coding practices.
Conclusion
Reopening issues is just feed-back, and the sooner you receive it the better you can address it. Reopening issues is just a step in a task life-cycle. When you’ve finished developing a task, it doesn’t mean you’re done with it. This is the proper mindset for doing Agile software development. A task is done only when the customer accepts it’s business value. If you see the big picture you’ll be less frustrated by reworking a given functionality.
| Reference: | Afraid of reopened issues? from our JCG partner Vlad Mihalcea at the Vlad Mihalcea’s Blog blog. |
