My Pocket Guide to Scrum

Scrum - A Pocket Guide (front)People learn about Scrum in various ways. Some read books. Some read my book:

Scrum – A Pocket Guide (A Smart Travel Companion)

  • Read a PDF excerpt from my book. It holds the foreword by Ken Schwaber, a short note by the early reviewers, the content table and the first chapter (‘To shift or not to shift’). A taste.
  • Get the full version at Amazon, Amazon UK, Van Haren’s webshop (the publisher), Or use good old Google.

My book serves to help the reader make better use of the tool that Scrum is.

My book introduces the rules and roles of Scrum while emphasizing their purpose. People can more effectively employ Scrum from an understanding of the purpose, rather than from mechanically following the ‘process’.

People are more capable of using Scrum to their advantage when understanding that Scrum is a framework laying out the boundaries within which people can deal with complex problems. My book distinguishes the rules of Scrum from tactics to apply the rules. My book has some examples on tactics, and where tactical decisions within the Scrum framework are required.

My book presents no universal truths, gives no universally applicable answers on generic questions, although I get asked such questions over and over again.

How long should Sprint Planning be? And the other meetings? How much time does the Product Owner role take? Is the Scrum Master role a full-time occupation? Should a team be available full-time? How must we organize when the team is distributed? How much time of a Sprint should a team spend on testing? What should be in the definition of Done? How many business analysts are needed in the team? What if… ?

I am extremely wary of being an ‘expert’ providing certainty where there isn’t. My book is a book for people on a journey to discover what Scrum can do for them. Hence its subtitle. My book does not map out your route. Your route is unique and distinct.

My book adds some historical perspective to Scrum, describes the roots of Scrum, how Scrum fits the Agile movement and what some future challenges of Scrum are.

My book “Scrum – A Pocket Guide” is not an expert book. It is not a book for experts. It is not a book by an expert. My book is a book by an eternal novice seeking mastery. I hope you like it. I hope it helps you seek mastery too.

Meanwhile I am in the process of creating a follow-up book. I will still not provide false precision. I might tell some stories about what worked for me, given context and time.


Agile Greece Summit – netweek interview

Yiannis Mavraganis and a crew of Agile enthusiasts organized the first Agile Greece Summit on Friday 18 September 2015 in Athens. It was an honor to be there and give a talk on Nexus and Scaled Professional Scrum. I hope attendants got many ideas and inspiration from the sessions and from sharing problems and insights. I hope it helps the Greek economy in these difficult times.

Netweek logoPreceding the event George Fetokakis published an interview with me in the Greek IT magazine netweek.

Netweek interview (Greek)The publication was in Greek. Thanks to George I can share the English version here. George published it under the header “Respect for developers”:

  1. What is Scrum?

Scrum is a lightweight framework for complex product development. Scrum has, by design, a minimal, yet sufficient, set of rules and roles. Scrum prescribes no techniques or practices to apply these rules to allow teams and organizations to devise the best possible tactics, depending on their context, to apply Scrum. 

All basic rules of Scrum are described in a lightweight document, the Scrum Guide, which is available at The Scrum Guide is maintained by the co-creators of Scrum, Jeff Sutherland and Ken Schwaber.

  1. Do you see any challenges in the organizations which use only Scrum? What do you think are some of the big threats to Scrum adoption or growth?

In my 2013 book, “Scrum – A Pocket Guide”, I describe two future challenges of Scrum. 

The first challenge concerns the way the role of the Product Owner is fulfilled. We often see that representatives or proxies of product management are fulfilling the role. The benefits realized through Scrum would be higher if product managers would directly engage in Scrum, through the role of the Product Owner.

The second challenge is the improved understanding and adoption of Scrum by management, think about operational IT management, sales divisions, delivery managers, product departments and hierarchical CxO management.

I would add a third challenge, related to scaling. Many organizations have adopted Scrum and see the benefits at the scale of one or some teams. Organizations pursue the same benefits with many teams, but struggle in scaling Scrum while respecting the principles and foundations upon which Scrum are built.

  1. Why should a Development Team choose Scrum?

Scrum thrives on self-organization, inviting and inspiring Development Teams to plan, organize and track their own daily work. Product Owner set out a vision and goals against which Development Teams work. Stakeholders are expected to provide the Development Team with new or changing insights by the end of every Sprint. A Sprint takes no more than 30 days, and is often shorter.

Scrum fundamentally restores the respect for the creativity and intelligence of Development Teams, allows them to fully exploit their skills and insights.

  1. What is Scaled Scrum and how important is this method for big software development projects?

‘Scaled Scrum’ is any implementation of Scrum in which multiple Scrum Teams create one software system or product. The purpose of Scrum, independent of the scale at which it is used, is to create high-quality, releasable versions of product by the end of every Sprint. This allows organizations to quickly and regularly serve their customers, and to incorporate feedback into the development process fast. It is what we call ‘business agility’. It is crucial for companies to survive and prosper in today’s fast changing economy.

