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 crucial sprint objective 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 determined by the development team.
Yet the goal is to get better and raise the bar to deliver a piece of valuable working software at the end of each sprint.
With the 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) cannot deliver a done product increment at the end of each sprint. Some teams do not care and finish the work till done at the next 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).
The output at 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 release it to the customer”. That’s 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 there was more detail about what done means and what to do with “undone” work in previous versions of the Scrum guide. In general, some artefacts and pieces have been left out 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 get the picture that “done” includes all the work necessary 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. The goal – and only goal is to create a done product increment at the end of each sprint. In Scrum, this is considered a bad practice. “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” department) 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, the effort is necessary to invest in:
software craftsmanship
automated testing
continuous integration
deployment automation
without sound technical practices, it’s pretty impossible to accomplish 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.
According to the rules stipulated in the Scrum guide, all variants on Scrum who do not achieve the actual state of “done” product increments 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 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;
How things work and hang together is transparent;
Standard, well-known design principles have been adhered to.
“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 entire team approach aims to create a shared understanding with everyone (all team roles) from the start 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 can implement product features end to end, creating value pieces with every item done. Collaboration with all team members is an excellent source of creativity, new ideas and innovation. This kind of cross-functional collaboration is demanding: people are expected to think outside their box, participate in work outside their main domain, and help create that necessary shared understanding to deliver value within an iteration.
Teams working in a phased approach (the so-called staggered sprints) face several worries – this should not be accepted as standard, and such teams should strive for a better working method. A phased approach is some work done in a sprint before the “development” sprint (or even worse, acceptance or testing after the” development” sprint).
The (single) (proper) Scrum team approach has numerous benefits:
Understanding of concepts and users’ needs amongst all team members
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 extensive upfront work (before “construction”) and try to create shared understandings with the whole team. That shared understanding will lead to a willingness to collaborate within the same sprint truly. You foresee a regular cadence of user tests in the Lean UX approach. The aim is to create a “test everything” culture: we test what’s available, and given the users’ feedback, we improve (we iterate).
There’s no need to re-describe Scrum. If you’re on a journey to discover Scrum, I welcome you. I advise you to learn more than Scrum and discover agile & lean.
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 encourage you to read these articles and recommend that little book. It’s written honestly and offers transparent descriptions.
With this are 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.
Scaling Scrum addresses the questions/challenges that arise when applying Scrum (Agile) in a significant context: an organisation or project with multiple teams and 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 scale indefinitely. The challenges/issues involved are cross-team coordination, organisational design, impediments resolution, backlog refinement and building one integrated product. Said, all the challenges 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 one team, go ahead and work with one 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 extra detailed process layer on top of Scrum. In that perspective, LeSS is very straightforward and lightweight.
Large Scale Scrum = Scrum. This is rational and recognisable but 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 success. Unfortunately, most (large) organisations are very un-transparent in most things. A scaling Scrum framework remains a framework (not a one-size-fits-all solution) for complex product development. Teams will need to apply practices and methods and measure work empirically.
LeSS and LeSS Huge
LeSS: Up to eight teams
LeSS Huge: Up to a few thousand people on one product
LeSS clearly defines building one integrated product with 1 product backlog. Sprint planning part 1 happens with all teams (or with team representatives). The Sprint Review is for all teams to review the 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 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. Suppose the product owner cannot handle the workload anymore to own his backlog. In that case, LeSS Huge provides an answer by introducing ‘requirements areas’ (a set of customer-centric feature areas) with an additionally responsible product owner per requirement area.
Flip the system
A key takeaway is that top-level management support is required to transform an organisation to become influential 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 talks to the management to discuss the required changes in organisational design and good engineering practices. If the management is not convinced or does not acknowledge the need for such changes, the LeSS adoption would be a ‘no-go’.
An adoption flips the organisational system for one particular product (or product group), not for the whole organisation. When the adoption of this 1 product is successful, you continue to spread to adopt the way of working to other organisation products.
Adoption
A part of the course addresses the adoption and the preparation involved to adopt LeSS. The path to agility is a path of continuous improvement. There is no perfect time to start agility; rather, ‘initiation’ of the transformation to agility can begin at any time.
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 empirically and transparently during your sprints.
On the other hand, you foresee a preparation period that involves activities to get started:
Educate everyone (including management)
Design cross-functional (feature) teams and create feature team adoption maps
Define the 1 definition of done
Make the product owner, an actual product owner
Keep project managers away from the teams
The preparation includes the setup of any facilities, systems, etc. With good practice, 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 three-day course, quite interactive. Craig organises his course by explaining some content, immediately followed 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 activity on causal-loop modelling. After the course, I’ve created my overall mindmap of the course contents, which I’ll use as a link to explore other topics. Both Ari Tikka and Ahmad Fahmy were present during the course. They have both experiences adopting LeSS (Ari in Nokia Networks and Ahmad in Bank of America Merill Lynch).
Craig takes time to address almost every question, or concern raised or parks it with consideration. He emphasises core Scrum and empirical process control very much (as he should).
Craig breaks the course in unequally time-boxed pauses and spices it up with miscellaneous valuable 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 multi-site or offshore agile development issues are part of the resources but not addressed in the course. Most large organisations have some offshore/nearshore development ongoing (or past this, after lots of misery) – it would have been exciting to get some more explanation or guidelines on this topic.
Certification
After completion of the course, you are a Certified LeSS Practioner. The Scrum Alliance also accredits the course as an added qualification on the topic of Scaling Scrum Fundamentals.
Resources
The site http://less.works 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 of the LeSS rules, but mostly read the LeSS framework, principles, and structure.
Craig Larman and Bas Vodde are agilists with lots of experience in Scrum and scaling Scrum/Agile. Craig focuses on organisational redesign and systems thinking and serves as a consultant for large-scale Scrum and enterprise agile adoption.
Craig and Bas have authored the following main books on Scaling Lean and Agile development:
This article expresses my 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.
Een dagelijkse status meeting maakt inherent deel uit van het Scrum framework. Ook zonder toepassing van Scrum, is een dagelijkse status meeting heel nuttig. Andere benamingen voor de status meeting zijn: “huddle meeting”, of kortweg: “daily”, of “stand-up”. In het Scrum framework is de officiële benaming: “Daily Scrum”
De objectieven van een dergelijke dagelijkse meeting zijn het bespreken van:
De stand van zaken van het werk
Verbetering van het team
Communicatie in het team bevorderen
Kenmerken van een dergelijke meeting:
Frequentie: dagelijks (dat is de gewoonte)
Tijdstip: wat past voor iedereen in het team (op zich in het tijdstip niet zo belangrijk, dit kan elk moment van de dag – zolang iedereen aanwezig kan zijn)
Duur: maximum 15 minuten is een goede duur tijd. Het is belangrijk dat de deelnemers niet afdwalen naar het vertellen van een verhaal, of het bespreken van oplossingen. Te lange conversaties of het langdradig vertellen, moet men op een vriendelijke manier een halt toe roepen. Het verduidelijken van een vraag of onderwerp kan natuurlijk wel. Het feit dat mensen blijven rechtstaan, zorgt er voor dat er blijvende aandacht is en de voorziene tijd beter respecteert. Een facilitator kan in het oog houden dat de meeting telkens tijdig start en eindigt.
Locatie: zo dicht mogelijk bij de locatie van het team (indien er mensen op afstand participeren – kies een vergader locatie met de noodzakelijke communicatie middelen: tele-conferencing, video conferencing)
Wie neemt er deel? Iedereen van het team. Iedereen is verondersteld spreken. Een facilitator kan in het oog houden dat iedereen aanwezig is in de meeting. Een facilitator kan aanduiden wie er spreekt, of we passen een sequentiële spreekvolgorde toe, of een random spreekvolgorde (vb. door een balletje rond te gooien). Een random spreekvolgorde verhoogt de aandacht van de aanwezigen 🙂 en maakt het leuker.
Er zijn vele interessante technieken – tips & tricks om een dagelijkse status meeting levendig te houden; een interessant artikel hierover is dit: “It’s not just standing up”
Een volgend acroniem is leuk om de essentie van een dagelijkse status meeting te vertellen:
G I F T S
Good start
De meeting is een goed begin voor het team – een goed begin van de dag – uiteraard als de meeting ’s morgens plaatsvindt :-). De meeting mag geen dagelijkse sleur worden of het aframmelen van de status. De meeting dient energie te geven! Een boost om de dag te beginnen en nieuw inzichten in te behandelen problemen of taken.
Improvement
De doelstelling is verbetering. Verbetering van het werk dat het team levert, verbetering van het functioneren van het team zelf. Het zeggen van problemen, zonder effectief naar oplossingen te zoeken heeft weinig meerwaarde.
Focus
Focus op het werk, niet zozeer de mensen. De doelstelling is om de status van het werk te (gedane werk / werk nog te doen) bespreken, niet te focussen op de activiteiten van elk individu.
Team
De status meeting is een meeting voor het team om zichzelf te informeren en beter te organiseren, het is absoluut geen rapporteringsmeeting! Vermijd dat een manager de meeting als een rapporteringstool gebruikt.
Status
We bespreken de status van het werk en eventuele problemen of belangrijke zaken. Dit wordt typisch gedaan door het beantwoorden van 3 vragen per individu:
Wat heb ik gisteren gedaan?
Wat wil ik vandaag doen?
Wat zijn de problemen die ik heb die me belemmeren om mijn werk te doen / taken af te handelen?
Een suggestie is om team members eerst de 3e vraag i.v.m. problemen te laten beantwoorden – zodanig dat hier voldoende aandacht aan gegeven wordt.
Visueel board
Een aanrader (must-have) is een board om zaken visueel bij te houden. In zijn eenvoudigste vorm maken we een “improvement board”, die de besproken problemen lijst. Vervolgens dient het board om bij elke status meeting de problemen te herhalen en te zien of er voortgang is voor een oplossing.
Een andere vorm is een planning / taken board. In dit geval zal het board alle taken weergeven met hun huidige status en eventuele problemen.
“Lately, we have watched with amusement and then growing concerned as the methodologists have rolled mega processes they assert are the silver-bullets to scaling.”
Ken Schwaber
A growing concern, I must concur. I also 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 organise Scrum at the team level should not embark on a journey to scale Scrum beyond that team level. * If such organisations attempt to scale Scrum, they will scale dysfunctions. * Organisations still stuck in the classic management paradigm are steer-less to get product creation organised incrementally and iteratively. These organisations mix Scrum with many waterfall practices (predictive long-term project planning, wild 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 organised to transform your teams to Scrum * Invest wisely to maximise Scrum at a team level, following with multiple teams and following 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
The House of Scrum