Posted on Leave a comment

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.

Posted on 2 Comments

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

Posted on 1 Comment

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.

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.

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

Posted on Leave a comment

Unwritten futures will unfold (adventures in Scrum)

At some occasions we stop to look back. It happens rather irregularly in my life, although regularly in Scrum. We see the trail we left behind. We notice landmarks, missed chances, forgotten events, achievements. Small or big. We cherish that we cannot undo it. And we look ahead of us, and think of the paths we might create moving forward understanding that our current actions continually determine our future.

Looking back, two fairly recent, symmetric landmarks stand out on my trail of Scrum created since 2003:

Looking back, I am humbled by the opportunities to travel, to speak, to think, to write, to publish a book, to collaborate with people across the globe. I thank anyone who crossed my path, regardless how they chose to interfere with me.

Just for a split second, I pride myself for having gone my ways, having made my choices. In that split second I see some impact on people, on individuals.

Looking forward, I shiver and doubt takes over again. I embrace the solitude that is often my companion and look forward to the future that, to date, is unwritten. There are many unknown futures that can unfold. In a short flash I realize that there are probably much more options than I know of. There are more paths than I can possibly identify.

Although the future will be nothing like the past, it’s fair to assume that my journey ahead will keep including Scrum. The exact directions however…

We can become what we don’t know we want to be.

Posted on 7 Comments

Sprint Cadence at scale

A system called ‘Scrum’

Scrum is founded on empirical process theory. Scrum implements regular inspections and adaptations in a closed-loop feedback system to deal with unpredictable events, changes and circumstances. The output of the system is used to be compared against new or updated input in order to update the output.

Closed Loop Feedback

The input to the system of ‘Scrum’ is Product Backlog. The output generated defines the core purpose of the system, i.e. the availability of a Done Increment. The time of one cycle to create such a Done Increment, which can be used as input for a new cycle, is limited to 30 days, and often less. Such a cycle is called ‘Sprint’ in Scrum.

Closed Loop Feedback (Scrum)

Technically Scrum has 2 elements of feedback being fed into the next cycle, i.e. the results of the inspection of the product at the Sprint Review (the Increment) but also the inspection of the process at the Sprint Retrospective. The system internally implements an additional, daily inspection and adaptation at the Daily Scrum to assure the best possible progress toward creation of a Done Increment.

Done (of an Increment) reflects releasable. Every Increment has all the qualities that make it fit for use. Whether it is actually released is a separate decision, but it has no impact on what defines “Done.”

One Scrum Team

When one team develops and sustains a product through Scrum, their ability to create releasable Increments might depend on the availability of skills within the team, access to tools and infrastructure, and dependencies within their one-team system. They self-organize around the inner-team dependencies, their Scrum Master works hard to (help) remove the other.

Scaled Scrum - Singular Scrum

Sprint length is set to the right frequency to enable learning (and incorporating new insights in the next Sprint) about:

  • How valuable the product actually is,
  • The fitness of the applied technology,
  • Current market changes.

A few, or more, Scrum Teams

When a few teams are developing and sustaining a product though Scrum, additional complexity comes into play. Additionally the teams face cross-team dependencies to produce releasable Increments, where releasable includes integration. This results in the need for additional communication and alignment. It explains why velocity, the measure of producing releasable software, of a team working stand-alone is always higher than the velocity of that same team in a construct of multiple Scrum Teams.

Scaled Scrum - Multiple Scrum Teams

Often Scrum Teams find it easier to work on the same Sprint length to have a shared Sprint Review and thereby reduce complexity. Within the Sprint work is synchronized via a Scrum-of-Scrums, a Daily Scrum across the teams.

When many Scrum Teams need to co-develop one product, dependencies become huge. There are not only the inner-team dependencies that every single team faces, but also an exponentially growing number of dependencies in Product Backlog and in the codebase.

The goal of a system called ‘Scrum’ however remains to create releasable Increments by the end of every Sprint, where a Sprint takes no more than 30 days, preferably less. If such Increment is not created, the closed feedback loop is broken, and the opportunity to adapt is lost.

A solution that up to some level circumvents this, is to align Sprint lengths of the involved Scrum Teams. The goal of such enforced cadence has the purpose of ultimately synchronizing at joint Sprint Reviews, the ultimate way to create and review integrated software. At the slowest pace of the involved team(s) a fully integrated Increment is available.

It is however still a limitation of autonomy, and autonomy is the best possible weapon against dependencies.

Cultivating Your Green Tree

