Worrying interpretations of Scrum

At an Agile event I attended recently the speaker surveyed the audience about the 9 elements that form Scrum. My suspicion was immediately raised with mentioning of “9”. It only got worse when the speaker came up with:

Definition of Scrum (9)

It got me wondering how many misconceptions of Scrum can be expressed in no more than two minutes:

Definition of Scrum (9?)

I was hoping that by now (2016), and certainly given the availability of the Scrum Guide (since 2010), the basic understanding of Scrum was better.

What worries me the most however is not the formality of the wrong and missing elements, but how this reflects an ineffective use of the Scrum framework, a limitation to how Scrum supports teams in creating great software products:

  • Accountability over the self-organized creation of Increments belongs to the Development Team as a whole. Synergy is key, not individualism.
  • Transparency is optimized when Product Backlog holds all types of work and requirements for the product. The format and syntax of Product Backlog items is open for the teams to decide over. User Stories are certainly not mandatory.
  • Burn-down charts were removed as mandatory from Scrum some years ago. It was replaced by the expectation that progress, regardless the format, is visualised on Product Backlog and Sprint Backlog.
  • If Scrum was to be reduced to one purpose, and one purpose only, that is the creation of a releasable Increment in a Sprint. It is the basis of empiricism, of business agility. Imagine my surprise that this was not even mentioned, THE core purpose of Scrum.
  • Scrum has no prescription that the Daily Scrum needs to happen standing up. Scrum’s interest is making sure that the team’s progress toward the Sprint Goal is inspected on a daily base, in order to allow the team to adapt.
  • The Sprint Review is a collaborative event at which the Scrum Team and the stakeholders work together, and identify what is most important to work on next. Adding input from the stakeholders to the inspected, current state of the software (via the Increment), improves that decision. It is so much richer than a demo.
  • All events in Scrum are contained within a Sprint. Sprints take no more than 30 days, and often less. Not mentioning the Sprint as such (container) event might allow to overlook that aspect.

Definition of Scrum (11)


Most Appreciated Releases 2015

The albums released in 2015 that kept endlessly repeating in my head and my player the most often were:

Editors - In Dream
Killing Joke - Pylon
Faith No More - Sol Invictus

Florence + The Machine - How Big, How Blue, How BeautifulRaketkanon - Rktkn#2Dez Mona - Origin


  • With the In Dream album Editors have gone to a seemingly small-scale sound. Until one starts discovering the layers, the sounds, the interwoven patterns. They seemingly picked up where they left off with the slightly disturbing (and pretty electronic) In This Light and On This Evening. It seems they had to go through their identity and personnel crisis with The Weight Of Their Love. Which re-established them as a band. Allowing them to move towards In Dreams. In Dreams has a bonus disc, Phase 2. The bonus songs add depth to the regular album. It is indispensible.
  • Coleman, Jaz - Letters From CytheraWith the Pylon album Killing Joke produced another greatly balanced work in the original line-up. Maybe less indispensible, but the bonus disc widens the album’s horizon even more. What helped me personally in appreciating the album, but also the band’s complete back catalogue, was reading Jaz Coleman’s self-published book Letters From Cypher. It shows the unified life of the band, against its founding, its history, its coming and going of people, its relative stability, its philosophical foundations, the joker and the back jester.
  • After the return on stages around the world several years ago, Faith No More confirmed their musical status with the great album Sol Invictus. The album demonstrates their grand and fluent mix of pathos, lyricism, hard rock, funk, engagement.
  • If you didn’t like Florence + The Machine before the crisis that knocked out Florence for a while, but helped her look for exotic places to record How Big, How Blue, How Beautiful, you won’t like her/them now. I guess. But if you did like her/them before, you will do even more now.
  • Many bands are into the Steve Albini (and Shellac) musical school of directness. Fewer get Steve Albini to produce their album, and release an album that is not a copy-paste, but shows identity, is powerful and totally true to the band’s proper musical identity. It’s what Raketkanon did with their second album Rktkn#2.
  • For too long, Dez Mona is being ignored by the masses, mistaken as they probably are because of the -agreed- somewhat cultish image that singer Gregory Frateur has. The Origin album shows a very diverse side to the band, but also a very sophisticated side, very rhythmic, very passionate, but never over the top. Time to get some recognition.

The Agile Paradigm (who said it was going to be easy?)

Grafx - Paradigm shift (Industrial)The domination of software development by a paradigm of industrial views and beliefs, a copy-paste of old manufacturing routines and theories, got us in a crisis. The attempts to overcome this crisis by fortifying the industrial approach are without result. The flaws and problems are huge, known and well documented. The crisis largely continues to this day.

