Scrum – It is what it is.

And I don’t intend to say that with a negative perspective.

Quite often people wonder why Scrum – a framework for complex product development – has the rules as described in the Scrum Guide. The authors of Scrum (Ken Schwaber and Jeff Sutherland) say that the framework contains the roles, events, artifacts, and the rules that bind them together necessary to operate. Adding, changing or removing something will not make it Scrum anymore and a Scrum team will not work optimally.

Quote by Ken Schwaber:

“Scrum is a general-purpose framework applicable in complex situations, where more is unknown about the parameters than is known. The rules of empiricism and self-organizing make it work within short iterations that control the risk and increase chances of finding answers and creating value. The few roles, artifacts and events are fixed so the Scrum team can focus on unraveling complexity.”

What’s your opinion?

Read the original blog posts here.

The house of Scrum

Scrum… is a means to an end, a tool designed for a purpose: people, agility, value.

There’s no need to re-describe Scrum. If you’re on a journey to discover Scrum, I welcome you. I do advice you to learn more than Scrum, and to also discover agile & lean.

I greatly recommend the collection of articles by Mike Cohn and Alistair Cockburn.

After attending a few presentations and after reading the small book “Scrum, a pocket guide”, I pleasantly appreciate Gunter’s writing on the topics of Agility and Scrum. I do encourage you to read these articles and I equally recommend that little book. It’s written in an honest way, and offers transparent descriptions.

Hereby a bunch of excerpts and links (all text is copy paste of blogs):

Agile and Scrum, entwined and related

Agile and Scrum, actually, are not interchangeable synonyms, but two inseparable ingredients in a software development ecosystem, pure chemistry.

Agile are the principles to Scrum, Scrum is a foundation for agility.

Read more…

The Scrum Stance

People employ empiricism to optimize the value of their work.

Read more…

Agility via Scrum

Agility is a state, a way of being; of people and of organizations. It is not a process, it is not a method. It is a state from which emerges flexibility, openness for change and fast responses to market changes. Scrum has become the most important Agile framework, allowing people and organizations to achieve this state of Agility. Scrum brings the rules and principles to organizations and their people to grow into this state of flexibility.

Read more…

To shift or not to shift (the software industry paradigm)

The software industry has for a long time been dominated by industrial views and beliefs. The universally accepted paradigm was in fact a copy-paste of old industrial routines and theories.

Although it was not widely and consciously admitted, but this did put the software industry in a serious crisis.

The House of Scrum The House of Scrum

The house of Scrum offers an open view on the world, while protecting from rigid behavior. Its inhabitants remain flexible at all levels to better deal with uncertainty, and shape -not predict- the future. They sense, probe and adapt at all levels. Scrum drives building better software products, and faster. In 30 days, or less. But, most of all, it restores energy and work pleasure for all involved.

Read more…

Scrum Values

Less known and probably under-highlighted, but therefore not less important, are the core Scrum Values upon which the framework is based.

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

Scrum values:

  • Commitment
  • Focus
  • Openness
  • Respect
  • Courage

Read more…

Yes, we do Scrum. And…

An article about doing Scrum, and improving beyond Scrum. It also describes Common adoption path of Scrum.

The Blending Philosophies of Lean and Agile

Beyond the clear similarities in Lean and Agile thinking, Agile has distinct practices that match the main Lean principles.

Read more…

Maximizing Scrum

It’s not only about “scaling”. It’s about “maximizing”.

Enjoy the scaling effect of maximizing. If you run out of improvements, consider adding teams. Choose wisely where you want to invest in first.

Read more…

Accountability is a quality of agile

In a context of Scrum the described inverted form of accountability leads to exactly the opposite of the Scrum tenets; cross-functional collaboration, utilizing collective intelligence, bottom-up knowledge creation, shared goals. Yet, accountability is essential. The false application of it doesn’t reduce 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 a clear accountability for each Scrum role:

  • 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 the understanding and application of Scrum.

These accountabilities are separated, yet all are 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.

Read more…

Done is a crucial part of Scrum, actually

Done Increments are THE way to achieve agility through the empiricism of Scrum.

The empiricism of Scrum only functions well with transparency. Transparency requires common standards to work against and to inspect upon. The definition of done sets the standard for releasable.

The definition of done is essential to fully understand the work needed to create a releasable Increment and for the inspection of that Increment at the Sprint Review. The definition of done serves the transparency required in Scrum in terms of the work to be done and the work actually done.

Read more…

Scrum, actually