At a larger scale, keeping a high level of such agility is highly important. It assures companies of flexibility and responsiveness. Translated to the adoption of Scrum for product development, it holds that the big challenge of scaled Scrum holds the ability for multiple teams to produce releasable software by the end of every Sprint.

Our Nexus framework provides organizations with guidance on how to grow and scale Scrum, on how to implement Scaled Professional Scrum.

We recently published the Nexus Guide at our website,

A Professional Organization Defines Quality

An often observed problem of Scrum adoptions is the isolated way that Scrum Teams operate, being or acting as if detached from the wider organization. There are several possible causes, one of them being the disconnect between people creating standards and people implementing upon those standards.

An organization that thrives and depends on software products and services can be expected to have a definition of product qualities in place, and to express such through standards, guidelines, rules, service levels and other expectations. Scrum Development Teams, consisting of professional product developers, are an integral part of an organization, rather than being isolated gangs of thug coders within the organization. Such Development Teams can be expected to adhere to overarching product standards.

It explains why, on the topic of the creation of a definition of Done, the Scrum Guide says (see

If the definition of “done” for an increment is part of the conventions, standards or guidelines of the development organization, all Scrum Teams must follow it as a minimum. If “done” for an increment is not a convention of the development organization, the Development Team of the Scrum Team must define a definition of “done” appropriate for the product.

If, as can be expected, the minimal definition of Done is provided by the organization, a Development Team can still complement it with context-specific elements; the product, a release or technology.

If organizational guidelines are not provided, a Development Team should, as professionals, create an appropriate definition of Done for their development. How else does a team know what work to do, what tasks to undertake, if it doesn’t know, and have a shared understanding of, the characteristics of the Done or end product? How else can Product Owners and stakeholders know what quality they will be receiving? Quality should not be their concern, or their primary focus. Market reception, business opportunities, offered functionality should be.

The lack of such standards or provision of them is therefore also best raised within the organization to serve wider organizational improvement. Remember that such improvement will also benefit others within the organization.

Scrum can be a lever for organisational improvement. Scrum Master is a servant-leader role for the organization too.

Often organizations provide a list of guidelines that is presented as ‘minimal’, yet proves to be unrealistically long and heavy. This again is a great area for conversation, improvement and removal of organizational waste. The organization might have not adapted their standards and expectations to the reality of iterative-incremental development, or their standards might for a long time have not been matched against actual implementation of them. ’Standards’ might be in place that were created as part of long, sequential processes where quality problems typically accumulated heavily before they were detected. As the people maintaining standards typically do not engage in creating quality upon those standards they start adding demands to the expectations that prescribe the delivery of proof that ‘quality’ is created. They started confusing defining quality (‘what’) with evidence of quality ‘(how’).

Avoiding the conversation is not helpful. Self-organization is not an excuse to do so. A Development Team might push back toward a realistic definition of Done with arguments on how they will actually build in quality, Sprint after Sprint after Sprint. A feedback loop from practice to theory is best established. It is important, and often surprisingly revealing, for the people creating standards to experience what practical application of these standards entails, or what waste is in them when iterative-incrementally delivering versions of releasable product.

Quality, in the end, is in the product, not in paper documentation. Paper documentation allows lies and illusions of quality, working software doesn’t.

Scaled Professional Scrum – Nexus (Nederlandstalig)

Op de  website publiceerde ik recent de whitepaper “Scaled Professional Scrum – Rationale of the framework” (PDF).

Hierbij vindt de geïnteresseerde lezer dit document in (een licht aangepaste) Nederlandstalige versie terug als “Scaled Professional Scrum – Whitepaper (Nederlandstalig)”.


Scrum is een framework voor complexe productontwikkeling.

  • “Scaled Scrum” omvat elke implementatie van Scrum waarbij meer dan één team een product realiseert.
  • “Scaled Professional Scrum” omvat elke implementatie van scaled Scrum die bouwt op de fundamenten, principes en waardes van Scrum, met inbegrip van software development professionalisme.

Het framework voor Scaled Professional Scrum van biedt de ruggengraat waarop organisaties hun productontwikkeling op basis van Scrum kunnen opschalen mèt behoud van de eigenheid en de voordelen van Scrum. Het framework bundelt de practices, ervaringen en inzichten van een wereldwijd netwerk van experten, waaronder Ken Schwaber en Jeff Sutherland, co-creators van Scrum.

Het kloppend hart van Scaled Professional Scrum is een Nexus, een ‘exo-skeleton’ voor Scrum. Een Nexus implementeert het Scrum proces zodat 3-9 Scrum Teams zo efficiënt mogelijk gezamenlijk aan één product kunnen werken.


Het Scaled Professional Scrum framework bevat 40+ practices. Elk van deze practices, indien met kennis en kunde geselecteerd en geïmplementeerd, kan de werking van een Nexus optimaliseren naar een specifieke context.

Introducing Scaled Professional Scrum – Nexus

Scrum is a framework for complex systems development.

  • Professional ScrumScaled Scrum is any instance of Scrum involving more than one team creating and sustaining a product or system.
  • Scaled Professional Scrum is any instance of scaled Scrum that thrives on Scrum’s formal rules and roles, complemented by software development professionalism, and Scrum’s values and principles.

The Scaled Professional Scrum framework of provides guidance to organizations engaging in efforts to scale their product development done through Scrum. The framework cohesively integrates practices, experience and insights gained from efforts to scale Scrum worldwide, including the substantial efforts that involved Ken Schwaber and Jeff Sutherland, co-creators of Scrum.

At the heart of Scaled Professional Scrum is a Nexus, an ‘exo-skeleton’ for Scrum. A Nexus employs the Scrum process to inter-connect 3-9 Scrum Teams building one product.


The Scaled Professional Scrum framework holds 40+ practices. Each of these practices, if chosen and used against context, augments the operation of the Nexus.

The whitepaper “Scaled Professional Scrum – Rationale of the framework” (PDF) is now available through the website.

At the “Scrum Day Europe” event of July 2 in Amsterdam I introduced the Scaled Professional Scrum framework of and the Nexus in my opening keynote. Find the presentation at SlideShare. The recording of the session is available at YouTube.

Traces of Scrum (Scrum Days Poland)

On May 28 and 29 the first Scrum Days Poland were organized. A great team made it happen, gently directed by two friends of the trainer community, Kate Terlecka and Tomek Wlodarek. Kate and Tomek were so kind to invite me for two sessions at the event:

  • In the executive track I spoke about ‘Empirical Management’. Find the slide deck at SlideShare.
  • For the main event I was asked to do the closing keynote, which was about ‘Scaled Professional Scrum’. Find the slide deck at SlideShare.

Apart from these sessions, I was asked for some thoughts on Scrum by different people:

1/ On behalf of the organization, Paweł Feliński checked in with me on some topics with regards to Scrum, and the adoption of Scrum:

2/ Leszek Pietrzkiewicz went around asking some people, including myself, to ‘describe’ Scrum in one word:

3/ Leszek Pietrzkiewicz asked me ‘Why do Scrum?’

4/ Andy Brandt, another Polish Professional Scrum Trainer, asked me some questions about Product Ownership, questions he typically gets from the attendants of his PSPO classes:

I applaud the local organizers for setting up such a great conference. I am grateful for being at the conference, meeting people and expressing the above thoughts. Traces of Scrum.

Celebrating two years at (#frwrks)

March 2013, Amsterdam. Ken Schwaber and I semi-simultaneously express the thought that there is likely more value in us engaging in a close partnership. We already have a pretty intense collaboration at the time. I decide to leave consulting, a well-known environment that I have been in for twelve years. I take some time off, do a couple of Professional Scrum classes, and lay the foundation for my book „Scrum – A Pocket Guide (A smart travel companion)“.

June 1 2013, Boston-Antwerp. I embark on this somewhat unexpected journey of working at the home of Scrum,

Over these past two years a three-fold pattern of activities emerged being part of the team:

  • Shepherding the Professional series. Developing and sustaining Professional Scrum assessments and courseware, training trainers, working with the global community of Professional Scrum experts and within the small-ish, creative organization of
  • Representing Ken and in Europe. Visiting partners and friends of, and taking up speaking and learning engagements.
  • Teaming up with Ken. Engaging in all sorts of interesting development activities, with the most important thread probably being the road from Agility Path to Scaled Professional Scrum and the Nexus.

Not working for a traditional enterprise turned out such a relief, the end of thinking and acting in terms of money and commercial motives only. No hour-based work, no office hours, working (mainly) from my home office, no timesheets. Instead mission-driven efforts, autonomy and valuable goals. Money is obviously important, up to the level of being able to pay our people a decent salary and to invest in the community. Beyond that however our goal is to support people, teams, organisations, with resources for assessment, improvement, maturing Scrum, growing professionalism, improving the profession of software development. It is not the most common model for a business, but it is what we do.

The two years at have shown me that there IS an alternative to the traditional way to run a business, an alternative that is financially viable, yet doesn’t revolve exclusively around financials.

Over these two years I’ve maintained mental stability, remained sane. No different than in every other environment I’ve worked in before, I’ve had my crises, my identity doubts, my ups and downs. I’ve come to terms with aspects of me that used to confuse me in the past, often in my past positions as Scrum Master. I’ve come to terms with blending in and still not fitting in. The best and most fascinating relationships are developed by not fitting in. It took me years to accept that, let alone exploit that. It’s a solid basis to continue my journey, my remarkable cobblestone path.

I wish you all the best. I thank you for all the inspiration. I am proud to be able to continue serving many Scrum professionals around the globe.


Shepherding the Professional series

Ullizee -Seal