Tag: Scrum

Posted on by — 4 Comments

Tactics for a Purpose – The Daily Scrum’s questions

In my book “Scrum – A Pocket Guide” I distinguish the rules of Scrum from tactics to implement the rules.

  • The rules of Scrum reflect the principles, values and empirical foundation of Scrum. They provide boundaries and a frame to augment self-organization.
  • Tactics are possible good practices. A tactic should be selected, tried and tested, made right-size and fitted to context and circumstances, or be rejected.

Over the years the basic elements of the Scrum framework remained the same, as did the principles and rules that bind them together. But the mandatory prescriptions of Scrum grew… lighter. The focus shifted toward describing ‘what’ is expected as opposed to instructing ‘how’ to achieve that outcome.

There are many tactics to use within Scrum. Good tactics serve the purpose of Scrum. Good tactics re-enforce the Scrum values, rather than undercut them.

The Daily Scrum is a mandatory event in Scrum, a daily inspection of the team’s reality to adapt the Sprint plan to it. The Scrum Guide suggests that in the Daily Scrum every Development Team member answers three questions with regards to the progress of the team towards its Sprint Goal (Done? Planned? Impediments?).

Does that necessarily assure a great Daily Scrum?

Everybody might just answer the questions mechanically, as a personal status update, not opportunistically looking for the best way forward for the next 24 hours. They might be talking to the walls or to the Scrum Board, not exchanging information with the other team members. They might just make sure that they simply -well- answer the three questions, possibly just because the Scrum Guide says they must. The rules are formally followed without understanding the ‘why’ of the rules.

Is the team merely seeing Scrum as a methodology? Or is the team using Scrum as a framework for creativity, discovery and collaboration? Maybe the Daily Scrum event is only seen as an obligation, a meeting with a reporting purpose? Maybe the team feels pressured to make sure all their micro-tasks are logged, and they use the Daily Scrum to cover themselves against possible blame. It doesn’t help much when the three questions are merely formally answered, if the people involved don’t actually talk to each other. It doesn’t help much if no information is revealed that helps the team optimize its shared work plan for the next 24 hours against the Sprint Goal. The event turns into a missed opportunity to gain insight in the real situation, to inspect it and to adapt to it.

The goal of the Daily Scrum is to share information, and to re-plan the Development Team’s collective work so that they progress in the best possible way towards the Sprint Goal. That should be the background from which the Daily Scrum runs, not to blindly answer 3 questions from a ‘best practice’ stance.

Posted on by — 24 Comments

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

Indeed:

  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?

Posted on by — 5 Comments

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.

Note: in 2018 I elaborated on the topic by describing how the ScrumAnd stance requires though and discipline.

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?

Posted on by — 6 Comments

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?

Posted on by — 8 Comments

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, also one of the 5 Scrum Values.

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?
Posted on by — Leave a comment

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.

Posted on by — Leave a comment

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

Posted on by — 4 Comments

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.

Posted on by — 5 Comments

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

Posted on by — Leave a comment

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.