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.

Can there be more to Scrum than… Scrum?

or: the evolution towards what I now call “ScrumPlus“.

Over the years I assembled a framework of roles, practices and experience in Agile delivery of fixed price projects as an external IT supplier (consultancy). Starting with eXtreme Programming (2003), it was expanded with Scrum in 2004 (when I certified from Ken Schwaber, quite unforgettable). Still, due to specific circumstances (local market, consultancy perspective, etc.) we always did just that little bit more.

The essence of my framework has not really changed. But it has always been a struggle to name it properly.

In 2008-2009 I used the very personally inspired My.Fragility. As that reflects how Scrum ‘saved’ me, how it set me free to work better with teams, customers and management. The gigantic relief of being free to be fragile, personally and with people (as opposed to bossy-ish command-and-control that management traditionally tried to force me into).

At that time my professional position blocked the use of my framework. But keeping it alive via this blog and in personal writings eventually revived me via Capgemini Belgium (yes, still consultancy): rolling out my framework and tools, a representative in the Agile Consortium Belgium and certified as Professional ScrumMaster I at Ken’s Scrum.org.

Time to use our Community of Practice blog and a (more corporate) name: ScrumPlus. As that confirms that we do Scrum, but also more:

  • We explicitly define our engineering standards as Quality Loops;
  • We add time to (1) transform a Vision into a Product Backlog (enhance ‘Ready’) and to (2) do a hand-over to customer’s staff. But not breaking the continuity nor weakening the Sprintly ‘Done’.

I willingly admit that this is possible with ‘pure’ Scrum as well, but the ScrumPlus framework is at least valuable in the local adoption of Scrum. And in my professional and market circumstances that is a big win.

Engagement of a project manager

Is there a hidden secret to the success of software projects?

Of course there is not. No silver bullet. But often was I asked for such a secret and often have I wondered on the subject.

My My.Fragility framework grew out of an attempt to describe my recipe. And although I firmly believe in this toolbox, there is simply… more. An undefinable extra?

Intrigued by the term ‘Engagement Manager’ I ran into a great blog post that essentially states that a Project Manager must be involved in Sales. And Legal, technology, Accounting, etc. To act cross-functional.

– Hey! That’s not new. That’s my way of doing Project Management.

– Okay, okay. I understand. Finally. It’s not the traditional view.

So, there you have it. My secret. Vision and attitude. Beyond pure delivery. A continuous and steady focus on satisfying and lasting working software, beyond politics, small talk and short-term reactivity.

Dedication, engagement, commitment. The will and the force to be more than a Project Manager, to be… Engagement Manager.

Stay tuned to My.Fragility

My.Fragility is my framework of Agile practices for flexible delivery of software development projects.

  • It started in 2003 with eXtreme Programming
  • In 2004 I started using Scrum and certified as a ScrumMaster
  • I’ve always applied personal practices for fixed timeframe projects
  • To prepare projects I use a Product Backlog Estimation model
  • I track development with my Product Backlog Tracking model

I have started distributing my documentation on it, beginning with my overall presentation: My.Fragility – The Essential Scrum and beyond (handouts) (4 MB).

It includes:

  • an introduction on the general position, maturity and adoption of Agile as a software development method
  • a focus on the process of Scrum
  • the specific elements (and additions) of My.Fragility
  • addenda on eXtreme Programming, references and the roots of Agile

Find all my notes on my framework under the tag my.fragility.

Or stay really tuned via RSS http://en.wordpress.com/tag/my-fragility/feed/

Definition of… Agile Testing

Poppendieck - Implementing Lean Software DevelopmentThe book Implementing Lean Software Development (from concept to cash) by Mary and Tom Poppendieck gave me an additional perspective and language (terminology) on quality and testing, thus enriching my existing insights.

Traditional testing is focused too much on bug hunting, mostly after a development cycle and including a devious rewarding or penalty policy. There is too little attention for verification of quality while building.

The development process should be oriented towards creating quality upfront (i.e. before UAT, release or whatever post-process control), and verification during the development process. If verification reveals a defect, the ‘line’ is stopped, the cause identified and resolved.

logo-myfragilityMy My.Fragility framework holds Quality Loops. These are performed continuously and at least daily. It is based upon eXtreme Programming practices. They serve as engineering standards within the Scrum process that is at the heart of my framework. It shows our focus on quality and integrated testing:

My.Fragility - Quality Loops


A flexible approach to a… fixed price

Despite maybe chaordic circumstances, most (all?) customers are very attached to having a good upfront price indication. Even as a convinced Agilist and Scrum Practitioner I still want to serve those customers.

My My.Fragility framework tries to align both views upon a well-defined (Agile) Project Life Cycle:

During a (timeboxed) Pre-game staging effort, an initial Product Backlog is created, estimated and given a total price/elapse time (following my Definition of Agile Planning). The Product Backlog and Release Plan (split up of elapse time into monthly Sprints) is included in all proposals and contracts. It is the formalization of a mutual understanding and trust of what is included and what is not.

During implementation, the full Scrum process is applied, but the number of Story Points is kept in balance with the estimated number. I.e. when changing or adding User Stories, the priority of a comparably sized effort (in Story Points) should be adapted. And, yes, this might result in not implementing the lower priority Stories. Unless impact on timing and budget is accepted.

Keep track of the changes (delta) in a Delta Backlog.

Play the Planning Game with the customer to maintain the balance:

  • During a Sprint, refine next priority Stories and assess their estimates upon the actual knowledge
  • Let the customer decide on the selection of Stories for the next Sprint. Intervene as little as possible. Assist
  • Iterate until the selected #Story Points matches the available #Story Points

So, Agile techniques may well be used to deliver total results in a fixed timeframe, when adding the notion of Negotiable Scope.

The sizing of User Stories

My My.Fragility framework adds my insights for fixed price (-negotiable scope) projects to XP and Scrum.

I included a Product Backlog Estimation model to calculate a total price using my Definition Of Agile Planning. And on top of User Stories and Story Points the Sizing of User Stories is to be considered:

The right size of a User Story is 0,5-5 ideal days (di) (ideal time = Story Points). For development. To be invEST. To comfortably fit a Sprint.

  • Epic Stories can be 5-15 di. A size not suited for development but acceptable for estimating. To be split into User Stories.
  • Cosmic Stories are >15 di. They can serve only as a beginning to understand a Product, not for estimation or development.
  • Tiny Stories are < 0,5 di. To be combined into User Stories.

Note: ‘Minimal Marketable Features’ (MMF) from Kanban can be a set of User Stories. Possibly an Epic Story.

The best base to estimate is experience. When experience is limited, use relative estimates (complexity scaling). I use a 1-2-5 scale:

  • Size is set upon complexity to 1-2-5-10-20-50-100-… Always use the higher value if you end up in between two points.
  • Find some reference points in your experience to compare.
  • Refine until you end up with real estimates (Story Points).

note: Ideal time is development time without breaks, questions, problems or any interrupts. It is multiplied with Velocity to get Planning days.