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 still 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 three questions are addressed, not to blindly answer them from a ‘best practice’ viewpoint.

The house we didn’t know we wanted (the surprise that 2014 brought)

After the silent resurrection of 2010-2011 (with the birth of our daughter and my re-discovery of the path of Scrum) 2012 was a pivotal year. 2013 subsequently was pretty explosive in growth and global expansion of our views and lives. The first half of it, 2014 was turning out what we were hoping for, a year to harvest, a year to reap some fruits of those preceding years. But in June things changed. Unexpectedly.

A couple of years ago my wife had clearly hinted at spending our yearly holidays in the US in 2014. It had something to do with her reaching an unspeakable age in 2014. Part of the preparation for that trip was ordering a wheel chair for our son, who has Duchenne Muscular Dystrophy, to help us move faster through New York City.

IMG_1377The wheel chair made us realize that our house in the future would require more adaptations than we had already made for our son. We didn’t like that. What manifested suddenly was a partial elucidation on our overall feeling of being locked in. It explained how we made many considerations over the past years on our house, plans that were never made real. That was only re-inforced by looking beyond today and beyond tomorrow, into the future where both our sons, one with DMD and the other with Down Syndrome, might just stay at home always given their disabilities.

So, suddenly we found ourselves in a position that we were looking for a new house, something that we had never before even considered or were aware of. It was unexpected. Not unpleasant. We felt the urgency.

And then urgency was followed by opportunity. A rare combination, and we moved fast.

IMG_1794We discovered a beautiful house, built in 1975, having the amount of ground floor we were looking for (thinking of our son’s immobility), the space we were looking for (thinking of the long-term future). It had character and style, a rural look that we immediately fell in love with. It was not too far from where we lived. But… way beyond our budget. Or so we assumed. We went to visit the house, discovered it was more of a project than a house, but our minds were stuck on it. We discovered that rate of interests are historically low (a ‘positive’ effect of the banking crisis), and that the sellers of the house were willing to give in on their asking price. The smell of opportunity.

We decided to jump. The day before we took off for the States we signed all papers at the bank and the contract was finalized! We had a wonderful holiday in the US, and our fall was spent dreaming of our new house, and obtaining the keys on October 7th.

IMG_1914We subsequently set a goal, i.e. to spend Christmas in our new house. It was not a realistic goal, looking back. It required some miracles, like removing old carpets, scraping off old wall paper, getting craftsmen in to sandblast and clean old wooden stairs and floors, to check the plumbing, to order and get a new stone floor laid, to assure some base electrical installations, to pack and arrange the moving, to start selling our old house, and much more. IMG_2369But we made it. On Monday December 22nd we moved over all large furniture and spent our first night in our new, little cottage.
During the first week we only lost power 3 times and some other minor outages, problems that were all fixed at the root and would not have been discovered so quickly if we hadn’t just moved in like we did.

Now, the rest of our years can be spent on further renovating, redecorating, refurbishing, expanding, and restoring all sorts of facilities, hopes and dreams. It’s good to be fully aware of the fact that nothing ever is complete. It explains our restlessness. I am glad that it got restated in all of its beauty in our hearts and minds by getting a house that 6 months ago we didn’t know we wanted.


2014 in review – Blog statistics (Gunther Verheyen)

2014 has been, in many regards, a fascinating and surprising year. Part of it is reflected on my blog, the part that says how important Scrum has become in my life. The majority of my blog notes are about Scrum. It also is an indication that my writing energy was spent on this, and not on the many personal topics and interests that I also wanted to blog about. Life is hard, life is full of choices.

The WordPress.com stats helper monkeys prepared a 2014 annual report for my blog. If you’re into statistics, enjoy it.

Best wishes for 2015

Warm regards

Here’s an excerpt:

The concert hall at the Sydney Opera House holds 2,700 people. This blog was viewed about 26,000 times in 2014. If it were a concert at Sydney Opera House, it would take about 10 sold-out performances for that many people to see it.

Click here to see the complete report.

Scrum Master – A Manager

Manager – Traditionally

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

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

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

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

Management – Actually

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

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


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

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

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

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

Manager – A Scrum Master

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

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

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

Management – Definitely

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

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

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

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

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

Introducing “ScrumAnd”

Jigsaw Scrum

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

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

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

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

ScrumAnd (Scrum Master)

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

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

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

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

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

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

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

Product Backlog and the Tea Leaves Effect

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

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

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

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

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

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

Courage and Accountability (go hand in hand)

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

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

Accountability complements Collaboration

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

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

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

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

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

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

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

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

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

Scrum foresees clear accountabilities:

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

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

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

Commitment mirrors Accountability

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

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

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

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

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

Transparency Serves a Purpose

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

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

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

Some illustrations

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