Grafx - Agile ParadigmThe seeds of a new world view were already sown in the 1990’s, and resulted in 2001 in the formal naming of ‘Agile’. A turning-point in the history of software development. A new paradigm for the software industry was born; a paradigm that thrives upon heuristics and creativity. A paradigm that restores the respect for the creative nature of software development and the intelligence of its practitioners.

Yet, many say that Agile is too radical. They keep propagating, to this day, a gradual -if any- introduction of Agile practices into existing, traditional processes. Having witnessed several of such attempts, I am extremely skeptical about such a ‘gradual’ evolution, a slow progression to the Agile paradigm. Because:

  1. A gradual evolution only scratches the surface. New names are installed, new terms, tools and techniques imposed, but the fundamental thinking remains the same.
  2. The mentioned paradigms consist of fundamentally different concepts and ideas, and many are mutually exclusive. No meaningful introduction of Agile practices in an industrial paradigm is possible.

A gradual shift is factually a status-quo. The industrial paradigm remains. A permanent crisis is called upon us.

It requires honesty to accept the mismatch of the old ways, and courageous leadership to embrace the new ways.

Abandoning the old thinking will take time. Scrum helps. Its distinct rules help in getting a grip on the new, Agile paradigm. The limited prescriptions allow immediate action. They allow developing new ways of working; through discovery, experimentation-based learning and collaboration. It is worthwhile the giant leap.

I wish you a 2016 of determination and improvement. I congratulate you with the hard work you will have performed in a year from now.

(Note: much of the above was copied, with some editing, from my book “Scrum – A Pocket Guide“, providing context to my description of the Scrum framework, its rules and roles, and their purpose)

A Long Way to the Light

When, at the age of 16 (1986), I started going out, a lot of people around me were seemingly seeing the whole of the moon. I didn’t. I even managed to ignore The Waterboys for the full first 2 decades of their existence. My ignorance was brutally ended in 2000 when being fatally attracted by the electrifying album A Rock In The Weary Land. Lucky me. A great journey of revelations started, greatly supported by the re-releases of all their early, and very fine albums.

Mike Scott - Adventures of a waterboyIn 2013 we had set out to go see them wandering boys live in Antwerp in August. Shortly before that very non-disappointing appointment a tweet by Belgian rock journalist Bart Steenhaut pointed me to Mike Scott‘s autobiography Adventures of a Waterboy. I took it with me to read on our yearly family holidays, to be better ‘prepared’ for the live gig, to have a better understanding of the man we were going to witness on that stage. In my imagination he was a wild man, a shamanist, and totally music. Would he actually be such, I wanted to find out.

What a revelation the book turned out to be!

I soon fell for the honest and open tone, the eloquent language, poetic like the lyrical foundation of his songs. I felt the man’s excitement in every page, even when going through the dreary moments of his career, the months and years of searching. I liked how he, almost casually, pictured the occasional lack of discipline, the quarrels with managers and producers, the quests for band members to record albums with or go on tour.

There are a couple of lady stories, but they always serve some musical purpose. The stories are relevant, musically. My heart broke over the heartbreaks and the various friendships, established, broken, lost, fixed. But then again, also in this domain, at the heart of the story is always the Music, Big or small (or both), folk or rock (or both).

The book obviously has quite some room for the becoming of Fisherman’s Blues (1988), without doubt their most known work. In great detail the emergence of the album is described, with its many back and forth movements, the declines and the falls, before and during its making, before and after its release and the touring. The reading takes the reader beyond the endless changes of names and the special, sticky relationship with Wickham and Thistlethwaith.

What I did miss was some deeper backgrounds on the becoming of the first 2 albums, The Waterboys (1983) and A Pagan Place (1984), 2 albums I still hold very dear. Overall I felt there is a sort of gap between Mike’s early teen and high school years and This Is The Sea (1985), the finality of the Big Music.

But, no worries, Adventures Of A Waterboy is a highly fascinating insight into some decades of musical adventures, a journey full of exploration, whether actually inside or outside of the music industry, always about music, at least in the end always pointing the man back to music. The book offers a look behind the scenes that goes way beyond the superficial glamour and public perception. It also shows the persistence, the hard work that is required on top of the talent. The work illuminates Mike’s brainwaves and how they helped him shift worlds, from the early years of aspiration to the rock business to the spirit of the Celts and the god Pan.

Adventures Of A Waterboy turned into one of those rare books that lifted me with my feet from the ground and transcended me completely to the described places and times. With its colourful descriptions of landscapes, cities, venues, islands, rooms and places. Enticing. A mesmerising journey through ink, letters, words, pages.