The autonomy of teams is reflected in their ability to autonomously set their own, proper Sprint length. Such autonomy can be largely increased by keeping all code of the product integrated. At all times.

The state of integration of the work is a source of inspection that might lead to adaptations that get priority over all other work to be performed. Integration needs to be fixed first before -upon a green integration light- new work can be added to the system. Work on your trunk only, and keep your trunk green at all times. Cultivate your green tree.

When work is kept integrated at such a rigorous rate, the need or necessity of shared Sprint Review meetings, as the way to ultimately synchronize results across multiple teams, dissipates. When work is rigorously kept integrated, all the time, each and every one of the involved Scrum Teams can derive a reviewable Increment from the integrated codebase autonomously and independently. The work performed during their Sprint can be reviewed with the Product Owner and specific stakeholders, allowing focus on a specific part of the system alone.

Scaled Scrum - Integrating Scrum Teams

Complexity is suddenly hugely reduced, while the ability to release integrated software is retained as well as the advantages of time-boxing the creation of output. No heated debates over big enough rooms for all shared meetings. No heated debates over the exact time-boxes across teams. Autonomy, and ultimately… self-organization.

Scrum's DNAThe system exhibits all core characteristics of Scrum as a closed-loop feedback system, the same characteristics that one team would exhibit; empiricism and self-organization. As a whole the system exhibits flow and continuity. The system operates at scale, yet is back to being… Scrum. The benefits of Scrum are scaled. Individuality, bottom-up energy, collaboration, self-respect are framed, not overruled, imposed or dictated, leading to autonomous teams creating cohesive product.

Posted on 4 Comments

Product Owner role summary

What does a Product Owner do?

The Product Owner brings the business perspective to the software product being created and sustained into a Scrum Team. The Product Owner represents all stakeholders, internal and external, to the Development Team. Although a Product Owner is likely to have various strategic product management tasks outside of the Scrum Team, it is important that the Product Owner actively engages with the Development Team regularly and repeatedly.

The Product Owner assures with the Development Team that a Product Backlog exists. The Product Owner manages Product Backlog based on the product vision as a long-term view of the road ahead. A product vision captures why the product is being built.

Product Backlog shows all of the work currently envisioned for the product. This work may comprise initiatives, functional and non-functional expectations, enhancements, fixes, patches, ideas, updates and other desirements. If anybody wants to know what work is identified and planned for the product it suffices looking at the Product Backlog.

The Product Owner expresses the expectations and ideas captured in the Product Backlog to the Development Team, and orders the items in the Product Backlog to optimize the value being delivered. Lower value items are actively removed from Product Backlog (see the Tea Leaves Effect). Lower value functionality is actively removed from the product.

The Product Owner invites stakeholders to the Sprint Review to come work with the Scrum Team; what got done, what didn’t got done, what are relevant market or competition trends. The goal is to collaboratively identify what is the most valuable work to do next for the Product. This is captured in Product Backlog. Obviously.

The Product Owner manages the product budget to balance value, effort and time for the represented stakeholders. The Product Owner maximizes value. Period.

What does it take to be a Product Owner?

Being a Product Owner requires specific skills and traits. There are too many to mention, but an entrepreneurial spirit is certainly a helpful one. Being a Product Owner requires ownership of a product, implying strong organizational adoption of the role. Being a Product Owner is being a servant-leader in working with self-organizing teams. Being a Product Owner is not easy. It may take some time to get there.

ScrumAnd - Product Owner

Posted on 9 Comments

My Pocket Guide to Scrum

Scrum - A Pocket Guide (front)People learn about Scrum in various ways. Some read books. Some read my book:

Scrum – A Pocket Guide (A Smart Travel Companion)

  • Read a PDF excerpt from my book. It holds the foreword by Ken Schwaber, a short note by the early reviewers, the content table and the first chapter (‘To shift or not to shift’). A taste.
  • Get the full version at Amazon, Amazon UK, Van Haren’s webshop (the publisher), Bol.com. Or use good old Google.

My book serves to help the reader make better use of the tool that Scrum is.

My book introduces the rules and roles of Scrum while emphasizing their purpose. People can more effectively employ Scrum from an understanding of the purpose, rather than from mechanically following the ‘process’.

People are more capable of using Scrum to their advantage when understanding that Scrum is a framework laying out the boundaries within which people can deal with complex problems. My book distinguishes the rules of Scrum from tactics to apply the rules. My book has some examples on tactics, and where tactical decisions within the Scrum framework are required.

My book presents no universal truths, gives no universally applicable answers on generic questions, although I get asked such questions over and over again.

