Most developers know the feeling of an co-worker or manager appearing at their desk in a mildly agitated state.
Something bad has happened.
Something went wrong and you're the "go-to" person to get it solved. The customer is upset, the system isn't working, and generally people are really unhappy about how things are going with some code that you know about. This may not be your code, but you're the one that can get it done now. That's precisely what you do. You resolve the issue and get the customer on the right track. Everyone at least appears happy and everyone goes back to their normal routine. The problem isn't really solved; all you've done is put a bandage on a wound.
There's likely a larger issue. All we've done so far is cure a symptom. Symptoms are usually easy to recognize and deal with, in this case the bug that is causing the program to fail. Don't stop here or the underlying problem will continue to fester. You need to know how you got to this point.
What you need now is honesty, transparency, and a genuine interest in making things better from all parties involved to get together and figure out what happened. What you want to achieve is communication that's going to make life easier, the product better and the customer happier. I've heard it referred to as "root causing" an issue. More formally said, a Root Cause Analysis. Get all of the people together (and not necessarily in a meeting room, just somewhere!) and talk about what happened and figure out what to do to keep it from happening again. I'm not advocating a cast-in-stone policy be put in place to handle all situations like this one in the future, but just a clear understanding of what happen and an agreed plan among everyone involved to get the issue out of your lives. Everyone needs to sit down and work out the facts about the way you do things that cause the customer to have to deal with a badly working product.
Also, keep in mind you don't need to restrict root cause searches to just negatives. You've probably got quite a few examples in your head of people or departments that are the definition of productive and happy. Why not find out what they're doing right?
You need to concentrate on growing an environment that keeps bugs from entering your codebase; not a process that allows for the quick removal of bugs.
Something bad has happened.
Something went wrong and you're the "go-to" person to get it solved. The customer is upset, the system isn't working, and generally people are really unhappy about how things are going with some code that you know about. This may not be your code, but you're the one that can get it done now. That's precisely what you do. You resolve the issue and get the customer on the right track. Everyone at least appears happy and everyone goes back to their normal routine. The problem isn't really solved; all you've done is put a bandage on a wound.
There's likely a larger issue. All we've done so far is cure a symptom. Symptoms are usually easy to recognize and deal with, in this case the bug that is causing the program to fail. Don't stop here or the underlying problem will continue to fester. You need to know how you got to this point.
What you need now is honesty, transparency, and a genuine interest in making things better from all parties involved to get together and figure out what happened. What you want to achieve is communication that's going to make life easier, the product better and the customer happier. I've heard it referred to as "root causing" an issue. More formally said, a Root Cause Analysis. Get all of the people together (and not necessarily in a meeting room, just somewhere!) and talk about what happened and figure out what to do to keep it from happening again. I'm not advocating a cast-in-stone policy be put in place to handle all situations like this one in the future, but just a clear understanding of what happen and an agreed plan among everyone involved to get the issue out of your lives. Everyone needs to sit down and work out the facts about the way you do things that cause the customer to have to deal with a badly working product.
Also, keep in mind you don't need to restrict root cause searches to just negatives. You've probably got quite a few examples in your head of people or departments that are the definition of productive and happy. Why not find out what they're doing right?
You need to concentrate on growing an environment that keeps bugs from entering your codebase; not a process that allows for the quick removal of bugs.
Jeff Nall, Scrum Master and System Architect. Find more free Agile Development Methodology information at MakeThingsGo.com
ByJeff M Nall 
No comments:
Post a Comment