Scrum, actually, in itself is not the purpose. Scrum is a tool. Scrum enables people to live the art of the possible, to make the most out of every single day constrained by their means, to maximize the value of their work in the face of uncertainty.

Scrum, actually… is a means to an end, a tool designed for a purpose: people, agility, value.

Read more…

Releasable in Scrum, actually

The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment. (…) This Increment is useable, so a Product Owner may choose to immediately release it. (Source: The Scrum Guide)

In Scrum, actually… releasable means all work done to release to the market. Instantly.

Read more…

Agile and Scrum, actually

As with Agile, the Scrum Values and Scrum’s fundamental roles and rules as described in the Scrum Guide don’t change with scale. But scaled implementations of Scrum require different tactics in implementing the rules.

In Scrum, actually… Agile is the DNA driving the behavior throughout the software development ecosystem.

Agile and Scrum, actually, are two inseparable ingredients in a software development ecosystem.

Read more…

Meetings in Scrum, actually

Scrum’s events serve the empiricism that Scrum brings to software development. Empiricism thrives on inspection & adaptation. Inspection & adaptation happens at a frequency, in regular intervals. Adaptation only makes sense when inspection is done against reality, when the actual situation is made transparent.

In Scrum, actually… meetings are opportunities where people meet to change their mind.

Read more…

Team size in Scrum, actually

Try something you believe might work for you. Inspect it, adapt to your findings. Repeat. When heavily constrained in doing this, sticking to the guidance of having 3-9 people in a Development Team is a good idea.

In Scrum, actually… team size is a team decision.

Read more…

Velocity in Scrum, actually

Velocity in Scrum actually is an indicator of productivity, an indicator of how much software, preferably releasable software, a team has produced in a Sprint. That in turn is not a promise, nor a contract for the future. Predictions are fragile. Empirical process control has the potential of antifragility. We embrace complexity.

In Scrum, actually… velocity makes most sense if a measure of a team’s capability to create releasable software.

Read more…


Personal reflections: the world of software development

10 years ago I’ve entered the IT world with the exciting expectations to create truly amazing software. Nowadays, the possibilities are endless, the technology advances fast, there are plenty of opportunities for innovation. It’ an exciting world!

Unfortunately, from time to time, the process to create software (for internal or external use), is clogged down by overly-prescriptive processes, coordination chaos, organizational barriers, technical mediocrity or simply the unwillingness (failure) to understand that software development is a complex adaptive system. In summary, an approach of an old industrial paradigm applied to software creation.

Humans are complex creatures, and as humans we want to create complex products. Unless you’re a solitary developer working end to end alone to create a piece of software – for your own use; you will need to talk (at some point in time) with a colleague developer and / or the user of that software.

Humans like to create complicated things to manage complicated things to end up in a lot of complications. Anyway, the world always will be divided by different streams of thinking; including the software world, moreover as it offers countless possibilities to create solutions.

In today’s fast paced world, software needs to be spot-on, well-engineered, valuable and simply said: great!

A piece of software has its use: it solves a problem, it answers to a need, it offers some entertainment, or it was a learning journey. In the real word (business or non-profit), we need to seize opportunities, respond to challenges, and control risk – and all this in a timely manner. The software developed needs to support this, it offers a solution, and it gives us a competitive advantage. Needless to say, in today’s fast paced world, software needs to be spot-on, well-engineered, valuable and simply said: great!

In the software industry (and nowadays also outside it), there exists a way of thinking and acting that embraces the above; it grass rooted long time ago and has gained adoption as time passes.

To me it makes no sense to act otherwise, to create complex (software) products in different way. One need to realize this way of working is more than a process; it’s more than yet another development framework. It addresses basic principles of values, it embraces humans for their nature; it embraces creativity. I am in no way brain-washed or sponsored (I hope); I do know that other ways of creating complex (software) products has failed too often. I like simplicity, I like productivity. I think there’s a way to have it in the world of software.

Source featured image:

Feature Teams

The Development Team (a.k.a. the team)

By the Scrum guide:

  • Self-organising: the team determines itself how to organise and execute their work
  • Cross-functional: the team possesses all the necessary skills and competences to produce a potentially shippable product increment

Feature team

The term feature team has been coined by Craig Larman and Bas Vodde (2010).


A feature team is a long-lived, cross-functional, cross-component team that completes many end-to-end customer features—one by one

A feature is able to take in a customer feature (requirement) and handle it end-to-end and in this way capable to deliver value iteration by iteration.

Feature teams


Most teams are not feature teams. There’s an attempt to create a cross-functional team, but that team does not possesses the skills necessary to implement a customer-centric feature end-to-end.

