Scrum Master – A Manager

Manager – Traditionally

Traditionally an individual is declared a ‘manager’ when having hierarchical control over other individuals. A traditional manager exerts power. A traditional manager commands people through the assignment of to-be-done work; expressed as tasks or work packages, given on a daily base or via to-be-followed plans. Subsequently a traditional manager follows up on the execution of the assigned work. The traditional manager does not wait for the results of the work but wants to see how the work is being carried out, who is doing it, when the tasks are being performed and how much time it is taking. The time it takes is in general compared to the time that was instructed the task should take.

This and other performance information is recorded and stored, mostly in reports and other forms of documents. The traditional manager (in)frequently uses the stored information to evaluate a subordinate in order to steer that person’s career; via carrots like education, promotion, incentives, bonuses, salary. The traditional manager acts as the one who knows it all, and is supposed to act in the best interest of the company and its shareholders, even if that interest is obscured from the people assigned with the actual productive work.

Not limited to, but certainly in a context of agile, there is not only no need for a ‘manager’ behaving according to this authoritarian pattern and traditional expectation, it is even highly counterproductive and extremely discouraging. Dan Pink - DriveIt undermines enthusiasm, disregards intrinsic motivation by focusing solely on extrinsic motivators, kills job satisfaction, is an open door for politics and bribery and is therefore catastrophic for an organization depending on people. It is without doubt disrespectful and inhumane.

Is the notion of ‘manager’ therefore forever corrupted? Evil by default? A lost case?

Management – Actually

Scrum, like all things agile, has a very different viewpoint on working with people and on the aspect of management, but it does not the disregard that the activity of managing is required.

Let’s explore this different perspective upon the statement that “Scrum Master is a ‘management’ position”.


  1. A Scrum Master is a manager. Contrary to the traditional idea of a ‘manager’, a Scrum Master has no formal power over the people in the Development Team, not deciding over their careers, incentives, etc. A Scrum Master does not manage the people or their tasks. But a Scrum Master does manage (via) the Scrum process. Within an organization a Scrum Master is accountable for the maximization of Scrum, for ensuring that people, teams, departments and the organization realize the highest benefits possible from using Scrum. A Scrum Master is accountable for the way Scrum is understood and enacted. This requires management skills, traits and insights.
  2. A manager is a Scrum Master is a manager. A Scrum Master is explicitly responsible for removing Impediments. Impediments are elements that limit the efficiency and progress of a Development Team in areas that are beyond the reach of self-organization of a Development Team. Impediments are most often found in the wider organization, in company processes, procedures, and structures. Removal of Impediments works better if the Scrum Master is a manager turned Scrum Master, thereby adopting facilitation as the primary management tool and seeing the workfloor as the primary habitat.

A Scrum Master indeed is a manager, albeit not in the traditional sense. It is clear that a Scrum Master does not manage budget, people, work and tasks. Product Owners manage investments. Teams manage themselves. However, self-organization as promoted through Scrum does require goals and boundaries. A Scrum Master manages the boundaries that Scrum provides to augment self-organization; time-boxing to limit risk, focused efforts, cross-functional collaboration, releasable results, validated learning.

The Scrum process does no more than framing the creativity of people in their joint creation of valuable software. The process of Scrum lays out a foundation for rhythm and discovery. A Scrum Master manages the Scrum process through the provision of specific services like removing Impediments, facilitating teams, educating the organization, coaching people and keeping the road open to perform, to work, to innovate, to be creative. The services that the Scrum Master provides, needs to provide or is allowed to provide become a mirror to the state of Scrum in an organization.

Scrum Master can be seen as a management position because the Scrum Master role holds what is expected from a manager in an agile context, not because it reflects what traditionally is expected from a manager. A managing Scrum Master is a wise leader that engages people through organizational purpose and vision.

Manager – A Scrum Master

A manager who acts like a Scrum Master optimizes the value of management to the organization. The optimization lies not in commanding and controlling tasks and detailed work items. The value a manager brings lies in identifying wasteful activities, eliminating waste, removing impediments, embracing complexity by assuring Scrum is understood and enacted, from its principles and roots in empiricism, building on the core Scrum Stance, propelling on opportunistic experimentation, setting goals, and maintaining purpose.