As a music-affinate reader I really got dragged into some threesome decades of up and down emotions of the passionate wanderer that Mike Scott seems to be. He gave me an insight into his life with the spirits; the spirit of the Big Music, the spirit of Pan, the spirit of Celts, the spirit of light and Love, the spirit of the mysteries, the spirit of outerworldly muses, gnomes and elves. I was energised by the man’s will, his drive, his ambition. All for greatness. Through the book I sensed a seeker, one who will never stop seeking, meanwhile adding characters to draw from, a shape-shifter swiftly moving between worlds. He is a wild man. He is a shamanist. But -above all- he IS music.

Intuitively I stopped reading when entering chapter 15, “The Philosophy Room”, and listened to the song Long Way To The Light first. After the chapter, I stopped again and listened to the full album Bring ’em All In (1995), one of Mike’s solo albums, before continuing my read. It helped me get this era of his life much better. It helped me understand that one sometimes has to keep up, slowly putting one foot in front of the other, do what one does best.

Mike Scott - Adventures of a waterboy -RugAlthough first published in 2013, these Adventures Of A Waterboy are not described beyond 2001-ish, shortly after the release of A Rock in the Weary Land. And that happens to be the time where I strangely picked up. I haven’t stopped following them since then.

I have enjoyed this autobiography the most because it’s an authentic story, all included, the better and the worse, of an artist and his music. No gossip. No dirt. No ego. Just music. And the god Pan. One of the better musical (auto)biographies around.

“Accepting the work product”

“Accepting the work product” is a respectable expectation for a Product Owner. It sounds off and scary but I should add it to my Product Owner role summary.

In a worldview rooted and drenched in hand-overs, separation and blame, anything related to ‘acceptance’ triggers negative sentiments. It brings back memories of rejection. We recall the resentment we felt every time we were blamed for the past and for past actions taken without any room left or given to remediate.

In the iterative-incremental continuum however there is only one way, and that is FORWARD. GO!

The Product Owner identifies and expresses the hopes and desires for the currently most important work. The Development Team acts on these hopes and desires and creates a Done Increment in no more than 30 days, and often faster. The Product Owner accepts the resultant work product against the ultimate goal to discover what is most important to do next with the key stakeholders present.

In my book “Scrum – A Pocket Guide” it is summarized as follows:

The collaborative Sprint Review provides the Product Owner with the best possible information on which to decide whether the Product will be shipped, and how additional Sprints can further improve the value of the product taking into account a balance of risk, effort, budget and cohesion. (p. 53, chapter 2.5.2 “Time”)

There is no absolute guarantee that reception of the presented work product makes a happy Product Owner. However, a Product Owner not being happy with the work product is not the same as the Product Owner rejecting the work product. There is no rejection. There is but one way, forward. Go!

Looking forward the Product Owner might:

  • Not release the Increment
  • Update Product Backlog to better reflect his/her intents
  • Have the work re-done via an updated Product Backlog
  • Decide to increase her/his participation in the creation process
  • Look to increase business skills in the Development Team

I sure hope the Product Owner keeps in mind a close collaboration with the Development Team, as summarized in my book “Scrum – A Pocket Guide“:

Although a Product Owner may have various strategic product management tasks outside of the Scrum Team, it is important that the Product Owner actively engages with the other players of the team regularly and repeatedly. (p. 48, chapter 2.5.1 “Players and accountabilities”)

And, eventually, a Product Owner might not fund a next Sprint or release.

Product Backlog Upholds Transparency

The software development industry has long suffered from a dogged obsession with identifying, checking, detailing, double-checking, describing and documenting perfect and complete sets of requirements before allowing ‘development’ (typically only the coding or programming part of it) to start. Typically such a requirements phase consumed vast amounts of valuable energy, time and budget, causing gigantic delays before the core work of software development even begun. Besides this trauma, such a requirements approach often caused what became known as ‘analysis paralysis’. The obstinate desire for perfect requirements completely grinded projects as an overwhelming amount of information was collected, along with the abunding amount of requirement interconnections. We lost overview, we certainly couldn’t document it anymore, let alone explain it and get a sign-off. The insurmountable information overload caused a hard stop. Basically, projects already got off track during this preparation phase, got beyond recovery and were canceled before the real work could start.

All energy was spent on what in the end is only an intermediate deliverable. The requirements turned into a goal in themselves. It was ignored that only during implementation the real discovery of what works and what not works happens, when functional options are validated against technology and turned into usable versions of product. And, ultimately, real progress of any software product development effort is in working software, versions that can be released to and be tested by users.