Traditional organisations are composed of component teams – a component team specialises in one particular line of work.

A feature team organization exploits speed benefits from specialization, as long as requirements map to the skills of the teams. But when requirements do not map to the skills of the teams, learning is ‘forced,’ breaking the overspecialization constraint.
Feature teams balance specialization and flexibility.

In large traditional structured organisations the number of component teams is huge: a sub team for each and every ‘phase’ of the project or system involved:

  • marketing / business concepts, business analysis, functional analysis, copywriting, visual design, user interaction / user experience design, technical analysis, technical design, front-end development (subteams by technology), back-end development (many subteams for each component or layer), network, server-system infrastructure, mainframe systems, webserver, etc – the list is long.

There’s a terrible overhead and waste in coordination, hand-overs, communication.

Coordination Chaos:

Creating true feature teams is a major and important step in the organisation’s redesign to become agile.

Generalizing specialists

The team itself is cross-functional, this means that the team as a whole requires the skills to implement the entire customer-centric feature end-to-end.

People within the team have multiple specialisation (skills): you need to ask and encourage (incentive) your team members to have secondary, tertiary skills. If the people don’t have those other skills, apply co-learning techniques.

Scott W. Ambler coined the term “generalizing specialists” to define the need for multi-disciplinary team members.

Mind map Large Scale Scrum (LeSS)

Large-Scale Scrum (LeSS)

Large Scale Scrum

Scaling Scrum addresses the questions/challenges which arise when applying Scrum (Agile) in a large context: an organisation or project with multiple teams, possible multiple products. The scale can vary from a few teams to dozens of teams (e.g. a few hundred or even thousands of people). As such a framework for ‘Large scale’ Scrum should be able to scale indefinitely. The challenges/issues involved are: cross-team coordination, organisational design, impediments resolution, backlog refinement and building one integrated product. Simply said, all the challenge you face in 1 team Scrum, but on a (much) large(r) scale.

The first advice given is: do not scale Scrum, do not multi-site! If you can create your software product with 1 team, go ahead and work with 1 team.

Large Scale Scrum (LeSS) can be called a ‘framework’ for scaling Scrum, but rather it defines a set of additional rules and guidelines. These rules are very much aligned with Scrum, and feel very natural. LeSS does not introduce an additional detailed process layer on top of Scrum. In that perspective, LeSS is very straightforward and lightweight.

Large Scale Scrum = Scrum. This is rational and very recognizable, but obviously does not take away the challenges. This is aligned with the vision of scaling Scrum by the official Scrum institutions: get basic Scrum right for your teams, scale only if necessary. Scale professional Scrum. Transparency is the key element to succeed. Unfortunately most (large) organisations are very un-transparent in most of all the things they do. As with Scrum, a scaling Scrum framework remains a framework (not a one-size-fits-all solution) for complex product development, in which teams will need to apply practices and methods and measure work in an empirical way.

LeSS and LeSS Huge

  • LeSS: Up to eight teams
  • LeSS Huge: Up to a few thousand people on one product

LeSS clearly defines to build 1 integrated product, with 1 product backlog. Sprint planning part 1 happens with all teams (or with team representatives). The Sprint Review is for all of the teams to review the one potentially shippable Product Increment together. The focus is on the whole product. An Overall Retrospective does not exist in standard Scrum. Its purpose is to retrospect on the previous Sprint(s) from a product perspective cross-team.

LeSS Huge provides a set of rules for a setup with a lot of teams – the ‘tipping point’ is ~ 8 teams, but it rather depends on the feeling and workload of the product owner. If the product owner cannot handle anymore the workload to own his backlog, LeSS Huge provides an answer by introducing ‘requirements areas’ (a set of customer-centric feature areas) with an additional responsible product owner per requirement area.

Flip the system

A key take-away is the fact that support of top-level management is absolute required to be able to transform an organisation to become effective in agile product/software development. As such, this is not new, but essentially – in the context of Large Scale Scrum – this implies the ‘go’ or ‘not-go’ decision.

A LeSS consultant goes in and talks to the management to discuss the required changes in organisational design and the need for good engineering practices. If the management is not convinced or does not acknowledge the need for such changes – basically the LeSS adoption would be a ‘no-go’.

An adoption flips the organisational system for 1 particular product (or product group), not for the whole organization. When the adoption for this 1 product is successful, you continue to spread to adopt the way of working to other products of the organization.