The Scrum Master-manager is strongly affiliated to the Lean idea of “Go See“. A manager turning Scrum Master is a person that does not hide in a far-away office. Not hiding is much more than merely creating an open door policy. An open door is a fake measure, as it still lays the burden with the people wanting to see and talk to the manager. The workfloor buzz does not enter through that door. The flow needs to be reversed. The Scrum Master-manager walks around, is part of the workplace with the teams, the place where the real value is created. In Lean this place is referred to as Gemba.

It can even be taken some steps further with the idea of Empirical Management.

Management – Definitely

Even in an agile context, the act of managing remains a valuable activity. The act of managing is performed by managers.

Teams manage themselves. They organize their work autonomously. They are managers too. Product Owners manage the product’s vision and the investments in the product. Others manage boundaries, company objectives and identity, technical environments, the Scrum framework. ‘Management’ is the collection of all such activities. Management done properly thrives on servant-leadership. ‘Management’ is not a collection of people executing hierarchical powers. It is an emergent, networked structure of co-managers, people with complementary skills, focus and accountability, mutually exchanged services. All seek direction. Collaboratively. Continually. Skills and meaningful conversation prevail over title, hierarchy and position.

“What you say has priority over how you look.”

Is a manager who turned Scrum Master still a manager then?

A Mirror of the Scrum Master’s Work (so far)

Introducing “ScrumAnd”

Jigsaw Scrum

Adopting Scrum best starts by doing Scrum in the first place, getting all the formal elements of Scrum in place. It is like a jigsaw that isn’t complete until you have fitted all the pieces together. Luckily Scrum doesn’t have many pieces: 3 roles, 3 artifacts and 5 events. A simple set of rules can emerge complex behavior.

This ability to say “Yes, we do Scrum” however is only the start, not the end. Scrum is not the goal, Scrum is a mean to a goal. In order to increase the benefits, the way Scrum is used is to be maximized, thereby moving to “Yes, we do Scrum. And…“. There is a “ScrumAnd” for a myriad of elements. In the post Illustrations of ScrumAnd this was demonstrated through (1) the Product Owner role, (2) the ability to create releasable Increments and (3) the level of collaboration within a team.

Applying the “ScrumAnd” model on the role of the Scrum Master.

The Scrum Master facilitates Product Owners, Development Teams and the wider organization with services. The benefits gained through Scrum depend on the services provided by the Scrum Master. Or is it the other way around?

ScrumAnd (Scrum Master)

It is unfavorable, difficult and probably impossible to forcefully command people, teams and organizations into higher performance. In a “ScrumAnd” view on the Scrum Master role, there is less of a deliberate choice or strategy involved to increase benefits.

Teams though can be facilitated and wisely lead into benefits that will last. Yes, you do Scrum if you have a Scrum Master. And the level of services that the Scrum Master provides probably reflects the state of Scrum:

  • A Scrum Master teaches techniques for others to use; how to manage Product Backlog (syntax, sizing, splitting, grouping, descriptions, refining, dependencies), how to create visibility of progress (burndown charts, Scrum boards, cards, velocity, release plans), creating a definition of Done, how to plan and execute a Sprint, how to do a Sprint Retrospective meeting, the value of time-boxing.
  • A Scrum Master helps teams and their wider environment optimize the use of Scrum through Scrum’s foundation in empiricism; how Scrum implements transparency, inspection and adaptation, how Scrum helps when only the past is certain and the future is uncertain and highly unpredictable.
  • A Scrum Master shifts the focus from using Scrum to deliver on a set expectations (scope against time and budget) toward organizing work for creating the most valuable outcome; shifts focus from the process itself to the goal of the process.
  • A Scrum Master focuses on behavior, instead of ‘process’ and even outcomes. Accountability drives behavior, and behavior becomes grounded in the Scrum values, and Scrum is understood and applied through the values and principles expressed in the Manifesto for Agile Software Development.
  • A Scrum Master is present with a team, and within the organization; a silent, non-intrusive, mentoring, comforting, observing presence.

Scrum Masters are often expected to operate on the practices end, to be teaching techniques. Development Teams might want it because they have always been told what to do. Managers might want it because it is as close as they feel a Scrum Master can get to executing control in this new way of working. Scrum Masters themselves have the intrinsic desire to be invisibly present.

Whenever a service is needed, by the Scrum Master’s observation or by explicit request, a Scrum Master assesses the service level required depending on the requester, context, time. The happiest moment for a Scrum Master occurs when teams push back for being provided with too low level services.

