Tag: Scrum

Posted on by — 1 Comment

Adding people to a project

I don’t align with Fred Brooks’ Mythical Man-Month, and certainly not with his law, “Adding people to a late project only makes the project later”.

I asked Jeff Sutherland about it at our Agile Consortium Belgium in April 2010. Jeff demonstrated with data from major projects that Brooks’ law is plain wrong, that adding people can positively affect productivity.

In September 2010 I checked it with David J Anderson at a Kanban training I followed. He went through the roof because of such ‘laws’ that haunt our profession and also had the data to disprove Brooks’ law.

Well-oiled Agile Teams take in new Team members without a productivity relapse. Thanks to iterative-incremental processes and technical practices like Test-Driven Development, Pair Programming and automated integration and regression testing (aka ‘Continuous Integration’).

Proven experience

Beyond my personal conviction I then realized I’ve proved it myself. At an atom sized scale compared to Jeff or David J, but still…

My Team was responsible for the core (Java) application of a large media platform (digital tv), centralizing business logic and system interfaces. A major new Release was to be developed from October to December 2004. Our pre-game investigation had turned out this to be feasible.

Despite frequent reminders, important prerequisites were not met, limiting our Velocity. Beginning of December I announced an extra Sprint (January 2005). Unhappy and angry customer. Although settlement of our needs was still too late I didn’t want to be the showstopper again. And decided to add people… shown in this weekly chart:

But… productivity increased and we finished in time, as is shown on our Product Burndown chart:

Looking back, all parties around the table in December must have been very happy with ‘our’ delay. Because we were the only ones that delivered end of January… Customer happy. With a great recommendation.

Posted on by — Leave a comment

The upstream adoption of Scrum

Since 2003 I have been involved in successful implementations of Scrum, through various projects and in different organizations. This was primarily on my local market, Belgium. Since 2010 I started promoting adoption of agility through Scrum beyond my professional consulting activities, as board member of the Agile Consortium Belgium.

While worldwide the Agile portfolio is going through the Bowling Alley and Scrum is emerging as the Gorilla, my local market seems to struggle to even cross the chasm. One of my re-occurring findings is the lack of upstream adoption of Scrum. I consider it a major impediment.

Retrospective of a Belgian ScrumMaster

In my position as consultant I rarely have complete control over the delivery process, and even the decision to actually call it ‘Scrum’, let alone full-scale adoption. But the least I always do is master a project instead of manage it as a traditional command & control-like dictator. I refer to it as my Scrumitude: iterative phasing with end-of-iteration demo’s, mastering a Team into Sprint Planning and self-organization, being a facilitator, removing impediments over being prescriptive, establishing a close relationship with the Business, promoting on-site presence of cross-functional team skills, using visible information radiators and high transparency. All information gets consolidated in a Product Backlog Tracking model I created. The actual course of Sprints and the reality of what the Burn-downs show is used to continually adjust expectations, for better or for worse.

In the absence of outspoken Scrum, even such stealth application of Scrum results in regular, often perceived as on-time, and on-budget, or better high return delivery with higher satisfaction. And it does make projects fun again. No surprise that downstream adoption of Scrum, i.e. by Teams, end-users and business representatives, is generally huge, outspoken or stealth.

Although good figures and great, highly visible results are generally synonymous for upstream ‘success’, the Scrum process and its essential causal part in this success seem hard to capture and to accept for many old-skool commandistos.

  • The first upstream obstacles are lower level management that likes to operate below corporate radars. They object the transparency and visibility as they feel personally less beneficial on the ‘success’.
  • The more upstream levels don’t care about the process, just about the figures. In the best case they tolerate a deviant process. An unpredictable and unreliable base for deeper transition.

What we need is active and explicit upstream support and promotion. Think about operational management (‘pure’ IT), sales divisions, delivery managers and hierarchical management.

Confessions of a Belgian ScrumMaster

The success of stealth Scrum is limited because it disguises the essential change. Stealth Scrum is certainly less intrusive, but the leverage of advantages and benefits that will last, is generally wasted. As a consultant it remains a struggle to articulate about Scrum more clearly without losing commercial opportunities.

PSMIIAnd a tedious effect is that people start instructing me with their fantasies on Agile/Scrum. Which is not why I re-entered the world of Scrum and greatly engage in Ken Schwaber’s Scrum.org. And decided not to let the momentum pass this time. And became Belgium’s first PSM II (in August 2010).

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