If you're wondering who owns the product patches, who determines when a patch will be done, what will the patch cover and how it will be delivered, the answer to all these questions is summed up in one word - Support
You don't depend on CTO Development or Operations manager to forward the requests and make developers do the actual work of creating patches. Simply use the Scrum process we have set in place and get your patches delivered just the way you like them - medium rare or well done
Below you will find 3 easy steps to help you help customers
1. Identify the need
As you are directly in contact with customers you can feel their pain and determine what issues trouble them the most; no one else can do this for you, not CTO, not QA, and definitely not developers who created the issues (although inadvertently) in the first place
Ask yourself the following questions:
a) How many customers have been affected?
b) How serious is the bug at hand? (see How to determine your own bug severity)
c) Does the identified bug have a workaround you can offer now to the customer?
d) How fast does the customer need the fix?
e) How many "invisible" customers who didn't contact you could have been affected by the bug?
f) How brand-damaging is the bug?
g) Will patching the bug now help the company to keep existing customer or gain a new one?
Compile and maintain the list of bugs-for-patching candidates daily; make sure you include only bugs that customers actually need. Remember: not all bugs are created equal - a High severity bug that has a workaround isn't necessarily instant candidate for patching
2. Make the request
Now that you have a neat list of one or more bugs that obviously need to be patched ASAP, create a patch request for corresponding product: just add/update a Product backlog item directly in the product-owning developer team's Product backlog
If you are requesting a new patch, create a new Product backlog item and describe in details what exactly you need delivered - specify all bugs individually, their ID, severity and description
If you have found additional bugs for the same product that need patching, append them to previously created Product backlog item if it is still open
Send an FYI to Product owner and the developer team about added / changed Product backlog item in their Product backlog
3. Deliver
You've done your job - don't worry if or when will you get the actual patch sent to you, this is now up to the developer team (they also have a system and a set of rules to follow). However for reporting needs you should still maintain a list of all patches you requested and when you requested them
As soon as you receive the patch with requested bug fixes, directly contact the customers who reported the issues and make them happy
Q/A
Q: I need to get a patch for this Medium severity bug as customers desperately need the fix. However rules say I can only request a patch for Critical and High severity bugs?
A: Why do customers desperately need the fix? If this is so obvious, are you absolutely sure your bug should be Medium severity in the first place?
Q: I requested Critical severity bugs patched and the customer needs this yesterday. Developer team just started a new two-week sprint without the patch goal included so this patch won't be done in another two weeks - can I yell at developers to speed this up?
A: No - don't yell and don't go pulling on CTO or Ops manager skirt. Developers also have a set of rules to follow and one of the rules is that Critical bug fixes must be delivered in a week's time even if it means working outside of the Sprint during allocated ad-hoc time. You'll get your patch sooner than you think
Q: I always request new patches each Friday once I build up a list of obvious patch candidates but customers don't want to wait 3 weeks to get the patch. What can I do?
A: Start by requesting new patches as soon as you identify bug candidates for patching, not once per week - there's nothing limiting you to do this daily if needed
No comments:
Post a Comment