A part of the course addresses the adoption and the preparation involved to adopt LeSS. There is no perfect time to start agility; rather ‘initiation’ of the transformation to agility can start at any time and the path to agility is a path of continuous improvement.

There are different views on when to start the first sprint: you can start right away (knowing you will not be able to produce a potentially shippable product increment at the end of the first sprint), but you deal with it in an empirical and transparent way during your sprints.

On the other hand, you foresee a preparation period which involves activities to get started:

  1. Educate everyone (including management)
  2. Design cross-functional (feature) teams and create feature team adoption maps
  3. Define the 1 definition of done
  4. Make the product owner, an actual product owner
  5. Keep project managers away from the teams

The preparation includes as well the setup of any facilities, systems, etc. With a good preparation, you have a solid basis to produce working software (according to the definition of done) at the end of your 1st sprint.

The course

The Certified LeSS practitioner is a 3 day course, quite interactive. Craig organizes his course by explaining some content, immediately follow by an individual, team exercise or in-class example. We’ve exercised lots of mind mapping to recapitulate what we’ve just learned and an exercise on causal-loop modelling. After the course, I’ve created my own overall mindmap of the course contents, which I’ll use as link to explore further topics. Both Ari Tikka and Ahmad Fahmy were present during the course. They have both experience with adopting LeSS (Ari in Nokia Networks, and Ahmad in Bank of America Merill Lynch).

Craig takes time to address almost each question or concern raised, or parks it with consideration. He emphasizes very much (as he should) on core Scrum and empirical process control.

Craig breaks the course in unequally time-boxed pauses, and spices it up with miscellaneous useful and useless stuff and quite a few bad Canadian jokes (no further spoilers mentioned here) J

Each participant received a copy of the scaling books + print-out of the slides (the slide deck is about 300 slides). Any particular issues regarding multi-site or offshore agile development are part of the resources, but not addressed in the course. Most large organisations have some kind of offshore/nearshore development on-going (or past this, after lots of misery) – it would have been very interesting to get some more explanation or guidelines on this topic.


After completion of the course, you are a Certified LeSS Practioner. The course is as well accredited by the Scrum Alliance, as an added qualification on the topic of Scaling Scrum Fundamentals.


The site provides a lot of info on the framework. It’s much recommended to read the material on the site (it contains a lot): minimum minimorum the LeSS rules, but mostly read as well the LeSS framework, principles, and structure.

Craig Larman and Bas Vodde are agilists with lots of experience in Scrum and scaling Scrum/Agile. Craig has a focus on organisational re-design and systems thinking and he servers as consultant for large-scale Scrum and enterprise agile adoption.

Craig and Bas have authored 2 main books on Scaling Lean and Agile development:

2010 – Practices for Scaling Lean and Agile Development – Craig Larman, Bas Vodde

2009 – Scaling Lean and Agile Development – Craig Larman, Bas Vodde

There’s an upcoming book 2015 – Large-Scale Scrum: More with LeSS, Craig Larman, Bas Vodde, which will contain a structured explanation on LeSS as a framework for Large Scale Scrum. I expect this book to be much aligned with the content of the website and the content of the course, presumably filled with examples and extra guidelines.

This article expresses my personal view regarding the Large Scale Scrum (LeSS) Practitioner course, given by Craig Larman – March 2015, Brussels. In case of any remarks or questions, don’t hesitate to reply.

My LeSS mindmap

(click for full-sized image)

Mind map Large Scale Scrum (LeSS)

Mind map Large Scale Scrum (LeSS)


Agile / Scrum / Lean / Kanban videos (to learn or to improve your knowledge)

There are some videos available giving insights into agile and agile frameworks, see below a collection – if you have any suggestions for other, please leave a comment! (some of these videos are by commercial vendors, but I only include these if indeed the video is instructive)

(list of 2015)


The Agile Manifesto – 4 Agile Values Explained


Scrum by the book (by Per Beining)

OpenView: Scrum & Agile development (Playlist: Jeff Sutherland and others)

The art of doing twice as much in half the time (Jeff Sutherland)

Agile programming — for your family (Bruce Feiler)

Ken Schwaber – The State of Agile – 2014 The Path to Agility Conference

Scaled Agile Framework (SAFe)

Introduction to the 3.0 version of SAFe

Dean Leffingwell Talks About SAFe 3.0 at Agile 2014

SAFe Foundations 3.0 with Dean Leffingwell and Jennifer Fawcett


Four Principles Lean Management – Get Lean in 90 Seconds

Toyota Production System – 5S Just, Just in Time, Kaisen

