Selling XP To Sales
By Adrian Sutton
XP is a process that requires constant communication and a strong commitment to making XP work. While you can do XP subversively without getting the rest of the business to buy into the process, the benefits you get will be significantly diminished. For a software development company, adopting XP affects every single part of the business and it’s important that everyone understands their role in the process and wants to help make it succeed.
So how do you sell XP to your sales and marketing team? Show them that it works.
It’s amazing how open minded people are after you’ve proven to them that something works. So get started on XP without worrying much about sales and marketing – in the early stages they won’t be affected much and they won’t affect the XP adoption much. Once you’ve gotten the basics of XP working and you can consistently get through iterations without major dramas, look for the next opportunity to do work directly for sales and marketing and run the project XP style with them as the customer.
At Ephox, the first opportunity was getting enough of a new feature developed that it could be demoed at an upcoming trade show. Deadlines were tight, there was absolutely no chance of having the entire feature completed and ready but it was still important that we had something to show. So we sat down with the people doing the demo and worked out what parts of the new feature were absolutely required to be able to demo it and what parts would be nice to have. We wrote them all down on story cards. Then we played the planning game.
Since timelines were so tight, we kept the stories very small and replayed a mini planning game after each story was complete. Mostly the planning game was just so that engineering could pass on the message that a new function was available and get the sales and marketing team thinking about how to best incorporate it into the demo – plus making sure it worked well enough. Sometimes though, after playing with the product sales and marketing changed their mind on what was most important and a different story was substituted as the next thing to do.
We tracked velocity in broad terms as well, so that an estimate could always be given as to which of the stories would be completed in time and which wouldn’t make the cut. The velocity wasn’t particularly accurate but we kept it slightly on the conservative side and came out ahead of schedule – if you can’t be accurate, be conservative.
In the end, I don’t think the demo was as impressive as anyone would have liked it to be, but given the time constraints and the fact that we originally didn’t expect to have anything demoable at all – it ended up quite well. Most importantly though, sales and marketing got to see how the XP process was working and how engineering worked with product management on a day to day basis to deliver the most important functionality as soon as possible and make each release as valuable as possible. They also got a taste of the flexibility that XP can provide – as a business we still need long term road maps so our major clients and OEMs can see where we’re headed, but it’s reassuring to know that we can turn on a dime and address the most pressing issues for clients, prospects or competitive pressures from other products.
How else do you sell XP to sales? Improve quality. Microsoft may be able to ram poor quality software down everyone’s throats but a small company in an enterprise market can’t – we have to make it right, first time and every time. Sales cycles are long and finding bugs in the software just makes them much, much longer, so our sales team is always interested in seeing us improve the quality of the software we develop.
At the start of our adoption of XP, we took on replacing a major core component of our product to make it flexible enough to add the features we had planned. The project involved completely rewriting a component that we’d used at the core of our product since its inception, but had never directly worked on and had very little understanding since it was provided from the JRE class libraries. Now had come the time where it was limiting what we could do, so it had to go. It was time to replace the code that parsed HTML and inserted it into the document model that swing text components use for editing. For a HTML editor, there’s really nothing more central than that bit of code.
The project took about two months – the first month writing acceptance tests to capture the exact behavior of the existing HTML parser and the second month writing the replacement that made them all pass (using TDD). We’ve had the replacement deployed to our internal systems for a few months now and in all, three bugs have been reported against the new code. Just three. Now there will almost certainly be more bugs in there – we haven’t actually run it through a proper QA cycle yet and it hasn’t been deployed to customers, but I physically cringed when I deployed it to our internal systems expecting to be deluged with complaints for the next few weeks. I’m thrilled that it’s gone so well.
That kind of quality in development, when applied to things that sales and marketing can actually sell instead of just replacing internal components is sure to impress.
For the record, I’ve written about some of the approaches we’ve used while replacing the HTML parser before: