De kernwaarden van Scrum

Scrum is een samenhangend framework van regels, rollen en principes die mensen en organisaties ondersteunen, maar dat afhankelijk van de exacte situatie en context ingevuld kan worden. Scrum is een expliciet empirisch proces omdat alleen een empirische aanpak in complexe omgevingen werkelijke controle biedt. Scrum is geënt op een aantal kernwaarden. Alhoewel deze waarden op zich niet uniek zijn voor Scrum, geven ze toch richting. Ze oriënteren en onderbouwen gedrag, acties en binnen Scrum genomen beslissingen.

In een context van Scrum zouden alle beslissingen die we nemen – alle stappen die we wel of niet zetten, de manier waarop we het spel van softwareontwikkeling spelen, de invulling die we geven binnen het framework – de kernwaarden moeten versterken, niet ondermijnen of omzeilen.

de-kernwaarden-van-scrum

Commitment

De Engelse definitie van ‘commitment’ is: the state or quality of being dedicated to a cause, activity, etc. Vertaald is dit: ‘een toestand van toewijding of engagement voor een doel, een activiteit, enzovoort’. Een illustratie van deze definitie is de uitspraak van een trainer van een sportploeg: “Ik kan mijn spelers op het gebied van commitment niets verwijten.”

Deze definitie vertelt exact waarom ‘commitment’ als een kernwaarde in Scrum is opgenomen. Commitment gaat over inzet, toewijding en inspanning, veel meer dan over het behalen van een vooropgesteld resultaat. Het begrip werd echter vooral als dat laatste geïnterpreteerd, niet in het minst omdat in de context van het verleden vaak werd gesteld dat een team zich moest committeren aan de scope voor een Sprint. Vanuit het oude, industriële denken werd dit al snel gezien als een belofte dat de geselecteerde scope voor een Sprint per se moest en zou worden opgeleverd. ‘Commitment’ werd ten onrechte vertaald als een na te leven contract.

In de complexe, creatieve en innovatieve wereld van softwareontwikkeling is een belofte dat scope, budget en tijd perfect ingeschat, gepland en opgeleverd kunnen worden niet mogelijk – zelfs niet voor een Sprint. Er zijn te veel variabelen en parameters die een toegezegd resultaat, tijdens het proces, nog beïnvloeden.

Om de oorspronkelijke bedoeling van het woord en de context van empirische procescontrole versterkt weer te geven, werd ‘commitment’, wat betreft de geselecteerde scope als resultaat van de Sprint Planning, vervangen door ‘forecast’. Echter, commitment is en blijft een belangrijke kernwaarde van Scrum.

Alle individuele spelers committeren zich aan het team: aan kwaliteit, aan samen-werking en aan voortdurend leren en bijsturen. Er is commitment om hard te werken en te doen wat mogelijk is, elke dag opnieuw. Er is commitment aan de Sprint Goal, commitment aan professioneel gedrag. Er is commitment aan zelf-sturing, aan de principes beschreven in het Agile Manifesto. Men committeert zich om werkende software op te leveren en er is commitment aan voortdurende openheid voor verbeteringen. Een team committeert zich aan de definition of Done, aan de regels van het Scrum framework. Er is commitment om waarde op te leveren, om werk daadwerkelijk af te ronden. Er is commitment aan volle transparantie, evenals commitment om elke status quo ter discussie te stellen.

Focus

In de combinatie van de rollen binnen Scrum en hun aansprakelijkheid zit een balans. Het complementaire karakter ervan versterkt niet alleen de noodzaak van samen-werking, ze zorgen er ook voor dat iedereen focus kan houden op een specifieke expertise.

Het principe van time-boxing binnen Scrum moedigt spelers aan om zich te concentreren op wat nu het meest belangrijk is, zonder te veel afleiding door wat misschien, wie weet, belangrijk zou kunnen zijn in een verder onbepaalde toekomst, ooit. Men focust op de actueel beschikbare kennis, nu. In de context van eXtreme Programming werd hiervoor de afkorting YAGNI in het leven geroepen: ‘You Ain’t Gonna Need It’. Als je nu onvoldoende zekerheid hebt over een verwachting of behoefte, negeer die dan, gedraag je alsof je die niet nodig zult hebben. De toekomst is een onzeker gegeven. Het is belangrijker in het heden ervaring en lering op te doen, die je later helpt om beter met de toekomst om te gaan, hoe die er ook uit ziet. Teams hebben een focus op afwerking, oplevering, en al het werk dat hiervoor te doen valt. Teams zoeken naar de eenvoudigste oplossing, de oplossing die op de eenvoudigste wijze tegemoet komt aan de huidige en bekende verwachtingen.

Dankzij de Sprint Goal heeft een team een focus, een oriëntatiepunt voor de volgende vier weken of korter. Binnen die periode zorgt de Daily Scrum ervoor dat mensen gezamenlijk focus houden op de dagelijkse werkzaamheden die hen naar die doelstelling helpen.

Openheid

De empirische procesfundamenten van Scrum vereisen transparantie, wat op zich openheid en eerlijkheid impliceert. De gecommitteerde spelers, die ook verantwoordelijk zijn voor de regelmatige inspecties (annex aanpassingen), hebben een beeld nodig van de werkelijke situatie om geen zinloze aanpassingen door te voeren. Aanpassingen op basis van een gefingeerde werkelijkheid leiden alleen maar tot meer leugens. Alle spelers delen dan ook openlijk de werkelijke status van hun werk, hun voortgang, hun inschattingen, hun problemen en hun moeilijkheden. Alle spelers staan echter ook open voor het feit dat softwareontwikkeling gebeurt door en voor mensen. Mensen zijn geen ‘resources’, robots of vervangbare machineonderdelen.

De spelers tonen openheid voor samen-werking met andere disciplines en functies, openheid om functieomschrijvingen te overstijgen. Ze tonen openheid naar de stakeholders en de bredere omgeving. Ze delen openlijk feedback en geleerde lessen. De spelers in Scrum staan open voor verandering, aangezien ze erkennen dat hun organisatie en de wereld waarin zij en hun organisatie opereren voortdurend veranderen – vaak erg onverwacht en onvoorspelbaar, maar wel voortdurend.

Respect

Binnen het bredere ecosysteem dat ontstaat rond Scrum heerst een sfeer van respect: respect voor mensen, voor de andere spelers en de andere teams; respect voor hun inzichten, kennis en ervaring, respect voor hun afkomst en persoonlijke achtergrond. De spelers respecteren – en waarderen – diversiteit als bron en sleutelelement voor nieuwe en mogelijk conflicterende ideeën. Ze hebben respect voor andere meningen.

De spelers van de teams tonen respect voor de omliggende organisatie door zich niet te gedragen alsof ze op een afgelegen eiland werken. Er is respect voor klanten, gebruikers en hun veranderlijke verwachtingen of ideeën. Teams tonen respect voor sponsors en geldschieters door geen features te behouden die toch nooit gebruikt worden, en die uiteindelijk slechts de onderhoudskosten van de software verhogen. Teams tonen respect door geen tijd, inspanningen en budget te verkwisten aan taken, producten of productonderdelen die geen waarde hebben, niet gewaardeerd worden, noch door de gebruikers, noch door de organisatie. Ze respecteren gebruikers door de problemen die deze ondervinden, op te lossen. Teams tonen zich respectvolle professionals door geen crappy software in productie te zetten.

Alle spelers respecteren de regels van het Scrum framework en de aansprakelijkheden die daaruit voortvloeien. 

Moed

Alle spelers tonen moed door geen software te bouwen waar niemand op zit te wachten. Moed zit vervat in de onderkenning dat requirements nooit perfect zijn, en dat geen plan ooit de complexe werkelijkheid kan voorspellen.

Men toont moed als veranderende inzichten, meningen en verwachtingen als een bron van inspiratie en innovatie worden beschouwd, in plaats van als een bron van ergernis. Het vergt moed om tijdelijke opleveringen uit te voeren, software te tonen die niet volledig en perfect lijkt, maar wel waarde levert of toevoegt. Alle spelers tonen moed door op elk gewenst moment de noodzakelijke informatie te delen die het team en de organisatie vooruithelpt. Spelers zijn moedig als ze erkennen dat niemand perfect is. Er is de moed om meer of minder radicaal van richting te durven veranderen, om een ander idee dan het eigen idee te omarmen, moed om zowel risico’s als voordelen te delen. Het vereist moed om de oude, valse zekerheden los te laten.

De spelers tonen moed als ze Scrum correct toelichten als een empirisch proces, vanuit de moed om toe te geven dat aanpasbaarheid de enige wijze is om met complexiteit om te gaan. Ze hebben de moed om de kernwaarden van Scrum te leven en te beleven, om een beslissing te nemen, tot actie over te gaan, niet tot een impasse verleid te worden, en vervolgens de moed tonen om genomen beslissingen op basis van ervaring opnieuw kritisch tegen het licht te houden en bij te sturen.

Noot:

Gunther Verheyen - Scrum Wegwijzerverheyen-gunther-scrum-a-pocket-guide-2016Bovenstaande tekst is een extract uit mijn boek “Scrum Wegwijzer” (2016, oa. verkrijgbaar via Managementboek.nl). Dit is de Nederlandse vertaling van mijn “Scrum – A Pocket Guide” (2013, oa. verkrijgbaar via Managementboek.nl).

There’s value in the Scrum Values

Scrum is not a methodology. Scrum is a process, but of a non-repeatable kind. Scrum is a framework of rules, roles and principles. The framework helps people and organizations discover what works best for them. Their real process emerges, and is specific and fitting to their time and context. Scrum can wrap existing product development practices or render them superfluous. The benefits of Scrum are greater when complemented by improved or revised engineering, product management, people and organizational practices. The prescriptions of Scrum have been limited to the essence. Every element of Scrum has a goal. Changing the core design of Scrum, leaving out elements, not playing the game by its base rules, covers up problems and limits the benefit of Scrum and any additions on Scrum, up to the level of making it utterly useless.

Less known than the process of Scrum and probably under-highlighted, but therefore not less important, are the core Scrum Values upon which the framework is based: Commitment – Focus – Openness – Respect – Courage. These values relate to the ethics of Scrum, thereby -from a social point of view- turning Scrum into a value system.

Scrum Values

Although not invented as a part of Scrum, or exclusive to Scrum, these values give direction to our work, our behavior and our actions. In a Scrum context the decisions we take, the steps we take, the way we play Scrum, the practices we add to Scrum, the activities we surround Scrum with should re-enforce these values, not diminish or undermine them.

I have found it very useful to bring these more out in the open, as a way to assess the desirability our actions and activities. It’s even a great help in thinking about applying the Scrum framework itself. It is possible to do Scrum as if it was a methodology; organize the meetings, direct all players on every possible detail for every possible action within the framework. But is the framework then being used for what it’s designed for? Won’t it leave the individual, the team and the organization with limited improvements?

A good illustration is how I’ve observed some teams doing their Daily Scrum. Everybody answers the 3 questions (Done? Planned? Impediments?), in a slightly spontaneous way or -worst case- when asked for by a Scrum Master-pretend. But does the team use the meeting to share information, to collaborate in re-planning their work for that day, making sure they don’t get out of line with one another for more than 24 hours, to get the most out of the Sprint, in moving forward to the Sprint goal? Or do they talk to the board instead of to each other? Do they only use the meeting to make sure that the board holds all their micro-tasks so their work is logged?

Here’s some detailed view on the values, and how they can guide our actions and behavior in a Scrum context:

Commitment

There is a widely spread misinterpretation of the word commitment in a Scrum context. This originates mainly from the past expectation of Scrum for teams to ‘commit’ to the Sprint Goal and the selected Product Backlog items. Upon the old, industrial thinking (that ruled software development for too many years) this was wrongly turned into the expectation that all scope would be delivered, no matter. ‘Commitment’ was wrongly turned into a hard-coded contract although it was always intended as an indication that the team would do the maximum possible effort in the Sprint and be completely transparent about progress. And in the complex, creative and highly unpredictable world of software development a commitment on scope is impossible anyhow.

And the definition of the word, according to Oxford Dictionaries, describes exactly how it was originally intended in Scrum:

Definition of Commitment

So, commitment is about dedication and applies to the actions, the effort, not the final result.

Yet, in the Scrum Guide we replaced commitment as a result of the Sprint Planning with forecast. Because of the relationship with scope it helps getting explicitly rid of the wrong interpretation. And fortunately ‘forecast’ greatly aligns with the empirical nature of Scrum too.

Still, commitment is and remains a core value of Scrum.

We commit to the team. Commit to quality. Commit to collaborate. Commit to learn. Commit to do the best we can, every day again. Commit to the Sprint Goal. Commit to be professional. Commit to self-organize. Commit to excellence. Commit to the agile principles. Commit to create working software. Commit to look for improvements. Commit to the Definition of Done. Commit to the Scrum framework. Commit to focus on Value. Commit to finish work. Commit to inspect & adapt. Commit to transparency. Commit to challenge the status-quo.

Focus

An iterative-incremental approach like Scrum and the time-boxing of Scrum allow us to focus. We focus on what’s most important now without being bothered by considerations of what at some point in time might stand a chance to become important. We focus on what we know now and YAGNI (You Ain’t Gonna Need It) helps retaining that focus. We focus on what’s most nearby in time as the future is highly uncertain and we want to learn from the present to gain experience for future work. We focus on the work to get things done. We focus on the simplest thing that might possibly work.

Openness

