Scrum – Beyond the ceremony of certifying

Why would you want to certify in anything Agile, and Scrum especially?

Well… you don’t. The right attitude will make you:

  1. want to learn about Scrum from an expert as a head-start for practicing it. Truly taste it by using the tool to get more Agile.
  2. want to assess your knowledge and experience.

Exactly the needs that Scrum.org is addressing. To think beyond courses. Knowledge, understanding ànd experience over paper certification, which I certainly value more:

  1. For learning purposes there is the Professional Scrum Master course, i.e. a retake of Ken’s former CSM.
  2. But there is a unique set of online assessments:
  • With the help of the communities an open assessment was created. I participated in it at the time it was still called Scrum I. It’s free of charge and you can use it as a quick check on your knowledge.
  • The level I assessment checks the fundamental Scrum knowledge (the cost of 100 $ is also included in the PSM course fee). A score of 85% is required!
  • The level II assessment requires 85% as well, which is not achievable without even more demonstrable knowledge, having applied Scrum and understanding the underlying principles. As I wrote in my blog note “Unsatisfied? Uncertified? Unvalued?“.

And, finally, Ken is assisting the development communities with the Professional Scrum Developer program, holding a course and assessments in a .Net and a Java version.

The knowledge of Scrum is verified against the Scrum Guide from co-founders Jeff Sutherland and Ken Schwaber. Capture their insights!

An highly unserved and underrated audience however are still the Product Owners, although a crucial role in Scrum. The ScrumAlliance offers a Certified Scrum Product Owner course (‘CSPO’). But… no assessment yet. I don’t want to go into CSP, CSC or CST options because I feel they are heavily over-institutionalized. CSD is too unclear.

The ScrumAlliance verifies knowledge of Scrum against the Scrum Primer, from the Scrum Training Institute. I’ve read both and find the Scrum Guide to have the in-depth Vision of Scrum, while the Scrum Primer is more about concrete practices.

Definition of… Agile

There is no final ‘definition of Agile’, no silver bullet / fits all approach. ‘Agile’ is not even one tangible method, but holds the common principles to a number of methods, that are as such stated in the Agile Manifesto.

I try to address this topic with the presentation of key characteristics. For both ‘Agile’ and traditional methods. That seems to be very recognizable.