The service that the Scrum Master is providing becomes a mirror for the Scrum Master’s work so far. Complexity equals instability, by default. Staffing changes (in the teams and in the organization), relationships change, strategies and objectives change, technologies change. A Scrum Master keeps going back and forth, up and down through the range of services possible. A Scrum Master cannot expect to steadily provide only one type of service.

Where are you, as a Scrum Master? What services are requested from you? Do you provide services that reflect the actual maturity of the team and the organization’s understanding and usage of Scrum?

Product Backlog and the Tea Leaves Effect

The Tea Leaves effectDo you like drinking a cup (glass) of tea? Ever had a tea bag that was torn? Spreading tea leaves in your tasty drink?

Then you know that such leaves circulate wildly and chaotically throughout your tea when you stir it, add water, or drink it. Science is somewhat more precise about the behavior of such leaves, calling it the tea leaves paradox, but let’s just stick with our more direct observations.

Floating tea leaves are best removed from the tea. It prevents obscuring of the tea, and makes a better and tastier drink. Most consumers prefer tea without such leaves. If not for the look of the tea, then certainly because it’s no fun to drink tea leaves.

The tea leaves effect is a good metaphor to understand the need to refrain from collecting and listing requirements in a Product Backlog endlessly. The tea leaves of your Product Backlog are those requirements that go up in ordering every time the Product Backlog gets stirred. They float around, obscuring your Product Backlog and decreasing its transparency, and they always sink to the bottom as the environment settles again.

Keep your Product Backlog clear, clean and tasty. Remove those features that cloud your Product Backlog. Remove those features that always sink to the bottom of what you plan for your product, and never get implemented. If those features are really valuable, they will pop up again at some point in time.

It connects to ‘trimming the tail‘ as described by Alistair Cockburn. The goal is to not build low value ideas. It sounds simple, the gains are considerable, but it takes much discipline. But you don’t want to feed your customers tea leave requirements, right?

Courage and Accountability (go hand in hand)

Accountability, commitment and transparency are terms that frequently pop up in the context of agile and Scrum. Unfortunately, but not uncommon in our industry, the use of these terms seems to happen a lot without much reserve or consideration, out of context, from a superficial or no understanding, as self-elevation attempts by self-acclaimed charlatan-experts; and in a way that even contradicts the principles and values of agile and Scrum. Yet, despite the misuse, they can be essential and powerful drivers of behavior in agile and Scrum.

Good enough reasons for further inquiry, thoughts and consideration, starting with the observation that accountability, commitment and transparency are inter-connected and have the requirement of an important quality in common: COURAGE.

Accountability complements Collaboration

‘Accountability’ is the state of a person, a group of people, an organization being accountable. This in turn refers to the expectation, the ability and the willingness to share how a certain result came about in a specific domain or area of accountability; what actions or decisions were or were not taken, explain why these were or where not taken, what the considerations were, etc. Accountability has less to do with the actual result than it has to do with sharing, explaining and justifying the path leading to the actual result.

Definition - AccountableAccountability thus requires the courage to be honest, to work hard, to do the best you can, to act responsibly, to share information, to reveal reality; not the destructive ‘courage’ commonly demonstrated in achieving a desired result, at any price, cost or damage.

All too often accountability is (mis)understood as the assurance of a desired, future result, the promise of a future outcome, with the built-in threat of laying total blame with the one(s) bearing the accountability when the predicted result is not exactly or completely achieved. It is a hideous expression of a desire for command and control. It builds on a blame culture, not on a goal-oriented culture of learning and improving.

Shall we rename the false understanding of ‘accountability’ to ‘commandability‘?

The undertone of commandability is: „YOU are accountable. It is therefore YOUR job to make it happen, whatever it takes.“ It is in itself obviously disrespectful. Beyond that, in the complex, unpredictable and uncertain environment of software development no approach with the characteristics of commandability is viable anyhow. Because software development by nature thrives on emerging knowledge and facts, and ongoing discovery. It requires the ultimate superhero to live up to the (false assumption of) accountability.

Being accountable for work, a task, a goal is not a promise of a result. Neither is it an obligation to do everything alone. It looks like courage to try to do so, but it isn’t. It is mistaking courage for individual heroism. And in a complex environment, like software development, it reduces the chances of success to extremely low and even zero, at the cost of an extreme feeling of loneliness and being burned. It doesn’t work like that in difficult, creative, unpredictable work. It doesn’t work when being part of a team.