The empiricism of Scrum requires transparency, openness. We want to inspect reality in order to make sensible adaptations. We are open about our work, our progress, our learning and our problems. But we are also open for people, and working with people; acknowledging people to be people, and not resources, robots or replaceable pieces of machinery as software development -after all- is still the work of humans. We are open to collaborate across disciplines and skills. We are open to collaborate with stakeholders and the wider environment. Open in sharing feedback and learn from one another. Open for change as the organization and the world it operates in change unpredictably, unexpectedly and constantly.

Respect

We show respect for people, their experience and their personal background. We respect diversity (it makes us stronger). We respect different opinions (we might learn from it). We show respect for our sponsors by not building features that nobody will use. We show respect by not wasting money on things that are not valuable or might never being implemented or used. We show respect for users by fixing their problems. We respect the Scrum framework. We respect our wider environment by not behaving as an isolated island in the world. We respect each other’s skills, expertise and insights. We respect the accountabilities of the Scrum roles.

Courage

We show courage in not building stuff that nobody wants. Courage in admitting requirements will never be perfect and that no plan can capture reality and complexity. Courage to consider change as a source of inspiration and innovation. Courage to not deliver undone software. Courage in sharing all possible information (transparency) that might help the team and the organization. Courage in admitting that nobody is perfect. Courage to change direction. Courage to share risks and benefits. Courage to promote Scrum and empiricism to deal with complexity. Courage to let go of the feint certainties of the past. We show courage to support the Scrum Values.

Scrum: Framework, not methodology

Scrum is not a methodology

Scrum has no exhaustive and formal prescriptions on how to design and plan the behavior of all software development actors against time, let alone how these designs and plans must be documented and stored. Scrum has no rules for upfront predictions of document types and deliverables to be produced or the time of their production. Instead of installing and thriving on hand-overs, toll gates and control meetings like software development methodologies typically do, Scrum removes them as a major source of delays and waste.

Methodologies are composed of stringent and mandatory sequences of processes and procedures, implementing predefined algorithms. As such, methodologies tend to replace the creativity, autonomy and thinking of people with components like phases, tasks, must-do practices, techniques and tools. As long as the methodology is being followed everyone feels safe, because they are formally covered, even in the absence of working results. Methodologies depend on high degrees of predictability, otherwise the preset algorithms fail.

Scrum is the opposite of a big collection of interwoven mandatory components. Scrum is not a methodology. Scrum implements the scientific method of empiricism. Scrum replaces a programmed algorithmic approach with a heuristic one, with respect for people and self-organization to deal with unpredictability and solving complex problems.

Is Scrum a process?

If Scrum is a process, it is certainly not a repeatable process. That’s often a challenge to explain, because the term ‘process’ typically invokes algorithmic predictable steps, repeatable actions and enforceable top-down control; the sort of expectations for a… methodology.

Scrum is not a commanding process. If referred to as a ‘process’, then Scrum is a servant process. What works best for all involved players, their working process, emerges from the use of Scrum. The players discover the work required to close the gap between an inspected intermediate result and an envisioned outcome. Scrum is a process that helps surface the real process, structures and a way of working that are continuously adapted to the actual context and current circumstances. Therefore we prefer to call Scrum a… framework.

Scrum is a framework

Scrum as a framework describes roles and rules upon principles that help and facilitate people in a low-prescriptive way. The Scrum Guide holds the definitive description of these base rules of the game. The prescriptions are minimal, but every single one of them addresses a common dysfunction of software development.

Over the nearly 20 years of Scrum, the rules of Scrum, as captured in the Scrum Guide, have gradually evolved, with small functional updates and releases. The prescriptions of Scrum, what needs to be in place to have the full benefits of Scrum, becomes more and more focused on emphasizing ‘what’ is expected in developing complex products over instructing ‘how’ to do it.

A good illustration of such an evolution is the elimination of burndown charts from the Scrum framework as mandatory (the ‘how’). This obligation however has been replaced by the explicit expectation that progress on the mandatory Scrum artefacts, the Product Backlog and the Sprint Backlog, is visualized (the ‘what’). The form or format of the visualization is no longer prescribed, thereby turning burndown charts into a non-mandatory, but still good practice; a good way to play the game suitable in many situations.

Yes, it’s Scrum if the Backlogs exist and a visualization of their progress is available, accessible and clear. This may be a burndown chart with open effort. It may also be a burnup chart in value. It may be a Cumulative Flow Diagram. It may be as simple as a Scrum board.

The Scrum framework leaves different options and tactics to play the game, ways that are at any time adopted to the context and circumstances. The Scrum core values give direction to the actions, the behavior and the additions to the framework. Upon that core, in a ScrumAnd way of thinking many opportunities emerge. Have a look at some illustrations of ScrumAnd.