How long should Sprint Planning be? And the other meetings? How much time does the Product Owner role take? Is the Scrum Master role a full-time occupation? Should a team be available full-time? How must we organize when the team is distributed? How much time of a Sprint should a team spend on testing? What should be in the definition of Done? How many business analysts are needed in the team? What if… ?

I am extremely wary of being an ‘expert’ providing certainty where there isn’t. My book is a book for people on a journey to discover what Scrum can do for them. Hence its subtitle. My book does not map out your route. Your route is unique and distinct.

My book adds some historical perspective to Scrum, describes the roots of Scrum, how Scrum fits the Agile movement and what some future challenges of Scrum are.

My book “Scrum – A Pocket Guide” is not an expert book. It is not a book for experts. It is not a book by an expert. My book is a book by an eternal novice seeking mastery. I hope you like it. I hope it helps you seek mastery too.

Meanwhile I am in the process of creating a follow-up book. I will still not provide false precision. I might tell some stories about what worked for me, given context and time.

Gunther

Posted on Leave a comment

Agile Greece Summit – netweek interview

Yiannis Mavraganis and a crew of Agile enthusiasts organized the first Agile Greece Summit on Friday 18 September 2015 in Athens. It was an honor to be there and give a talk on Nexus and Scaled Professional Scrum. I hope attendants got many ideas and inspiration from the sessions and from sharing problems and insights. I hope it helps the Greek economy in these difficult times.

Netweek logoPreceding the event George Fetokakis published an interview with me in the Greek IT magazine netweek.

Netweek interview (Greek)The publication was in Greek. Thanks to George I can share the English version here. George published it under the header “Respect for developers”:

  1. What is Scrum?

Scrum is a lightweight framework for complex product development. Scrum has, by design, a minimal, yet sufficient, set of rules and roles. Scrum prescribes no techniques or practices to apply these rules to allow teams and organizations to devise the best possible tactics, depending on their context, to apply Scrum. 

All basic rules of Scrum are described in a lightweight document, the Scrum Guide, which is available at http://www.scrumguides.org. The Scrum Guide is maintained by the co-creators of Scrum, Jeff Sutherland and Ken Schwaber.

  1. Do you see any challenges in the organizations which use only Scrum? What do you think are some of the big threats to Scrum adoption or growth?

In my 2013 book, “Scrum – A Pocket Guide”, I describe two future challenges of Scrum. 

The first challenge concerns the way the role of the Product Owner is fulfilled. We often see that representatives or proxies of product management are fulfilling the role. The benefits realized through Scrum would be higher if product managers would directly engage in Scrum, through the role of the Product Owner.

The second challenge is the improved understanding and adoption of Scrum by management, think about operational IT management, sales divisions, delivery managers, product departments and hierarchical CxO management.

I would add a third challenge, related to scaling. Many organizations have adopted Scrum and see the benefits at the scale of one or some teams. Organizations pursue the same benefits with many teams, but struggle in scaling Scrum while respecting the principles and foundations upon which Scrum are built.

  1. Why should a Development Team choose Scrum?

Scrum thrives on self-organization, inviting and inspiring Development Teams to plan, organize and track their own daily work. Product Owner set out a vision and goals against which Development Teams work. Stakeholders are expected to provide the Development Team with new or changing insights by the end of every Sprint. A Sprint takes no more than 30 days, and is often shorter.

Scrum fundamentally restores the respect for the creativity and intelligence of Development Teams, allows them to fully exploit their skills and insights.

  1. What is Scaled Scrum and how important is this method for big software development projects?

‘Scaled Scrum’ is any implementation of Scrum in which multiple Scrum Teams create one software system or product. The purpose of Scrum, independent of the scale at which it is used, is to create high-quality, releasable versions of product by the end of every Sprint. This allows organizations to quickly and regularly serve their customers, and to incorporate feedback into the development process fast. It is what we call ‘business agility’. It is crucial for companies to survive and prosper in today’s fast changing economy.

At a larger scale, keeping a high level of such agility is highly important. It assures companies of flexibility and responsiveness. Translated to the adoption of Scrum for product development, it holds that the big challenge of scaled Scrum holds the ability for multiple teams to produce releasable software by the end of every Sprint.

Our Nexus framework provides organizations with guidance on how to grow and scale Scrum, on how to implement Scaled Professional Scrum.

We recently published the Nexus Guide at our website, https://www.scrum.org/Portals/0/NexusGuide%20v1.1.pdf

Posted on 2 Comments

A Professional Organization Defines Quality

