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 Scrum.org you will also find a Scrum glossary. To be honest, I never checked mine against the one on the Scrum.org 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 EMPLOY EMPIRICISM TO OPTIMIZE THE VALUE OF THEIR WORK.

Where:

  • 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

A Software Development Profession

Creative, artful thinking and craftsmanship are ESSENTIAL QUALITIES for any software developer. But shouldn’t software development be about more than an act of art, a craft in best case? Isn’t there a need to add professionalism to it? Shouldn’t software development be a profession?

It is tempting to believe that software development already is a profession. After all, many people are employed in developing software, making a living out of creating and sustaining the working code of software products and services, as a team or as individuals. Many more are employed in and make a living out of all the side-activities in the wider software development industry; like funding, exploiting, selling, promoting software products and services. This however is not sufficient to state that software development already is a profession.

Some take their dreams for real and call software development a profession. For others it is more a matter of pride, status or ego to say they are part of a profession, instead of an artisan discipline. That still is not enough to state that software development already is a profession.

A profession has regulations, codes, expectations and rules, all building upon a recognized body of knowledge. A profession sets explicit expectations on ethics, conduct and behavior to be demonstrated by any member of the profession. Official exams are in place for members to demonstrate a level of required skills and knowledge before receiving an attestation, and the permission to bear an official title that is protected and reserved. A healthy profession’s regulations and standards have a purpose, a purpose that goes beyond self-serving the profession and the profession’s institute. All regulations and standards should serve to assure the best possible execution of work in order to protect the people and organizations taking part in or being subject to the profession’s activities and its outcomes, and the decisions taken as part of it.

It is difficult to predict if and when software development might transform into a profession. It seems unlikely in a short term. There is the gigantic amount of software development work, there are the endless variations of what might be considered ‚software development,’ the absence of a widely accepted definition and understanding of ‚software development,‘ disagreement over the work activities that should or should not be part of the profession.

Reasonable doubts may be expressed on whether being a profession will augment the quality of service, avoid charlatanism, etc.

Furthermore a variety of people and instances may have personal, political, career, financial or other interests in software development, possibly even outside of the activity itself. Such people and instances might see regulation as a threat to their interests. Or might see it just as a limitation to their artistic freedom. Not to speak of the difficulty in growing a body, ethics, assessments, instructional guidelines and a code of conduct that would be widely accepted within the industry.

Where there are many elements that probably impede software development from growing into a regulated profession, there are also very valid reasons why software development would be better off if it transformed into a profession.

Not the least reason is the overwhelming and crucial presence of software in society and our daily lives. Software has become increasingly vital to society. A major shift is happening. Software products and software services are at the front and at the back of many public, industrial and consumer services and facilities. Software no longer is a ‚nice to have,’ for amusement purposes only. Software is at the heart of the economy. Software is core to many, often even critical, services in the private and in the public domain; financial services, taxes, energy, retail, health care, education, defense, telecommunication, transport, the automotive industry, just to name a few. Numerous organizations thrive on software. Even when they are not software companies, their services largely depend on software.

The omnipresence of software leads to a huge demand for talented and skilled software development people. The demand for professionalism that goes beyond talent and skills is less acknowledged but equally important in the light of the crucial functions of software in society. It would be comforting to know that the level of professionalism shown in the industry grew at the same rate as the growth of presence and criticality of software products and services itself, although even a higher rate is required.

Software development deserves professionalism in doing and in managing it. Such professionalism would benefit much from being structured in a profession.

This post is one of the inquiries I have planned into the values of professionalism in software development and the potential of the scrum framework to induce the formation of a software development profession. A matter of incremental writing. I hope you enjoy it, and the future follow-ups and iterations.

Scrum – A Pocket Guide (3rd impression)

Gunther Verheyen, Scrum - A Pocket Guide (A Smart Travel Companion)Early 2013 I wrote the book “Scrum – A Pocket Guide“.

It was published in November 2013 by Van Haren Publishing. The pocket format used by my publisher coincides with the sub-title of the book “A Smart Travel Companion” and my views of Scrum as a journey, not a destination. Scrum is a journey toward increased agility, and my book is designed as a small guide that any traveler can easily take along.

Here’s what some of my best friends in the world of Scrum said about “Scrum – A Pocket Guide”:

Best description of Scrum currently available.

says Ken Schwaber, Scrum co-creator.

The book on Scrum I wished I had written.

says David Starr, also known as ‘Elegant Coder‘.

My publisher now informs me that the third impression is about to be produced (June 2014). It is still the first edition as the content is stable. The second impression dates from February 2014. I am humbled by this success and grateful for the appreciation.

If you have read the book, leave a review at Amazon UK, Amazon.com, GoodReads or one of the other shops where the book can be found. It provides me and potential readers with very valuable feedback.

Although Van Haren Publishing has its head quarters in the Netherlands, they have a great global distribution network. Here are some sources where “Scrum – A Pocket Guide (A Smart Travel Companion)” is available from, in varying formats:

And find many more search results at Google (24900 results), Bing (1110 results), Yahoo (1140 results).

Scrum Day Europe 2014

As from 2011 there has been a genuine boom of Scrum in the Netherlands. And it is still going on. A virus improving the lives of many people in the fascinating world of software development. I have worked with several Dutch organizations, of which ING is probably one of the biggest, one that I documented by the end of 2012.

In March 2012 Ken Schwaber, Scrum co-creator and my working partner at Scrum.org, asked whether I saw room for a Scrum event in the Netherlands. Yes, and we named it “Scrum Day Europe”. We set it up with 3 co-organizing companies around the ideas of “Software in 30 Days”. The goal was not to make it just another average agile event, so we went for a smaller event, with a clear management focus and much room for interaction. It turned out a great success, so a 2013 edition was organized with some small, incremental changes. Ken and I opened the 2013 edition with a keynote on the Agility Path framework for Enterprise Scrum that we were working on.

ScrumDay4Pros-logo_whiteThis year, 2014, will see the 3rd edition of the Scrum Day Europe event. The event is now part of Scrum.org’s prestigious Scrum Day for Professionals series. We have limited the co-organizing companies to our Scrum.org partner-in-principle Prowareness and have complemented that with a more substantial involvement of the communities. Because, in the end, Scrum.org’s role is to serve, help and facilitate the many Scrum practitioners out there, and this event is a great way to connect people and ideas.

The theme of 2014 will be “Evidence-Based Management”, on which I recently published a whitepaper called “Empirical Management Explored: Evidence-Based Management for Software Organizations“.  Ken and I will have the pleasure of opening the event again.

I look forward to meeting with great fellow Scrum travelers at the event, hoping YOU will be one of them. Have a look at the program and the speakers. Get your ticket via the Scrum Day Europe website, or directly at Scrum.org.

Scrum Day Europe 2014

Find all information on Evidence-Based Management at ebmgt.org.