Tag: My.Fragility

Posted on by — 2 Comments

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.

Posted on by — 1 Comment

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.

Posted on by — 1 Comment

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.

Posted on by — Leave a comment

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/

Posted on by — Leave a comment

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


Posted on by — Leave a comment

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.

Posted on by — Leave a comment

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.

Posted on by — Leave a comment

Definition of… Story Points

I have combined personal insights for fixed price (-negotiable scope) projects with practices from eXtreme Programming and Scrum in my My.Fragility framework.

The main estimation steps from the framework’s Product Backlog Estimation model were highlighted in my Definition Of Agile Planning. But the model also implies at least an understanding of some definitions.

After my definition for User Stories here’s how I use Story Points:

  • Story Points equal ideal time (“ti”). But using ‘Story Points’ might prevent people from confusing it with realistic time. The eXtreme Programming notion of Gummy Bears (“Bg”) might be a bit too abstract, although it’s fun to use.
  • Ideal time is the development time for a User Story without breaks, questions, problems or interrupts of whatever nature. Spending every minute of every working day on productive coding.
  • Ideal time is mulitplied with Velocity (“v”) to estimate Planning time (“tp”). In my experience, an overall velocity of 2,5-3 results in a realistic number of planning days.

planning time (“tp”) = ideal time (“ti”) * Velocity (“v”)

  • An alternative definition of Story Points is the number of productive coding hours per day. This is generally accepted as maximum 5-6. Velocity is then expected to be around 1,33.

Note I generally apply an overall Velocity to all User Stories, although my model allows a specific Velocity per User Story, e.g. depending on the expected complexity.

Posted on by — Leave a comment

Definition of… User Stories

Over various projects I have applied a set of Agile practices from eXtreme Programming and Scrum. Adding personal insights to specifically handle fixed price (-negotiable scope) projects resulted in my My.Fragility framework.

The framework includes a Product Backlog Estimation model, for which the main estimation process steps were highlighted as part of my Definition Of Agile Planning. Furthermore does the model at least imply an understanding of my definition of a User Story:

A User Story describes a feature from an end-user perspective. It is independent of software layers or parts of the project

A User Story can be explained as an essential Use Case

A User Story should be INVEST to be ready for development

  • Independent: User Stories have as little interdependence as possible. Resolve it by putting related Stories in the same Sprint
  • Negotiable: a User Story is an invitation to discuss implementation. The best design and code result from communication!
  • Valuable: a User Story represents effective business value for an end-user
  • Estimatable: the size and knowledge on a User Story is sufficient to reliably estimate the Story
  • Small: a User Story is small enough to be estimated, developed and tested. It is comfortably realizable in one Sprint
  • Testable: a User Story has a clear result that can be tested
Posted on by — 1 Comment

eXtreme Programming Revisited (part III)

Extreme Programming InstalledWhen reviewing Chet Hendrickson’s paper on the evolution of Extreme Programming practices, I was surprised that he completely ignored Kent Beck’s revision of 2004. As does Ron Jeffries’ practices representation, by the way.

Ken Beck - Extreme Programming Explained5 Years of eXPerience resulted in a complete revision of Extreme Programming Explained. The general tone softened, partial adoption became acceptable and the practices were extended, and divided into primary and secondary practices. Maybe Kent considered XP as under-adopted, but I missed the strong and ahead leadership from v1. No compromise. Working software is the goal. Extreme focus. Programming is the way.

I also felt that in the v2 edition, good ideas were introduced, but good practices were also replaced. Because I instantiate Scrum’s engineering standards with logo-myfragilityXP practices in my framework My.Fragility, I decided to merge the best of both:

My.Fragility Grafx - XP Practices

Note: when checking the original Extreme Programming Installed book myself, I wondered (after all these -6- years!) why it did not mention the Coach role. When moving to Scrum after our ‘pure’ XP application, I kept promoting this role. I still do in my My.Fragility framework (on top of Scrum’s Product Owner, Team and ScrumMaster).

And I still don’t known why User Stories was not an explicit XP practice from the beginning…