The person taking such individual expectation of a promised result seriously is likely to wander off into a personal death march when lacking this courage to admit it can’t be done alone, that it takes collaboration and help from others to live up to the assigned accountability. It takes courage to ask for help and engage with fellow travelers. It is a type of vulnerability that enables better living up to accountability.

Commandability, the falsified and perverse form of accountability, even brings about the danger of creating silos, silo-thinking and silo-behaviour; at the level of an individual, a team, a product, a department, a company.

Using inverted accountability in a context of Scrum leads to exactly the opposite of the Scrum tenets; cross-functional collaboration, utilizing collective intelligence, bottom-up knowledge creation, shared goals. Yet, accountability remains essential. The false application of it doesn’t drive out its importance. Removing and avoiding accountability has disastrous effects as well; no vision, no focus, no direction, no choices, endless discussions and meetings, indecisiveness; a Gordian knot.

Scrum foresees clear accountabilities:

  • The Development Team is accountable for creating releasable Increments.
  • The Product Owner is accountable for maximizing the value of the work.
  • The Scrum Master is accountable for facilitating the understanding and application of Scrum.

These accountabilities are separated, yet all needed. It is why these roles need to collaborate as a Scrum Team with a shared responsibility toward the organization, its customers and the wider ecosystem. The built-in tension, resulting from the separate accountabilities, invokes productive dissent, helping teams to rise above artificial harmony, recognizable as accommodation, silence and apathy. The tension is a foundation for emerging ideas and the creativity to create the best possible solution. The level of tension however is to be observed and protected from accumulating into unhealthy levels and types of dissent and (personal) conflict.

In the end, true accountability complements collaboration, not supersedes it.

Commitment mirrors Accountability

Accountability is the mirror to commitment. A committed person or team fears not taking up accountability, often it happens even spontaneously and voluntarily. Accountability works better if it induces commitment, if it appeals to intrinsic motivation.

Commitment suffers from a misunderstanding very similar to the misunderstanding that exists over accountability, i.e. being interpreted as a hard-coded contract with a promise of a certain future result. In a context of Scrum this misuse was somewhat reinforced by the past requirement for teams to ‘commit’ to a Sprint. It caused creation of the expectation that all scope would be delivered, no matter.

Definition - Commitment‚Commitment’ however was always intended as a promise to do the maximum possible in the Sprint and to be transparent about the achieved result at the end of the Sprint. In the complex, creative and highly unpredictable world of software development a commitment on scope is impossible anyhow.

So, commitment is about dedication and applies to the actions, the effort, not the final result. As such it is still a core value of Scrum. Committed people show the courage to do the best they can, to promise they will do the best they can, given the conditions they work in and the means they are given.

Committed people accept accountability. They show no fear of being transparent over the work done, the work not done, changes to a plan, opportunities discovered, problems encountered. Transparency even helps them demonstrating that the best possible result was accomplished, even when it is not the supposed or hoped for reality, whether it is less or more than what was expected. Such transparency comes not without courage.

Transparency Serves a Purpose

Accountability requires transparency. Commitment offers transparency. But transparency serves a purpose, the purpose of learning. Accountability and commitment without the goal of validated learning are meaningless. Transparency for the sake of transparency is meaningless. Accountability, commitment and transparency are the ingredients of progress, not a hammer for blame over the past. Accountability, commitment and transparency without trust, self-organization and regular validations are pointless.

Validated learning is also why work is organized in time-boxes in Scrum, as a way to limit any type of risk and to frequently learn, thereby superseding the traditional notion of failure. Scrum makes validated learning explicit via its implementation of empiricism in software development. Transparency in Scrum serves the frequent cycles of inspection and adaptation. Transparency is needed for all inspectors to know about reality, to assess and evaluate the actual, real status, and adapt to it in order to move on.

Transparency is not necessarily applicable to any sort of information, independent of situation and context. Transparency applies on all information that the people accountable for inspection and adaptation require.