An often observed problem of Scrum adoptions is the isolated way that Scrum Teams operate, being or acting as if detached from the wider organization. There are several possible causes, one of them being the disconnect between people creating standards and people implementing upon those standards.

An organization that thrives and depends on software products and services can be expected to have a definition of product qualities in place, and to express such through standards, guidelines, rules, service levels and other expectations. Scrum Development Teams, consisting of professional product developers, are an integral part of an organization, rather than being isolated gangs of thug coders within the organization. Such Development Teams can be expected to adhere to overarching product standards.

It explains why, on the topic of the creation of a definition of Done, the Scrum Guide says (see http://www.scrumguides.org/scrum-guide.html#artifact-transparency-done):

If the definition of “done” for an increment is part of the conventions, standards or guidelines of the development organization, all Scrum Teams must follow it as a minimum. If “done” for an increment is not a convention of the development organization, the Development Team of the Scrum Team must define a definition of “done” appropriate for the product.

If, as can be expected, the minimal definition of Done is provided by the organization, a Development Team can still complement it with context-specific elements; the product, a release or technology.

If organizational guidelines are not provided, a Development Team should, as professionals, create an appropriate definition of Done for their development. How else does a team know what work to do, what tasks to undertake, if it doesn’t know, and have a shared understanding of, the characteristics of the Done or end product? How else can Product Owners and stakeholders know what quality they will be receiving? Quality should not be their concern, or their primary focus. Market reception, business opportunities, offered functionality should be.

The lack of such standards or provision of them is therefore also best raised within the organization to serve wider organizational improvement. Remember that such improvement will also benefit others within the organization.

Scrum can be a lever for organisational improvement. Scrum Master is a servant-leader role for the organization too.

Often organizations provide a list of guidelines that is presented as ‘minimal’, yet proves to be unrealistically long and heavy. This again is a great area for conversation, improvement and removal of organizational waste. The organization might have not adapted their standards and expectations to the reality of iterative-incremental development, or their standards might for a long time have not been matched against actual implementation of them. ’Standards’ might be in place that were created as part of long, sequential processes where quality problems typically accumulated heavily before they were detected. As the people maintaining standards typically do not engage in creating quality upon those standards they start adding demands to the expectations that prescribe the delivery of proof that ‘quality’ is created. They started confusing defining quality (‘what’) with evidence of quality ‘(how’).

Avoiding the conversation is not helpful. Self-organization is not an excuse to do so. A Development Team might push back toward a realistic definition of Done with arguments on how they will actually build in quality, Sprint after Sprint after Sprint. A feedback loop from practice to theory is best established. It is important, and often surprisingly revealing, for the people creating standards to experience what practical application of these standards entails, or what waste is in them when iterative-incrementally delivering versions of releasable product.

Quality, in the end, is in the product, not in paper documentation. Paper documentation allows lies and illusions of quality, working software doesn’t.

Posted on 2 Comments

Scaled Professional Scrum – Nexus (Nederlandstalig)

Op de Scrum.org  website publiceerde ik recent de whitepaper “Scaled Professional Scrum – Rationale of the framework” (PDF).

Hierbij vindt de geïnteresseerde lezer dit document in (een licht aangepaste) Nederlandstalige versie terug als “Scaled Professional Scrum – Whitepaper (Nederlandstalig)”.

Achtergrond:

Scrum is een framework voor complexe productontwikkeling.

  • “Scaled Scrum” omvat elke implementatie van Scrum waarbij meer dan één team een product realiseert.
  • “Scaled Professional Scrum” omvat elke implementatie van scaled Scrum die bouwt op de fundamenten, principes en waardes van Scrum, met inbegrip van software development professionalisme.

Het framework voor Scaled Professional Scrum van Scrum.org biedt de ruggengraat waarop organisaties hun productontwikkeling op basis van Scrum kunnen opschalen mèt behoud van de eigenheid en de voordelen van Scrum. Het framework bundelt de practices, ervaringen en inzichten van een wereldwijd netwerk van experten, waaronder Ken Schwaber en Jeff Sutherland, co-creators van Scrum.

Het kloppend hart van Scaled Professional Scrum is een Nexus, een ‘exo-skeleton’ voor Scrum. Een Nexus implementeert het Scrum proces zodat 3-9 Scrum Teams zo efficiënt mogelijk gezamenlijk aan één product kunnen werken.

Nexus_Titled_Transp

Het Scaled Professional Scrum framework bevat 40+ practices. Elk van deze practices, indien met kennis en kunde geselecteerd en geïmplementeerd, kan de werking van een Nexus optimaliseren naar een specifieke context.