Meta

Category / scrum

I’ve stumble upon this list, and I like it – as it clarifies again a bit the role of the Scrum Master.

Source: https://age-of-product.com/70-scrum-master-theses/

Scrum is not a methodology, but a framework. There are no rules that apply to each and every scenario — just practices that have worked before in other organizations.

Successful practices of other organizations cannot simply be copied to your own. Every practice requires a particular context to work.

You need to determine for yourself what works for your organization — which is a process, not a destination.

The role of a scrum master is primarily one of leadership and coaching. It is not a management role.

A scrum master should recognize that different stages of a scrum team’s development require different approaches: some, teaching; some, coaching; and some, mentoring.

A scrum master should be familiar with the Shu-Ha-Ri concept of learning new techniques.

A scrum master’s principal objective should be to remove themselves from daily operations by enabling the scrum team to be self-organizing and self-managing.

Being a scrum master does not entail, and should never entail, enforcing processes.

Scrum is not designed for bean counters, although some metrics are helpful in understanding the health of a scrum team. Generally, insisting that the team achieve specific KPI (for example, commitments vs. velocity) does not help.

Scrum doesn’t elaborate on the process that enables a product owner to add valuable, usable, and feasible user stories to the product backlog. Product discovery using the Design Thinking, Lean Startup, or Lean UX methodologies may help, but in any case, a good scrum master will want the scrum team to be a part of this process (whether participating in user interviews or running experiments).

A scrum team’s communication with stakeholders should not be run through a gatekeeper (e.g., solely through the product owner) because this hurts transparency and negatively affects the team’s performance. Sprint reviews, conversely, are a good way to stay in close contact with stakeholders and to present the value delivered by the team during each previous sprint.

The most important objective of a sprint in Scrum is to deliver a DONE product increment – a piece of working software delivering value for the end-user. That is the goal today, and always has been the goal.

In a context, in which multiple Scrum teams work on the same product, it’s the goal – and only goal – to deliver each (and every) sprint an integrated product increment – so no UNDONE work left at the end of the sprint.

How do you define DONE?

Scrum does not define what “done” means for a product – that’s to be defined by the development team.

Yet the goal is to get better and raise the bar, in order to be able to deliver a piece of valuable working software at the end of each sprint.

With support of the Scrum Master, the development team improves their practices at a steady pace to be able to reach that goal.

“As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality. Any one product or system should have a definition of “Done” that is a standard for any work done on it.”

Unfortunately, we observe that many Scrum teams (or teams saying to practice Scrum) are not able to deliver a done product increment at the end of each sprint. In the world of software development, this means a piece of working software (end to end) ready to be used by a customer (end-user). Some teams simply do not care and finish the work till done at a next sprint.

The output at the of the sprint has been called a potentially shippable product increment. Some teams interpreted this as “the product increment is ready to be shipped, but actually there’s still some work to do to actually release it to the customer“. That’s obviously not the point.

That’s why the Scrum Guide says:

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

A lesson from Scrum history

Jeff Sutherland and Ken Schwaber, – the creators of Scrum have been updated the Scrum guide over time. It’s interesting to read how in previous versions of the Scrum guide there was more detail about what done actually means, and what to do with “undone” work. The reason in general that some artefact and details have been left out, is to make the description of Scrum as a framework more simple, clear to understand and lightweight.

A completely “done” increment includes all of the analysis, design, refactoring, programming, documentation and testing for the increment and all Product Backlog items in the increment. Testing includes unit, system, user, and regression testing, as well as non-functional tests such as performance, stability, security, and integration. Done includes any internationalization.

You clearly get the picture, that “done” includes all the work necessary to be able to have a piece of releasable, valuable software at the end of the sprint.

It continues:

“Undone” work is often accumulated in a Product Backlog item called “Undone Work” or “Implementation Work.”

Sprint by Sprint, the “undone” work of each increment is accumulated and must be addressed prior to releasing the product. This work is accumulated linearly although it actually has some sort of exponential accumulation that is dependent on each organization’s characteristics. Release Sprints are added to the end of any release to complete this “undone” work. The number of Sprints is unpredictable to the degree that the accumulation of “undone” work is not linear.

Take care, the current Scrum Guide does not specify a “release sprint” as a practice. This is similar to the “hardening” sprint defined in – for example – the Scaled Agile Framework. In Scrum, this is considered a bad practice. As stated the goal – and only goal is to create a done product increment at the end of each sprint. “Undone” work piles up and increases risks and delays.

The word “undone” is not mentioned anymore in the current version of the Scrum Guide.

A perfect definition of done

Large-Scale Scrum (LeSS) (by Craig Larman and Bas Vodde) do explicitly mention “undone” work – in larger organisations there are often whole teams (e.g. an “operations” team, a “services” team) or whole departments (“operations” departement) or people (“release manager”) existing which are to be considered part of “undone” work if this cannot be done as part of the sprint (and it often cannot be done within a sprint).

A perfect definition of “done” implies that each product increment is

valuable

immediately releasable to the end-user

And that should be the goal of perfection.

To be able to achieve this as a team, effort is necessary to invest in:

software craftsmanship

automated testing

continuous integration

deployment automation

without sound technical practices it’s fairly impossible to achieve this on any scale (small or large).

Do not make a mistake, this is quite a challenge for many teams who (try to) practice Scrum.

All variants on Scrum who do not achieve the actual state of “done” product increments, according to the rules stipulated in the Scrum guide, are not to be considered Scrum teams.

What does done means in software development?

I quote this from – Ken Schwaber – and any software development team should adhere to these (working in Scrum or not)

The end result should include software that has:

Presence of valuable functionality for customers to use;

Absence of low value functionality that must be maintained and sustained regardless;

Quality code base to predictably maintain and sustain;

