Respecting Scrum by doing more

;-) Confession
I did eXtreme Programming before I did Scrum. Although this may seem trivial, it has positively affected my further Agile career.

Let’s go back in time…
In September 2003 my management (consultancy company) assigned me on a project that they hadn’t hoped to win and that was allotted far too late. Result: our company was facing a development effort of 700 days and delivery in December. Two software architects, literally in 15 minutes, convinced me of applying eXtreme Programming. Because I recognized what I had been trying to do in previous projects, but was now sort of ‘hard coded’ in the approach, i.e. iterations and communication.

In only a couple of days we created User Stories, replaced the MS Project phasing by 3 iterations of 3 weeks and convinced the external customer to intermediately attend demo sessions. Our roles included the Team, a project manager/Big Boss (me), a Coach and a proxy Customer. As we soon discovered that our proxy Customer was fully occupied in functional guidance to the Team, we included a Tester to assist her. The Tester incrementally wrote hands-on functional test scenario’s for the User Stories being developed. We added 2 days of slack before the stakeholder demo; to fix small issues, prepare the next User Stories and do spikes.

In 2004 we had to scale and the same fellows (now Coaches) directed me to Scrum. I read the 2 books by Ken Schwaber and registered for his CSM course in May 2004 in Brussels. It was a great experience and as from then we used Scrum for our organizational practices (Sprints, roles, meetings, artefacts) but we kept using eXtreme Programming as implementation for the general Scrum demand of Engineering Standards (PP+TDD, CI+Refactoring). From those engineering standards the use of User Stories emerged, as well as the roles of Coach and Agile Tester.

We always delivered fixed price projects as an external supplier. So we had to translate the customer’s Vision (mostly an RFP) into a Product Backlog, more READY than you would expect in pure Scrum. But we put a maximum length of 1 Sprint on the effort (but usually did it in less time). Our Sprints delivered DONE and potentially shippable work, but we added a final hand-over Sprint (no development!) to close the project. Oh yeah, our ‘slack’ turned into Product Backlog Grooming sessions.

A framework was born.
I went through lots of yo-yo movements over the next years. Even quitting for a while, tired of the slow local adoption (supplier ànd customer side). But… relaunched my ideas as My.Fragility to re-enter the market. And at my current employer we renamed the framework to ScrumPlus, because it does respect Scrum completely, but just extends the base pattern of Scrum to the particular use for delivery of fixed price-negotiable scope projects.

Back to the future
In February 2011, my management decided to apply only Scrum and ScrumPlus in some major Service Lines, abandoning RUP or other traditional approaches.

So I have set up a training program while I will be coaching people in the field. From the training people will get a deep understanding of the base mechanics, principles and emergent Scrum. Project practitioners will get a good understanding of ScrumPlus as instance of Scrum, its base Philosophy of Done, its Agile Project Life Cycle and the 2 Excel tools.

And as you have understood this is largely rooted in my early eXtreme Programming experience.