Some illustrations

  • In Scrum, the Product Owner typically maximizes the value of the work by ordering the Product Backlog. The Product Owner is accountable for the Product Backlog, accountable for identifying, ordering and expressing product ideas and options. A Product Owner will have an extremely difficult time trying to do this all alone. Consulting with users, stakeholders, and the Development Team, appealing to the collective intelligence of the ecosystem augments a Product Owner’s accountability (and credibility). And it doesn’t prevent the Product Owner from having the final call and prevent being stalled in endless debate.
  • In Scrum, the Development Team is accountable for creating an Increment of releasable product by the end of the Sprint. Inspection of the Increment requires transparency over the state of the Increment, over its quality. A much used practice to achieve such transparency is the definition of „Done“. A Development Team will have a difficult time providing full transparency through the definition of Done when only allowing in what they like or care to care about. Consulting with the Product Owner, taking into account the organization’s quality standards, regulatory requirements, etc. augments a Development Team’s accountability (and credibility).
  • In Scrum, the Development Team plans and organizes its work for a Sprint. On a daily base the work is optimized and re-planned against the Sprint Goal. What is a demand to make Sprint Backlog transparent outside of the Scrum Team based on? What inspection and adaptation would such ‘transparency’ serve?

Scrum Glossary

In November 2013, my book “Scrum – A Pocket Guide (A Smart Travel Companion)” was published. I added a Scrum Glossary in appendix A of the book. I explained the terms that I consider essential in the Scrum framework, holding e.g. that I would never translate these.

I felt it was a good idea to share my Scrum Glossary here too:

  • Burn-down Chart: a chart showing the evolution of remaining effort against time.
  • Daily Scrum: daily, time-boxed event to re-plan the development work during a Sprint. It serves for the Development Team to inspect the daily progress and update the Sprint backlog.
  • Definition of done: a list of expectations that software must live up to in order to be released into production.
  • Development Team: the role within a Scrum Team accountable for doing incremental development work, with the aim of creating a releasable Increment every Sprint.
  • Emergence: the process of the coming into existence or prominence of unforeseen facts or knowledge of a fact, a previously unknown fact, or knowledge of a fact becoming visible unexpectedly.
  • Empiricism: a process control type in which decisions are based on observation, experience and experimentation. Empiricism has three pillars: transparency, inspection and adaptation.
  • Engineering standards: a set of development and technology standards that a Development Team applies to create releasable Increments of software.
  • Increment: a piece of working software that adds to previously created Increments, and -as a whole – forms a software product.
  • Product Backlog: a list of the work to be done in order to create, maintain and sustain a software product.
  • Product Backlog refinement: the activity in a Sprint through which the Product Owner and the Development Team add granularity to Product Backlog.
  • Product Owner: the role within a Scrum Team accountable for incrementally managing and expressing business and functional expectations for a product.
  • Scrum Master: the role within a Scrum Team that is accountable for guiding, coaching, teaching and assisting a Scrum Team and its environments in the proper use of Scrum.
  • Scrum Team: a team consisting of a Product Owner, Development Team and Scrum Master.
  • Scrum Values: a set of fundamental values and qualities underpinning the Scrum framework was created.
  • Sprint: time-boxed event that serves as a container for the other Scrum events.
  • Sprint Backlog: an overview of the development work to realize the Sprint’s goal.
  • Sprint Goal: a short phrase describing the purpose of a Sprint.
  • Sprint Planning: time-boxed event to start a Sprint. It serves for the Scrum Team to inspect the work that’s most valuable to be done next and design that work into Sprint backlog.
  • Sprint Retrospective: time-boxed event to end a Sprint. It serves for the Scrum Team to inspect the past Sprint and update the process for the next Sprint.
  • Sprint Review: time-boxed event to end the development work of a Sprint. It serves for the Scrum Team and the stakeholders to inspect the Increment resulting from the Sprint, the impact of overall progress and update the Product backlog.
  • Stakeholder: a person external to the Scrum Team with a specific interest in and knowledge of a product that is required for incremental discovery.
  • Velocity: indication of the average amount of Product Backlog turned into an Increment of product during a Sprint by a Scrum Team.

On you will also find a Scrum glossary. To be honest, I never checked mine against the one on the website.

Nietzsche contra Nietzsche

In 1869, nauwelijks 24 jaar oud en nog zonder doctoraat, wordt Friedrich Nietzsche (geboren te Röcken nabij Leipzig in Duitsland) na zijn studies in Bonn en Leipzig benoemd tot hoogleraar Klassieke Filologie aan de universiteit van Bazel in Zwitserland. Nietzsche was van opleiding namelijk classicus. Dit domein werd alsnog zijn ingangspoort tot de filosofie, zijn latere en finale bestemming.

Nauwelijks een jaar eerder, in 1868, had Nietzsche in Leipzig de componist Richard Wagner ontmoet.