Quality code base to enhance without undue effort or risk;

Ability to catch defects early and no later than at release;

Predictability of schedules; and,

A Lack of surprises.

Which raises the question, what is quality software?

It has these characteristics:

I can readily understand the software and where & how things happen;

When I change or add to part of the software, there are no unintended or poorly designed dependencies;

I can read the code without looking for tricks or poorly defined and labeled variables or data;

I don’t need the person(s) that wrote the code to explain it to me;

There are a full set of (automated) tests to check that the function works as expected;

When I change something and add to the tests, I can check that the entire change and product continues to work;

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

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

You can find online all kinds and sorts of formats (games) for retrospectives; I’ve found back a description of a ‘base’ agile retrospective, and I’d like to recommend this to anyone. It focuses on what went well, what could better, and next on identifying and committing to action points for improvement.

ABSTRACT. The stated, accepted philosophy for systems development is that the development process is a well understood approach that can be planned, estimated, and successfully completed. This has proven incorrect in practice. SCRUM assumes that the systems development process is an unpredictable, complicated process that can only be roughly described as an overall progression. SCRUM defines the systems development process as a loose set of activities that combines known, workable tools and techniques with the best that a development team can devise to build systems. Since these activities are loose, controls to manage the process and inherent risk are used. SCRUM is an enhancement of the commonly used iterative/incremental object-oriented development cycle.

The good questions are:
1. What have you done yesterday that contributes to reach the sprint goal?
2. What will you do today that contributes to reach the sprint goal?
3. Do you encounter any impediments/issues/problems that prevent you from reaching the sprint goal?

The habit of each person listing all the things he has done yesterday, and what he will do today is quite besides the point. The daily scrum is not a status meeting, it’s not a reporting meeting. In essence people should say what and how they’re progressing towards the sprint goal, and think and act as team how to plan their work together… for the next 24 hours. So yes, it’s a planning meeting, for the shortest iteration: the next 24 hours.

There are many “anti-patterns” regarding the daily scrum:
– Talking to the board, and not to the people
– No board at all
– Talking only to the scrum master
– Not expressing the progress of what your working on
– Having no sprint goals (so nothing to measure against)
– Talking too much, speaking about sprint goal – irrelevant stuff (for example discussing tasks in detail)
– Discussing problems and solutions in great detail > these should be taken offline, by preference the discussion continues in subgroups (with the relevant people), directly after the daily scrum (when the topic is still hot).

“Cross-functional” collaboration in (agile) product development means that the whole (complete) product “development” team is participating. Scrum talks about a “development” team, without distinction of role. As such, “developer” means any competence or skill required to create the product or service, not limited to “programming” (writing code).

Lean UX heavily promotes the whole product development team participating during the complete product development cycle, from the very beginning. The whole team approach aims to create a shared understanding with everyone (all team roles) from the beginning and to minimize any waste originating from working in sub-teams or silos (hand-overs, intermediate deliverables, re-discussing the same topic with people who didn’t participate, etc).

Shared understanding

True agile teams (feature teams) are product-oriented and are able to implement product features end to end, creating pieces of value with every item done. Collaboration with all team members is a great source of creativity, new ideas and innovation. This kind of cross-functional collaboration is demanding: people are expected to think outside their box, to participate in work outside their main domain, and to help to create that necessary shared understanding to be able to deliver value within an iteration.

Teams working in a phased approach (the so-called staggered sprints) face a number of worries – this should not be accepted as common, and such teams should strive for a better way of working. A phased approach is basically some work done in a sprint before the “development” sprint (or even worse, acceptance or testing after the”development” sprint).

Improved time to deliver (precondition is to deliver chunks of value you are able to implement within a sprint)

Less re-work, less waste

Improved definition of done

Sense of ownership amongst all team members

And so, we urge you to re-consider any large upfront work (before “construction”), and try to create shared understandings with the whole team. That shared understanding will lead to willingness to truly collaborate together within the same sprint. In the Lean UX approach you foresee a regular cadence of user tests. The aim is to create a “test everything” culture: we test what’s available and given the users’ feedback, we improve (we iterate).

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

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

As you explain, the framework is simple. Likewise Scrum, it’s painfully simple.

As Ken Schwaber once said (I believe):

“Scrum is like your mother-in-law, it points out all your faults.”

Each organisation has an enormous untapped potential to deliver more value, more rapidly, more frequently. But reality is different, small and large organizations have and maintain (anxiously) the traditional organizational model.

How difficult is it to transform to a networked organization, stimulating self-organisation and a learning culture? From a scale from 1 to 10, I’d say 10. This kind of organisation design only works if management supports it, management understands and shows the example and the executive support is long lasting.

Unfortunately (again) for large organisation (I’ve been working in bank); I’m rather pessimistic: it will takes years, may be decades before this kind of organisational design & culture change happens. So, the essence of a “large product” development is its simplicity.

Are other organisations fooling themselves? Those which are adopting “large scale” organizational frameworks? Will they reach the benefits? They will get some benefits yes, but then again: it’s not difficult to gain some improvements in an organisation working for years according to “a previous-century industrial paradigm” (as in manufacturing). But I guess they’ll never reach true “business agility”.

I wish the market conditions would be much tougher: those not adapting are extinguished: the sooner the better.

Large Scale Scrum (LeSS) is for me an honest framework which embraces Scrum (for 1 team). LeSS does not introduce any additional layers of governance, it does not compromise to fit with existing traditional organization structures, it does not compromise on the delivery of value.

Indeed, LeSS is much more about organisational (re)design than about introducing Scrum. Before “scaling up” to multiple teams, an organization must be able to adopt Scrum on the team level, and proof for themselves they can organise performing teams. LeSS embraces the principles of agile and lean thinking as these are meant to be.