In many development shops the urge to make the high profile, or in some cases the high maintenance customer happy side tracks development cycles and introduces schedule risk that are hard if not impossible to audit in the post mortem for the project. Product Managers/Product Owners are quick to point out the product shipped 4 weeks late but exhibit a surprisingly short memory about events that caused the schedule to slip. Pulling off an engineer to fix a bug and deploy it for a customer for 1/2 a day adds up. It also derails the performance of that engineer in the development cycle. A good rule of thumb is take the amount of time the engineer was derailed and multiply it by 4, this is the real cost of the bug fix not the actual time it took to fix the bug and deploy it for the customer. It might be smart to build this into the estimate to fix the bug, quoting 2 days to fix the bug rather than 1/2 a day may cause the bug to be deferred until the next development cycle, which is probably what should happen in most cases.
The factor of 4 takes into account the engineers intensity in the development cycle, let's call it in "the zone" level of performance that produces optimal efficiency and quality for the engineers work. When this is derailed it takes time for the engineer to get back to where they were and back into "the zone". In development shops where this is common practice, schedules are rarely met as the estimates that made up those schedules didn't include the interruptions. It's also important to consider the issue of the ROI of fixing the bug. Now in the case you have 2 customers the math is easy, losing 50% of your customer base makes the case a 'no-brainer'. In the case where you have 2000 customers, fixing the bug and derailing the development cycle for the 1999 customers who haven't complained about it doesn't make sense.
So how does Scrum force the improvement of customer management. One of the immutable laws of Scrum and one that becomes apparent to all the stakeholders, product owners included is that you never, ever, interrupt a Sprint.
The nature of Scrum is full body contact. Everyone involved in the Scrum is fully involved, including the Product Owner. He has ranked the Product Backlog Items to make sure the most important items are considered in the planning meeting first. He is involved in the planning meeting so he understands which items made it into the Sprint and why others couldn't be included because of effort and time constraints on the Sprint. He can understand that it may take a few more Sprints before the full feature is complete. But he is also comforted by the knowledge that he may chose to forgo some of the later Sprints containing the lower ranked Product Backlog Items so he can ship the feature earlier. That's because of another immutable law of Scrum at the end of every Sprint the Product is shippable.
So a pleasant side effect of Scrum is that the Product Owner is forced to manage the customer, rather than the other way around. If a customer calls with a bug or enhancement request, rather than hang up the phone and walk into the Software Engineering Managers office to request work start right away, the Product Owner manages the customer and informs them that it will be a high priority for the next planning session but it can't be addressed immediately. Even then the Product Owner may not commit to a date because he is mindful of taking away time in the next Sprint that could be used to implement his next stack of Product Backlog Items.
By managing the customer, the Product Owner improves the efficiency of the machine producing his product, getting features and other enhancements out faster. This can be a win for the customer as well, by managing the customer expectations they are satisfied they have been heard, they have been told it will be given priority and worked into the development schedule, and they will be pleased to see new features and enhancements coming out in the application faster than they were before.
No comments:
Post a Comment