Key characteristics of traditional methods:

  • Plan-Ceremony driven;
  • Single pass waterfall (sequential model);
  • Success = compliancy with predictive plan, i.e. end = original set destination;
    • Progress = ‘deliverables’ (specs/design/code/reviews/signatures);
    • Resisting/blocking ‘change’.

    Key characteristics of Agile methods:

    • Change-People driven;
    • Iterative-incremental process;
    • Success = delivered Business Value;
    • Progress = frequent delivery of working software;
    • ‘Embrace change’. Even encourage change!

    It is quite possible to get organized upon these general principles, and find a way through it and successfully build software. It is however a lot faster and more productive to select an existing, tangible process. Start by implementing it ‘from the book’ to get a firm grip on it. In a next step, it can still be optimized upon specific circumstances.

    And, while you’re at it, have a good look at Scrum. It is the most spread Agile method worldwide, has lots of communities with well-documented cases, is technology-independent and there are great coaches to assist a Scrum transition. A good starting pointing might be Scrum.org

    Naar geen pijpen gedanst

    Ik heb vanuit een ongelooflijke honger en met erg veel gretigheid Vaslav gelezen, de roman van Arthur Japin over het goddelijke, vorige-eeuwse danswonder Nijinski. Hongerig was ik (1) naar nieuw werk van Japin nadat zijn Een Schitterend Gebrek me zeer bevallen was. Hongerig was ik (2) omdat ik enige jaren geleden “Nijinski” heb gelezen, zijn dagboeken zoals ze ongecensureerd waren vrijgegegeven door zijn dochter. In Vaslav komen drie vertellers aan het woord. We volgen hen grotendeels tijdens die ene noodlottige, na-oorlogse dag, 19 januari 1919. De dag dat het kleine paardje, moegestreden, stopte met dansen. Door hun ogen zien we het leven van Nijinski, zoals het was, is en nooit meer zal zijn.

    Peter is de lokale bediende van Nijinksi in Sankt Moritz. Waar meneer terechtkwam nadat hij afstand nam van de wereld. Peter verbaast zich voortdurend. Door de gemoedelijke houding van meneer tegenover een bediende, diens onwereldse onbeholpenheid, de wereldse verhalen uit meneer’s vorige leven. Hij is ook de eerste die het verval opmerkt van de geest van de danser. Omdat hij het al eens meemaakte. Bij dat andere, echte genie, professor Nietzsche. En altijd maar op dat uurwerk kijken.

    Het verhaal van Peter loopt over in dat van Sergej Pavlovitsj, Nijinski’s grote ontdekker en minnaar. Diaghilev. Eigenaar en bezieler van Les Ballets Russes. In de steek gelaten door Vaslav voor… een vrouw. Pulszky Romola -de derde vertelster- baande zich geduldig een weg tot bij de sterdanser. Die niet alleen met haar huwde maar er ook een kind bij kreeg. De onmacht van Diaghilev, Vaslav was zijn grootste creatie èn zijn grootste mislukking. Maar nu heeft het serpent van een moeder van Romola net hèm een uitnodiging bezorgd voor Nijinski’s oorlogsdans.

    De doorlooptijd van het boek is… 1 dag. Maar naadloos wordt door de 3 vertellers de volledige levensloop van Nijinski in beeld gebracht, via flashbacks, mijmeringen en gedagdroom. Een vertelmatig hoogstandje. Maar echt aangrijpen deed het boek me pas bij het verhaal van Romola over hun oorlogsjaren, in Hongarije. Na de lange jaren reeds van Vaslav’s stilzwijgen, inzinkingen, zijn opnames die hem alleen maar verder doen wegzinken. De vreselijke tussenkomsten van haar moeder ook.

    Enige gelijkenissen met Een Schitterend Gebrek zijn Venetië, de prachtige schets van romantiek beleefd in harten, het complexe effect van die romantiek ondervonden in levens. Maar de diepgang is toch net dat beetje minder. De fascinatie en enthousiasme voor het onderwerp lijken me wat voorrang te hebben gekregen. Maar in het hoofd kijken van de voor eeuwig zwijgende Nijinski blijkt toch moeilijker dan bij de voor eeuwig gebrandmerkte vrouwenveroveraar Casanova. Net wat gebalder had niet misstaan, alhoewel het mij persoonlijk niet stoorde. Vanwege mijn fascinatie en enthousiasme voor het onderwerp allicht.

    Als u me nu wil excuseren, ik wil de dagboeken herlezen. De woorden van lettermeester Japin afwegen aan de woorden van de dansmeester zelf…

    Dancing on hallowed grounds / Dancing Nyjinsky style (Bauhaus – Dancing)
    I’m a muscle in plastic / Nyjinsky’s bad move
    (Bauhaus – Muscle in plastic)

    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.

    The upstream adoption of Scrum

    Since 2003 I have successfully applied Scrum in various projects and introduced it in organizations. All on my local market, Belgium. Since 2010 I also promote adoption 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 don’t always have complete control over the delivery process. 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-organizing, being a facilitator, removing impediments over being prescriptive, establishing a close relationship with Business, promoting on-site cross-functionality, using visible information radiators and high transparency. All consolidated in my Product Backlog Tracking model upon Sprints and Burndowns.

    In the absence of outspoken Scrum, even such stealth application of it results in on-time and on-budget delivery and higher satisfaction. And it makes projects fun again. No surprise that the downstream adoption, i.e. by Teams, end-users and business representatives, is generally huge.

    Although good figures are generally synonymous for upstream ‘success’, the Scrum process and its essential 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 are 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. It’s less intrusive, but the leverage of lasting advantages, hyperproductivity, is underused. But I still wonder how to articulate about Scrum more clearly without losing commercial opportunities.

    And 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.