Tag: Scrum

Posted on by — 2 Comments

Is that a gorilla I see over there?

A topic that I frequently run into at customers is the maturity of Agile. I usually present my matching of ‘Agile’ on the Technology Adoption Life Cycle with the Hype Cycle for Application Development. To show the evolution of Agile, and its outgrowing of the stage of anecdotal evidence.

Specific to the Technology version -for new high-tech paradigms- of the Adoption Life Cycle is the chasm, introduced by Geoffrey Moore. A phase of stagnation between Early Market and Bowling Alley. Of unpredictable length. And some products even never get out of it. Scary.

In the post-chasm period the viable market forms, and a gorilla rises, an absolute market leader. Alternatively the market leader may turn out to be ‘merely’ a king, much more vulnerable to being overthrown.

An important and disruptive innovation in itself, Agile is past the chasm. It’s probably in the Bowling Alley, maybe approaching the Tornado. At the same time Agile processes are applied to develop products that are subject to the (T)ALC. Best fit because there’s no time to stabilize into Main Street. And Agile offers just that flexibility while assuring a return.

At the same time I observe the increasing number of Agile players that is referencing Scrum. Practitioners, trainers, thought leaders, customers, etc. On blogs, forums, in trainings, papers, etc. You name it. Positively (“this is great, we also do it“) or more disapproving (“this doesn’t work, we do it like this“). Although personally convinced that they’d better highlight their own methods’ merits and strengths, I don’t oppose to it.

And Scrum prospers from it. Free publicity and a trigger to keep moving. I see evidence of the latter in the rise of Scrum.org. More community oriented as an alternative to the ScrumAlliance institute will it open the Scrum offering to a wider audience.

But it gets very uncomfortable when it gets personal. Quite vicious attacks are regularly launched at the persons behind Scrum and the people doing Scrum, away from the value of the framework.

Maybe that is exactly the indication that Scrum is indeed emerging as the gorilla of the Agile methods pack…

Posted on by — 5 Comments

Unsatisfied? Uncertified? Unvalued?

When I announced having passed the Professional ScrumMaster II assessment (including getting certified) the reactions were -to say the least- mixed. People I have effectively worked with sent me warm congratulations. People more distant to me seemed more cynical and skeptical. Time to set free your psychoanalytic ambitions!

I partly share the cynicism, skepticism and unbelief with regards to certification in general in our world of IT, consultancy and software development. But a little common sense makes one don’t consider certification solely, but experience, attitude and personality as well.

I know that calling people Certified ScrumMaster (CSM) after merely attending a 2-day course isn’t too credible. Can I say to my credit that it was 3 days when I did it in 2004? But that was then. Nowadays the ScrumAlliance requires participants to do an online CSM evaluation.

And it doesn’t justify any reservations on the PSM program!

Last year, Ken Schwaber and the ScrumAlliance parted and Ken started Scrum.org (for a couple of reasons). He developed new and updated programs upon effective knowledge assessments. Jeff Sutherland and Ken updated the Scum Guide. To form the Scrum Body of Knowledge.

The Scrum Open Assessment was created incrementally with feedback of the community and serves as a check-up on the subscriber’s knowledge. No medals attached, just knowing where you stand.

The Professional ScrumMaster assessments are not open, but require payment. Luckily, payment is no guarantee. You do not just pay to get a certificate. You obtain 85% or more. Scrum.org has no benefits in creating an unnaturally large amount of PSM’s.

  • PSM I is about knowing how the game should be played. Limited pretensions. It’s also included in the fee for a PSM course, the follow-up to Ken’s original CSM. So it is not just about the money.
  • PSM II is about understanding and applying the underlying principles. Answers that cannot be found directly in the Scrum Guide. Often demanding multiple options with (dis)advantages.

So let no general skepticism stand a correct judgement of the PSM assessments in the way. They emphasize on demonstrable knowledge, over paper certification, which I certainly have come to value more. Reason why I am proud of my PSM II. Though that won’t stop me from being pig-headed in my way of mastering people and projects…

Note: The Professional Scrum Developer (PSD) is an innovative program on software development using Scrum. Resembling my Quality Loops?

Posted on by — 6 Comments

Professional Scrum Master II

I consider myself not only an early follower of Ken Schwaber’s Scrum.org but also a mental companion on his new journey. Must have to do with the fact that I obtained my Certified ScrumMaster from Ken in 2004 in Brussels and am still fascinated with his straight-forward views.

Despite my (pragmatic) use & application of Scrum since 2004 (and eXtreme Programming since 2003) I was hesitant to take the Scrum.org assessments. Hesitant, as in opposed to arrogant.

But… Open Scrum went well (Jan 2010), as did Professional Scrum Master I (Jun 2010). The biggest doubts however I had about the Professional Scrum Master II, frightened by the essay-like topics. But I leaped and took the exam. On 26 August. The start of 2 nervous weeks of awaiting the result. To receive my certification… hooray indeed. #27 worldwide.

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 — Leave a comment

Scrum Level I

A while ago Ken Schwaber founded Scrum.org, a new platform to discuss and promote Scrum. I enthousiastically registered and took the Scrum Assessment. And contributed in spreading the news.

Although my personal score (86%) did include some stupid errors it seems that, from the overall results, it is quite good. Well above the required 75% anyway to be Scrum Level I (since Wed 14th Oct 2009).

Posted on by — 7 Comments

Definition of… Scrum

Is there a way to check on the correct application of Scrum?

Most attempts end up in complex questionnaires or big assessments. This is strange as Scrum is a simple process and has distinct definitions of roles, artefacts and meetings. And I also distinguish core principles.

When presenting Scrum as the core process of my My.Fragility framework I always show my Scrum Diamond, a graphical representation of the 3 essential elements for each of the 4 Scrum ceremonies:

It makes an assessment of Scrum simple: check whether the process and the above ceremonies are in place!

And remember: Scrum prescribes a minimal, but tightly coupled, set of ceremonies. Skipping even only one implies affecting the essence of Scrum. Doing so does not necessarily mean that you are not Agile or don’t perform well, but don’t call it… Scrum.

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.