This is reflected in the value statement of the Agile Manifesto:

“Working software over comprehensive documentation.

as well as in one of the 12 Agile principles:

“Working software is the primary measure of progress.”

Scrum implements this through the demand to have Done Increments of software by the end of every Sprint, where a Sprint takes no more than 30 days, and often less.

This demand supports breaking away from the false illusion that there is a direct correlation between the perfection of a set of requirements and the value of the software produced. There is no such cause-effect linearity. The chance of success of a software development endeavor is not linearly related to the level of detail, documentation and completeness of its requirements. Any requirement, no matter how well documented and agreed upon can still become obsolete, its content may change, its appearance when coded may differ or its delivery may not result in the expected value and satisfaction. Regardless how well it was thought through in advance, documented and agreed upon.

Despite the adoption of Agile frameworks, and the widespread adoption of Scrum in particular, we have a long way to go.

In many environments, as part of what is called ‘Agile’, requirements are now captured as User Stories, sometimes even on index cards. However, the hidden desire for perfection hasn’t changed. The belief that more detailed requirements will lead to better software remained intact. The courage or insights to acknowledge that progress is not measured on intermediate artifacts is missing. The ‘analysis paralysis’ phenomenon is replaced by a ‘story card hell’ [1]. Efforts are undertaken to collect all stories that can possibly be thought of, and for all stories identified, attempts are made to have every detail documented, in a tool or on its index card.

The format has changed, the obsession with perfect requirements hasn’t.

In the system called ‘Scrum’ one, and only one, source of input is defined, Product Backlog.

Closed Loop Feedback (Scrum)

All work for a product is captured in such Product Backlog, regardless whether the work is performed as a ‘project’ or not.

Product Backlog management in the empirical process that Scrum implements, holds that items in Product Backlog are added and changed as more is learned from the actual work. There is no need, nor a demand to have a full Product Backlog in place before development can start. A Product Owner having sufficient trust, ideas and funding often even provides the best starting position for innovation and new product development.

Product Backlog is incrementally managed:

  • Ordered against time (for assumed value). Understanding that value remains an assumption until the work is released.
  • Gradually decomposed.
  • Regularly refined, cleansed and updated.

Product Backlog refinement

Scrum prescribes no specific format or tools for a Product Backlog, or the items on a Product Backlog. Scrum certainly has no obligation to use the format of User Stories for all items on the Product Backlog.

Product Backlog serves transparency.

Product Backlog is expected to hold all types of work required to deliver or enable delivery of releasable Increments of product by the end of every Sprint.

Although Product Backlog might hold references to other sources and deliverables, in itself it remains the single source of truth.

Scrum’s principles and rules may not create a requirements paradise, but as a framework it allows finding distinct ways to deal with requirements in a way that overcomes ‘analysis paralysis’ without ending up in a ‘story card hell’. Keeping Product Backlog minimal and removing items (the tea leaves effect) is probably the most overlooked Product Backlog management strategy, yet it will get you a long way. Progress is measured and visualized, Sprint by Sprint, upon Product Backlog converted into Done Increment and the new insights applied on open Product Backlog.

Still. I see the challenges.

We can do better a job providing inspiration to enact the simplicity of Scrum to better deal with complexity. We haven’t been clear enough in helping teams, organisations and Product Owners more effectively utilise Product Backlog, one Product Backlog.

The challenges in the more effective utilization of Product Backlog are to start using Product Backlog to decompose from goals, objectives, functions and domains to actionable work, certainly in scaled implementations of Scrum. Or to use Product Backlog to create value and impact, while managing dependencies. To use Product Backlog to forecast, create product roadmaps, align work with other products and report on progress, budget and value. To use Product Backlog at the program and portfolio level.

Product Backlog can serve these purposes. We could have made people be aware of it more.

Product Backlog is open to adding metadata and properties for and grouping notions of Product Backlog items. Such additional metadata allows creating different views into Product Backlog while upholding one Product Backlog as the single source of truth, while upholding total transparency. Transparency is not upheld through an immense inventory of requirements with an immense inventory of detailed descriptions, not even in one Product Backlog, let alone spread across separate whatever-type-of backlogs.

Many techniques and practices exist surrounding Product Backlog. They might require their own artifacts, yet they cannot replace Product Backlog.

Product Backlog serves to uphold maximal transparency in product development when employing Scrum. Product Backlog, in the end, is all the plan you need.

[1] The term ‘story card hell’ was first used by James Shore, in a 2005 presentation, http://www.jamesshore.com/Presentations/Beyond%20Story%20Cards.html