Friedrich Nietzsche -  De Geboorte van de TragedieIn 1872 verschijnt het eerste boek van Nietzsche, “De Geboorte van de Tragedie“. Het is een onderzoek naar de bronnen, het ontstaan en de evolutie van de aard en de verschijning van de zogenaamde ‘klassieke tragedie’ in het oude Griekenland. Alhoewel geschreven vanuit zijn vakgebied bevat het boek heel duidelijk al de krijtlijnen van de latere filosofische wegen van Nietzsche. Kenmerkend is ook al de uitgesproken hamerende stijl van zijn geschriften, het afwijzen van doorgedreven structuur en retoriek. Finaal slaat hij de wegen van de filosofie pas exclusief in vanaf zijn terugtreden uit zijn universiteitspositie, wegens gezondheidsproblemen, in 1879.

De eerste versie van het boek heeft nog als ondertitel “uit de geest van de muziek“. Het bevat ook een voorwoord aan Richard Wagner en ettelijke, behoorlijk naiëf ogende idolatrische verwijzingen naar hem. Echter, de echte kern en waarde van het boek is Nietzsche’s diepgravende en oorspronkelijke analyse van de klassieke tragedie. De figuur van Wagner is eerder de projectie, een spiegel van Nietzsche’s hoop op de wedergeboorte ervan. Nietzsche hoopt op de herwaardering van de dionysische driften in de muziek en het theater, zodat de balans kan hersteld worden tussen het instinctieve (een dierlijke, natuurlijke levenslust) en het naïeve (hoopvolle, dromerige romantiek). Nietzsche meent dat de tijd gekomen is om de decadente ontsporing naar louter verschijning, louter woordenspel, ongedaan te maken. De onderliggende idee is het herstel van het pessimisme als levenslustige motivatie, erkenning ervan als oerbeweging, een wezensaard en levensbron.

Het is erg opvallend hoe dit eerste werk van Nietzsche quasi alle thema’s reeds bevat die blijvend zullen terug komen in zijn latere werken, alhoewel een voor een met meer diepgang behandeld in die werken en niet meer zo sterk tegen deze culturele achtergrond.

In de jaren van omgang met Wagner volgend op hun initiële ontmoeting en gesprekken ontwaakt Nietzsche geleidelijk uit het droombeeld dat hij heeft/had van Wagner en bij de derde druk van “De Geboorte van de Tragedie” in 1886 wijzigt hij de ondertitel naar “of: de Griekse geest en pessimisme” (ps. naar mijn mening zou het beter zijn “of: de Griekse geest en het pessimisme”) en vervangt hij het voorwoord aan Wagner door een ‘proeve van zelfkritiek’. In de meest recente Nederlandse vertalingen, steeds uitgegeven bij de Arbeiderspers, werden gelukkig genoeg beide inleidingen opgenomen, met de historische duiding ervan in het nawoord van Hans Driessen, de vertaler.

In zijn laatste actieve levensjaar (1889), dat wil zeggen net voor hij in de 10-jarige lethargie verzeilt die tot aan zijn dood in 1900 duurt, schrijft Nietzsche 2 pamfletten die de figuur van Wagner als expliciet onderwerp hebben, “Het geval Wagner” en “Nietzsche contra Wagner”. Het tweede pamflet wordt door Nietzsche zelf, net voor de intrede van zijn lethargie, niet vrijgegeven voor publicatie. Enkele maanden later, nadat Nietzsche is ingestort, wordt het alsnog gepubliceerd.