The 7 Types of Waste


Intro to Kanban in Under 5 Minutes (What is Kanban, Learn Kanban)

Tools: Jira

Introduction to JIRA & Agile Project Management

Scrum Scaled for Large Projects and Organizational Initiatives

Ken Schwaber’s point of view on scaling Scrum. With a smile I’ve read Ken’s comment: “Lately, we have watched with amusement and then growing concern as the methodologists have rolled megaprocesses they assert are the silver-bullets to scaling.”

Growing concern, I must concur. As well, I experience how organisations are struggling and seeking how to scale scrum. Recently, Gunther presented the issue at #atbru (Agile tour Brussels) in his talk “Empirical management explored”.

My observations:
* Organisations not yet able to decently organize Scrum at team level, should not embark on a journey to scale Scrum beyond that team level.
* If such organisations do attempt to scale Scrum, they will scale dysfunctions.
* Organisations still stuck in the classic management paradigm are steer-less seeking to get product creation organised in an incremental and iterative way, still mixing it with many waterfall practices (predictive long-term project planning, absurd guesstimates, lack of transparency, …). On the way, they end up with a self-defined framework; mixing it all up.

The bottom line is:
* Invest wisely to get organized to transform your teams to Scrum
* Invest wisely to maximize Scrum at team level, and next with multiple teams, and next with multiple products > this subsequent growing approach is the sound approach to scale
* Live and breathe the Scrum Stance and agile values
> Invest in people and teams
> Manage and plan based upon real metrics and evidence
> Focus on business value

Scrum Scaled for Large Projects and Organizational Initiatives

In Scrum zijn er geen business analisten!

In Scrum zijn er geen business analisten!

Hmm. Toch wel.

In Scrum bestaat de “rol” business analist niet, en  ook geen andere typische IT project rollen zoals functioneel analist, technisch analist, architect, systeembeheerder, project manager, …

Het Scrum framework definieert 3 rollen:

  • Product eigenaar
  • Ontwikkelaars (het team)
  • Scrum master

Het “ontwikkel” team omvat alle individuen met alle vaardigheden en expertises om het product te “ontwikkelen”. In feite kunnen we dit ook het “product” team heten, de term “ontwikkelaar” neigt teveel om enkel (software) ontwikkelaars aan te spreken.

Het team oefent dus alle vaardigheden en expertises uit om tot een succesvolle ontwikkeling van het product te komen. Het team is in principe cross-functioneel en een teamlid hoeft zich niet te beperken tot een bepaalde rol of activiteit. Volgens de nood en planning kan elk teamlid een bepaalde activiteit uitoefenen… analyse, design, ontwikkeling, testing, planning, project administratie, … . We moedigen dit aan in een cross-functioneel team zodat teamleden van elkaar kunnen leren en kennis gedeeld / verrijkt wordt.

“Business analyse” omvat uiteraard meerdere vaardigheden en een analist is actief op vele terreinen: marketing & communicatie, business, functioneel, technisch, … . De business analist heeft typisch vaardigheden om de vertaalslag te maken tussen marketing en technische mensen.

Agile en analyse?

Als “business analist” vervullen we de facto meerdere taken. Een agile analist zou men kunnen omschrijven als:

Een agile analist combineert business, functionele, techische analyse en acceptatie testen. De agile analist streeft naar transparantie in communicatie en het gehele project, werkt in korte iteraties en is continue op zoek naar feedback. De agile analist creëert samen met de product eigenaar en de andere teamleden een visie en bouwt mee aan het product, iteratie na iteratie.

Bron: volledig artikel (

10 redenen waarom een organisatie niet succesvol is in het toepassen van Agile / Scrum

De adoptie van agile principes en een framework (zoals Scrum) in een organisatie is een hele uitdaging.

10 mogelijke redenen waarom een organisatie niet succesvol is in het toepassen van Agile / Scrum:

1. De organisatie begrijpt het probleem niet ten gronde dat men wenst op te lossen met de introductie van Scrum

2. De organisatie heeft onrealistische verwachtingen

3. De organisatie heeft geen strategie of visie

4. Er is geen management ondersteuning

5. De organisatie is niet bereid om effectief te veranderen (cultuur, processen)

6. De teams in de organisatie hebben geen intentie om cross functioneel te werken

7. Er is geen product ownership

8. De organisatie heeft niet voldoende geduld

9. De organisatie is niet bereid om te investeren in training

10. De organisatie denkt dat alle veranderingen door 1 persoon georchestreerd kunnen worden

Thanks to @tirrellpayton