About a year ago I started building a new team at DocuSign. I hired a few engineers, teamed up with a product manager and started building a portfolio of products that were all designed to plug DocuSign into leading business ecosystems.
I am a big fan of agile project management. As I evangelize DocuSign technology in addition to managing a dev team I always need a clear answer to where the team stands and what we need to do to get the product shipped. Overall the personnel and the method worked out really well we shipped on average 1-2 new products or new versions of products every month.
Now the success is catching up to us. Several thousand customers have deployed our products and they are starting to use it for business critical needs. What this means is that now folks are encountering new configurations and new use cases and the issues get escalated to my engineering team through support and sales staff.
Every purist who is saying: “you should have had better documentation / you should have tested all of the possible environments” can sit down and just admit that they have never shipped products in emerging markets with emerging platforms. The reality is that escalations will happen.
Our solution to this has been to give developers an interruption fund (we call it a “slush fund” internally). Basically a couple of developers and one QA engineer get 2 days every two weeks to account for interruptions. If not interruptions come in those folks use the time to improve unit tests, fix build issues and do other things to “pay down the technical debt”. For your reference the total team size is 6 developers and 2 testers.
My question is: how do you deal with interruptions while running a scrum team? Thoughts or suggestions? Hit me up over twitter @mikebz .