Friedrich Nietzsche - Nietzsche contra WagnerIn het Nederlandse taalgebied zijn deze teksten onder 2 verschillende vormen gebundeld en gepubliceerd, telkens in dezelfde vertaling. In de reeks Privé-domein (#194) werden ze beide uitgebracht onder de titel “Nietzsche contra Wagner”, naar het tweede pamflet. In de Nietzsche-bibliotheek werden ze samen uitgebracht onder de titel “Het geval Wagner”, naar het eerste pamflet.

Het is bijzonder opvallend hoe beide pamfletten sterk aansluiten bij het ideeëngoed van Nietzsche dat reeds zijn eerste werk domineerde, “De Geboorte van de Tragedie”. Ze zijn in die zin zelfs erg rijk omdat erin ook zijn denken rond cultuur en kunstenaarschap wordt hernomen, in het licht van het Dionysische en het Apolinische, en de verwerping en vervanging ervan door het Socratische. Het is in die zin ‘rijk’ omdat het die culturele oorsprong actief herneemt en behandelt, en niet de toepassing ervan in het louter filosofische is.

Het tweede pamflet, “Nietzsche contra Wagner”, hoort m.i. tot het meest autobiografische en oprechte dat Nietzsche heeft neergeschreven. Het staat, in tegenstelling tot wat de titel doet vermoeden, grotendeels los van de figuur van Richard Wagner. Het is eerder een strijd van Nietzsche tegen zichzelf, tegen de neigingen die hij vanuit de figuur Wagner ook in zichzelf herkent, en actief bekampt en aanvult. Het eerste pamflet, “Het Geval Wagner”, is veel duidelijker een rechtstreekse afrekening met de figuur van Wagner, alhoewel het een mengeling van afkeer en bewondering bevat.

In de boekuitgave “Nietzsche contra Wagner” worden de pamfletten aangevuld met citaten uit de dagboeken van Cosima Wagner, echtgenote van. Deze citaten ontbreken jammerlijk in de latere heruitgave onder de titel Friedrich Nietzsche - Het Geval Wagner“Het Geval Wagner”. Jammerlijk aan het ontbreken van de dagboekcitaten is dat deze citaten indirect toch een goed beeld van de relaties van de Wagners met Nietzsche schetsen. Alleen al de frequentie van vermelding van Nietzsche door mevr. Wagner is een goede indicator; de frequentie is bijzonder hoog gedurende de eerste 2-3 jaren maar neemt sterk af in de loop van de erop volgende jaren. De inhoud en de intensiteit van haar notities versterken dit effect. De aanvankelijke extreme genegenheid, bewondering en positieve toon slaan geleidelijk om in ergernis, afkeer en ontzetting. In hoofde van Cosima lijkt er toch heel wat heimwee aanwezig te blijven, daar waar bij R. de ergernis overheerst. Allengs, Nietzsche lijkt ondanks zijn lijfelijke afwezigheid toch een regelmatig onderwerp te zijn ten huize Wagner, inclusief een verschijning in een nachtmerrie van Richard.

Een mindere kritiek is dat in de latere uitgave ook het namenregister niet meer wordt opgenomen.

Het kernprobleem dat Nietzsche vaststelt en uitvoerig met zijn furieuze mokerhamer naar taal brengt, is de hang van Wagner naar zuiver effect en impact, naar enkel romantiek en decadentie, zonder Dyonisch tegengewicht en fundering, met daarenboven, in zijn latere werk, ook nog een uitgesproken christelijk-moralistisch karakter. Einde van de (hoop op de) wedergeboorte van de tragedie. For the time being.

Scrum Is A Stance (too)

-An inquiry into the expression of behaviors through Scrum-

Scrum is not a cookbook ‘process’ with detailed and exhaustive prescriptions for every imaginable situation. Scrum is a framework of principles, roles and rules that thrive on the people doing Scrum. The true potential of Scrum lies in the discovery and emergence of practices, tools and techniques and in optimizing them for each organization’s specific context. Scrum is very much about behavior, much more than it is about process.

(from the preface of „Scrum – A Pocket Guide“, Gunther Verheyen, 2013)

It is worthwhile elaborating on the importance of people and behavior in Scrum. Because, indeed:

Scrum is very much about behavior, much more than it is about process.

Introduction: the simplicity of Scrum

Presumably there are many reasons why Scrum turned into the leading framework for Agile software development during the past decade. One of the reasons may be the simplicity of Scrum. Or, perhaps it is the opposite, the wide adoption of Scrum is more like a miracle given that same simplicity.

Yet, the simplicity of Scrum is ESSENTIAL. The simplicity of Scrum reminds us of the fact that the real complexity to be tackled in software development lies outside of the rules and roles of Scrum. The real complexity resides in the specific context within which Scrum is applied. In software development, ‘context’ starts and ends with people; what people do, don’t do, like, dislike, prefer, hate; how people jell, feel and behave. The rules and roles of Scrum help people tackle complexity. But no ‘process’ can replace or compensate the people aspect of software development.

The simplicity of Scrum creates openness. It is an open invitation for discovery and emergence. Yet, the simplicity of Scrum gives rise to many frowns, emotions, reactions, debates. It is experienced as enticing, provocative, offensive, powerful, inadequate, a mystery, impossible. Is the beauty of Scrum, expressed through this simplicity, therefore in the eye of the beholder only? Or is there more to Scrum than meets the eye?

In the end, more than the rules and roles of Scrum, people have the key to Scrum. Behavior is the key to unleashing the potential of Scrum. Scrum is a stance, too.

The eye of the beholder

The rules and roles of Scrum are described in the Scrum Guide. The Scrum Guide was created and is maintained by Jeff Sutherland and Ken Schwaber, co-creators of Scrum. It is the definite body of knowledge to Scrum.

The rules and roles included in the Scrum Guide can be applied and followed as described, with no further inquiry into the why of these rules and roles. They can be regarded as ‘to be followed’ instructions, merely because the Scrum Guide prescribes them.

Blindly following the described roles and rules is for many in the industry of software development at least a great start to transform to Scrum. It helps. People, teams and organizations start, learn, and improve in creating and delivering software iterative-incrementally, with small steps of validated learning. However, sticking to, not transcending, such blind view and usage of Scrum is likely to turn Scrum into no more than yet another IT delivery process. As such it still leaves many holes, gaps, disconnects and waste. The rules and roles of Scrum, as described in the Scrum Guide, in themselves might not be enough to grasp the depth of Scrum and reap the full benefits of employing Scrum. The simplicity of Scrum may be somewhat deceptive.

It helps to dig deeper by:

  1. Reflecting on the definition of Scrum included in that same Scrum Guide document,
    “A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.”
    In the Scrum Guide this definition precedes the description of the rules and roles. This definition shows how Scrum is intended, i.e. an aid for the people employing Scrum, a way for people to structure and organize their own work. It sheds a different light on the subsequent roles and rules of the Scrum Guide. Yet, both are in the same document. Ultimately, the roles and rules described in the Scrum Guide can only be fully understood from the definition of Scrum and the clear intent expressed in that definition.
  2. Reading the description of the roles and rules again, e.g. some time after having started with Scrum. It often leads to the discovery that the Scrum Guide describes behavior more than it has technical prescriptions. A typical focus of many processes is on ceremonial technicalities like meetings, deliverables, timings, phases; i.e. on what is expected from people. Scrum is a framework that gives people the room to organize their own work, yet provides boundaries as every healthy ecosystem needs.
  3. Stepping back to a perspective that goes beyond the Scrum Guide document, the perspective offered in the Manifesto for Agile Software Development. The rules and roles described in the Scrum Guide, the behavior described, don’t just stand on their own. They are grounded in the values and principles expressed in the Agile Manifesto. Ultimately, the Scrum framework can only be fully comprehended when seen as an expression of these values and principles. Ultimately, the rules and roles of Scrum, the behavior described in the Scrum Guide, can only be fully understood in combination with the fundamental views expressed in the Agile Manifesto.

The intent and definition of Scrum, matched against the agile values and principles should ground and then drive the behavior expressed through Scrum.

The Stance of Scrum

Scrum has many facets. Scrum is a framework, not a methodology. The framework of Scrum is not just a set of technical prescriptions, but a recipe to deal with complex challenges. The rules and roles of Scrum support and complement, not replace, the intelligence and creativity of people. The framework of Scrum is an implementation of the values and principles of the Agile Manifesto. Scrum implements empiricism in software development.

The framework of Scrum thrives on implied principles, thinking and… behavior, on people taking a stance to product development through Scrum, a Scrum stance.

The definition of Scrum shows the way to the core of the stance typical to Scrum. If Scrum is an operating system for the values and principles expressed in the Agile Manifesto, the definition from the Scrum Guide shows the way to the kernel of the operating system.

The kernel is expressed as:



  • People are respected for their intelligence, creativity and ability to organize their own work, to self-organize. People collaborate, thereby adhering to the values and principles of the Agile Manifesto and embodying the Scrum values of respect, focus, courage, openness, and commitment.
  • Empiricism serves to deal with the complexity typical to software development. In empiricism only reality and past results are accepted as certain. At a regular cadence outcomes and behaviors are transparently inspected for new and changed insights against set goals. These insights are used to adapt to observed reality.
  • The value of outcomes, work delivered to an ecosystem of creators, stakeholders and consumers, is constantly evaluated, optimized and maximized as a shared goal. Value comes in different shapes and appearances; satisfaction, money, improvement, credibility, risk. Optimizing value is very different from adhering to traditional development drivers like budget, tasks, scope, time, schedule.

In the end, Scrum has many appearances. In the end, Scrum -like all things agile- starts and ends with people. Scrum is a stance, too.

The Scrum Stance