In the TGV, 3 hours ahead of me with the air conditioning, I stick Roxy & Elsewhere by Frank Zappa in my ears and I launch into a reading of the new Scrum Guide (the one that just came out in July 2013).

Before starting, it seems clear to me that while Ken Schwaber & Jeff Sutherland are the creators of Scrum, they no longer really control the creature. The name belongs to them, as does the consolidation of the “toolkit” under this name, but the concepts and ideas behind it have been freed beyond their expectations and out of their real grip.

I haven’t read this guide in 4 years, I’m not looking for the “differences” between versions but rather the variations with my approach.

Scrum Pillars

Very quickly upon reading the booklet, we observe that Scrum remains a foundation, a framework, a toolset, and not a mindset, a culture, etc. We will observe that this desire to make things very operational is present everywhere, from the description of Scrum’s pillars, its values so to speak, transparency, inspection, adaptation: the Transparency “for those responsible for outcomes” (to those responsible). Schwaber & Sutherland thus decide to limit it to these people. It’s probably a desire to make the tool very sharp, perhaps wrongly, perhaps not. We could not limit transparency… Inspection: of scrum elements and the sprint goal. Same thing, they voluntarily decide to target. Finally, Adaptation, an inspector observes (an inspector determines…). Another precision -not necessarily useful-, couldn’t all of us think about continuous improvement? I understand that Schwaber & Sutherland want a very defined tool, a proven toolbox. Very useful especially for getting started (yes transparency is essentially for stakeholder commitment, hence the precision in the guide). But this targeting may quickly reveal itself as a limitation as soon as agile culture spreads. So a double-edged sword. In short, precisions yes, restrictions no.

Roles

I like the definition of the Product Owner and the team, even if the word “development” is very associated with code, which is not at all necessarily the case. But if people make this connection, it’s not the case with the Scrum guide.

I would have added: the Product Owner must be proud, the team happy, and the scrummaster absolutely neutral. I would have appreciated, as they did with the Product Owner (sole accountable), certain precisions about the scrummaster (too many deviations observed): no production, no estimation, neutrality required, for example. My experience leads me to think that it’s generally better not to have a Scrummaster than to have one who produces and who estimates.

Scrum Team Size

This is a point on which I don’t agree with Schwaber & Sutherland. They propose development teams with a minimum of 3 and maximum of 9 to which they add the Product Owner and the Scrummaster. In my experience I observe a sort of deliquescence as soon as the team size plus the Product Owner and the Scrummaster exceeds 7 (5+PO+SM). So I’m far from the 11 (7+PO+SM) mentioned by the authors. My field observation actually aligns with other observers who believe that 7 is a very good number for a team (see this information on the pleasure of belonging to a group, which doesn’t officially equate to performance, but in my pantheon pleasure is often associated with performance).

My practice is 3 to 5 team members + PO + SM. The PO and SM can share their time on 2 projects in parallel. Starting from 3 we really begin to degrade their performance (the PO’s and SM’s), but if the induced value is greater than this degradation why not. I also suggest to the Product Owner to reserve half of the time they allocate to the project/product for advance phase work (grooming the backlog, synchronization with stakeholders and other POs, etc.) and the other half to the current iteration (team support).

Sprint

Wow, they continue to propose 1 month in duration (max). 1 month is enormous. 2 weeks has become a standard for 1 or 2 years. I’m generally never convinced by explanations that tell me it takes 1 month (instead of 3 weeks for example) because it takes time to accomplish certain things. My answer is that quite often it’s simply enough to commit to less. But that’s only possible if we use brain juice to break down our elements. That requires effort. That’s what some refuse.

Well, we keep the word “sprint”, we don’t push for the use of “iteration”.

My common practice: 2 weeks. 1 or 3 weeks exceptionally depending on contexts.

Sprint planning

Schwaber & Sutherland regularly mention a sprint goal, a sort of vision for the sprint like the product or project vision. For example, the online payment sprint for Peetic. Well I’ve never truly succeeded: prioritizing the backlog is already complex enough (value, team production capacity, optimization of team productivity, etc.). Adding on top of that a desire to have a coherent set of elements that tend toward a coherent objective (at the sprint level!) and finished isn’t constant, not necessarily very easy, so I don’t require it.

Well, we no longer speak of commitment, just elements selected for the sprint… I like the notion of commitment because it induces accountability. And accountability in my eyes is a way to nourish the team’s motivation. I don’t like commitment if it becomes a coercive element against the team. Any commitment can be questioned for good reasons.

my practice: 2h to 2h30 sprint planning 1st part, 1h30 sprint planning second part. The second part the team is often left to itself (self-organized as always).

Daily Scrum

As I told you, the sprint goal is a notion I rarely use. The sprint objective in my eyes is to produce the maximum value for the project or product we’re working on. Schwaber & Sutherland promote again a very operational approach by changing the daily scrum questions a bit: they add “What did you do yesterday…” + “…regarding the iteration’s progress”. Ok same, a) this seems obvious to me, is it necessary to add it? (all these precisions are a bit infantilizing) b) who knows, maybe the value will come from something completely external to the sprint and to the team, why deprive oneself?

Moreover, the daily scrum seems to me less a measurement moment as they imply (inspect…progress toward… completing sprint), than a moment of sharing culture and project/product knowledge. Otherwise my practice is the same.

[Roxy & elsewhere is coming to an end, I switch to a live Grateful Dead]

Sprint review

The description is ok except that… in my practice I limit the sprint review to 30min… (2h to 4h proposed by Schwaber & Sutherland). Why?

The sprint review is the moment of opening transparency towards stakeholders, and the place for feedback. I often say like in a marriage, “speak now or forever hold your peace”. Generally it’s difficult but essential to bring the right true stakeholders. Yet asking them to participate in 2 hours of meetings every 2 weeks, or 4 hours every month… is illusory, and not necessarily useful. On the other hand it’s essential that they be present at reviews.

These key people can’t simultaneously say that the project is important and that in parallel they don’t have 30min every two weeks to devote to it (if they do anyway, question them gently about this contradiction). If the project isn’t important (= no presence at reviews), in that case suggest they stop it, we only do things with value in the agile world. 30min every two weeks is an interesting value: 4-5 business days per year you follow the entirety of a project or product over a year (interesting for teams that revolve around it). Because I haven’t yet mentioned the case of departments or products and multi-team projects: imagine a company with say 10-15 teams in parallel, two hours every two weeks, fifteen hours per week??? Stakeholders are often quite few, it becomes impossible for them. On the other hand 30min*8/week = 4hours becomes playable again, and still, they’ll have to choose but it becomes conceivable again. Same for members of other teams who would like to follow other reviews, or members of the support department, etc.

So my practice: 30min max reviews, with 5min introduction, 20min presentation of completed items, 5min opening on the next steps (the release plan). If it turns out that the review triggers an unexpected sum of feedback, don’t hesitate to provoke a dedicated meeting.

Sprint retrospective

By the way I’m surprised (I had forgotten?) that Schwaber and Sutherland allocate less time to the retrospective than to the sprint review. Ouch. I disapprove (but they don’t care and they’re right to). My practice pushes for retrospectives that oscillate around two hours every two weeks. Another precision that bothers me: plan for implementing improvement*s* (plan for implementing improvements). It seems essential to me, even if we detect several improvements (which is often the case) to limit ourselves to implementing a single resolution (and to stick to it hard as stone). Indeed, resolving the difficulty estimated as main by the team every two weeks is already a fine accomplishment. Launching into resolving several improvements simultaneously rather has the result of diluting the objective and sticking to it less… This variation is perhaps due to the fact that these gentlemen envision iterations of one month, who knows.

My practice: 2 hours, 1 single targeted and measurable/achievable improvement, the main one in the team’s eyes.

Backlog

Ok ok. But in my experience difficult to give a chiffered business value to each backlog element (it’s possible for features, hard for user stories), with breakdowns and other manipulations it quickly becomes a Chinese puzzle, so I don’t suggest it.

Another differentiator with my practice, in case of product or project that are led by several teams I propose several backlogs, which isn’t the case with Schwaber & Sutherland who suggest a single shared backlog. Naturally in my practice the vision, the project is shared but each team has its backlog. Simpler, more readable, more efficient, it forces clarification of objectives and dependencies.

Definition of done

Schwaber & Sutherland assign, not very clearly, responsibility for the definition of done to the development team. It’s certainly not simple, it’s one of the hardest things about Scrum. For me the definition of “done”, of finished, belongs to everyone… even beyond the Scrum team itself. I don’t arrange and simplify things. I repeat, “done” is one of the most arduous things. It’s a notion that must suit the team (without that it learns to bypass it), but that must also suit the organization (without that how to integrate several teams working on a common whole?). It’s something that addresses tasks (underlying elements of user stories) as much as the user stories themselves, even sets of user stories, or even the sprint, and the project in its entirety. After that, what to say if not repeat: it’s a complex element to handle. So my only recommendation is: sensitize as many people as possible on this difficulty and this importance, open the discussion with the whole team on it, communicate regularly on it with stakeholders.

An inclusive framework

Even though I took the time to note my “differences” or certain reflections, I’m always amazed by the quality of this little work. 20 pages to summarize a formidable tool -very mature-, in a simple and clear way. And above all open: the manual seems to say: take me, use me, I’m not limiting, I’m inclusive. We’re far from other methods or frameworks much more exclusive (XP to name it…). I think that this openness, which we find in Kanban, is a very beneficial thing about Scrum. Naturally it’s also why we get lots of sorcerer’s apprentices and deviations, but it starts from a good idea: come, the Scrum inn is open. Take.

Feedback

August 9, 2013: Anthony Cassaigne

I can say that I largely share your point of view. Particularly that it’s difficult to have a (coherent) objective in a sprint. I still haven’t found how to do it. Yet in Scrum and XP from the Trenches Henrik Kniberg says it’s not negligible because it can prevent getting lost.

For the definition of done, I insist on defining a Done for each element. That is to say give yourself a definition of done for the US, give yourself a definition of done for the sprint, give yourself a definition of done for the release. And for the team, if there’s divergence of viewpoint among developers that they define done for a task.

What’s your point of view on the notion of ready US? I find it seductive because it officializes and formalizes the possibility for developers to refuse a US for the upcoming sprint. But I haven’t tested it.

Anthony, thank you for your feedback, I’ve seen a definition of done made for each type of element, it seemed to me a gas factory, another complication. So I’ve never tried and don’t plan to unless the actors request it. That induces too much complication and we lose the idea of “whole” that seems indispensable to me. At worst I risk hearing “ah me my thing it’s done, at my level”. Yet it’s done or it’s not done. Saying “it must work with 200,000 simultaneous users” addresses the user story as much as certain tasks. People are intelligent and know when it impacts the user story or the task, or both, etc. If the definition of done is too large (more than 15 elements… at 10 I already feel a limit) that saddens me too. We should “have it in mind”, compact. This limitation is also a form of prioritization.

August 10, 2013: Grégory Salvan

I really appreciated your article on the scrum guide 2013. It’s very inspiring work, I think we should all do it. My little experience being different I have some remarks.

"[Your] experience leads [you] to think that it’s generally better not to have a Scrummaster than to have one who produces and who estimates."

In mine, product owners weren’t able to properly define their product without us helping them because they don’t properly understand the developer profession (often a problem of story independence).

What I noticed is that without SM “someone who produces” takes charge of helping the PO and “by chance” it’s always the same person.

Similarly as a dev. I would have trouble accepting an SM who doesn’t produce or who is neutral. On the contrary I expect them to be involved in their relationship with the PO and in production work. If they’re too far from technical problems there’s a “black box” effect with the PO who doesn’t understand why a story takes “so much time to be realized” (for ex.)

On the other hand for me they must be impartial and that requires a certain perspective when you produce.

Another point I noticed, when there’s no SM, is that problems are solved later (sometimes after the retro) because nobody in the team wants to decide for others or interrupt their prod. to take care of something else.

I would tend to say that an SM who isn’t a developer produces a silo effect.

Have you encountered similar problems and what did/would you do in these cases?

++ for team size and also for sprint objective that reminds me of phases in a classic project.

Ideally I would replace sprint objective with a revision of/ reflection on product vision. (even having 2: one for the current product and one for the product we want to make in the idea of behaviorism: initial state / final state)

What do you think?

Thank you Grégory (sorry but not available for the canoe outing). I don’t agree with you on the Scrummaster or PO position. A PO leaves the “how” to the team. So they don’t necessarily have to know the arcana of the technique. It can help them optimize their backlog ordering, but for that they just need to listen to the team and trust it. They must approach questions from the business angle, thus freeing, leaving entirely to the responsibility, all realization questions to the team. So that shouldn’t be a hindrance, it can even turn out to be an advantage: these POs aren’t tempted by “How”, they restrict themselves to “What” and “Why”.

Another thing: I’m not saying there shouldn’t be a scrummaster. It’s always better with a scrummaster. In cases where it proves impossible: I say that to properly understand the underlying mindset, the required culture, it’s better not to have a scrummaster than to betray the role by making it exit its neutrality.

That someone helps the PO, I don’t know, they’re self-organized, and they do what they think is right. If it’s not the right PO, you have to dare say it, that doesn’t question the person’s qualities, but taking this role at this moment, in this context.

If the scrummaster isn’t neutral, they can’t facilitate, they can’t communicate, they can’t help people understand Scrum. Being neutral doesn’t prohibit helping people, by doing everything in their power outside the attributions of the PO or the team. The POs I encounter quickly understand why a “story takes so much time to be realized” because they actively participate in sprint planning, the place for all discussions on this subject. Usually it’s organizations that have trouble with a true Scrummaster, you have to succeed in selling them someone who will have no direct productivity but will be the source of major productivity for the whole.

By keeping Scrummasters who code, who estimate, we just stay in the old world, we don’t take the leap. Through what may seem like a detail, an enormous implementation difference is hidden.

Yes reflection on the product must be constant. Like the backlog, a living element in permanent mutation.

Thank you for your feedback.

August 14: feedback from Claude Aubry (pablotages!)

Here is Claude’s article on his blog: http://www.aubryconseil.com/post/Scrum-Guide-2013-et-pablotages

And yes, on my side it’s not mandatory for the Product Owner to be present at the “daily scrum”. Let’s be clear: if the Product Owner could listen to all “daily standups”, that’s best. But it’s definitely a meeting within the dev team in the scrum team. Even the scrummaster isn’t mandatory (but they must ensure that the daily scrum proceeds correctly). It’s the moment of knowledge sharing within the team (in the self-organized team), not the moment when we solve big problems, nor when we make big decisions (small ones ok: “I’ll do the review of your task”, “I can help you on”, etc.).

It’s not forbidden for it to be the moment for big actions or big decisions. Why deprive ourselves? But then we exit the “daily scrum”: for example we clap our hands and announce: “ok daily scrum finished, special meeting on this subject”. Because we must absolutely preserve the 15min (max, not min) of the “daily scrum” to guarantee its sustainability. It’s an essential meeting.

August 21: feedback from Pierre Neis

Good your review, you highlight points that were highlighted in…. 2011… or even 2008?

The major changes in the guide occurred in 2011. In the new version the subtleties are rather rhetorical (http://static.squarespace.com/static/51e3f87ce4b0031a73dac256/t/51f7de63e4b0eda27e6ea4ef/1375198819807/Scrum%20Guide%202013%20(Changes).pdf) :

  • artifact transparency –> clearly, if the team alone knows the artifacts or if documents are hidden on a server, it’s FLOP
  • Sprint Planning returns to an event: since 2011, planning was separated in 2 by WHAT and HOW. The Planning result is the same since 2011: Sprint Goal (the team announces what it seeks to achieve, a plan defining how it plans to go about it, a Sprint Backlog. Also since 2011, the Scrum Team no longer makes a commitment but a forecasting, an estimate.
  • Backlog Refinement instead of grooming are terminology choices related to the English language that can be subject to interpretation. The notion of ready is reinforced: a team can accept that a “ready” item –> linked to INVEST. This reduces the “push” side.
  • Scrum events are an integral part of the Sprint and these are time-boxed. This means that all events outside these are distractions, but also it prevents negative reactions from the growing number of meetings. This is a point of attention brought to Scrum Masters.
  • The Daily Scrum was since 2011 the developers’ Inspect/Adapt. 2013 reinforces the planning side by revisiting the 3 questions to link them with the Sprint objective. In my teams this brings great help in bug detection. During the Daily, developers do triage and can either integrate them into the Sprint or push them into the preparation queue for the next Sprint if it’s technical debt.
  • the value concept at Sprint Review: this subtle point is important because it reinforces developers’ position facing the business. The review, not to be confused with the demo which is a small part of the review, has the objective of finding consensus between the Scrum Team and the business for the next Sprint with the aim of optimizing results (business value vs technical debt).

There, it’s not complicated ;b)

Ah yes, I forgot. Little reminder of meeting durations:

  • when it indicates 4 weeks max, that doesn’t mean that less isn’t possible. On the contrary, it’s recommended.
  • max duration of a Sprint: 4 weeks (2 is optimal, but if your clients aren’t available?)
  • max duration of a Sprint Planning for a 4-week Sprint: 4 hours (inversely proportional)
  • max duration of a Daily: 15 minutes
  • max duration of a Sprint Review for a 4-week Sprint: 4 hours (inversely proportional)
  • max duration of a Retrospective for a 4-week Sprint: 3 hours (inversely proportional)
  • grooming, oops refinement: 10% of Sprint time max.

For team size 5+/- 2 people, actually it’s been working this way since 2004. It’s actually about group dynamics: beyond 5 people team productivity proportionally stagnates or even decreases (% h/dev).

Well then, I’m done. Sorry for accents, my US keyboard isn’t complete :b((

From a personal point of view, the remarks I could bring on the Guide are the following:

  • the rhetorical cosmetics is definitely oriented toward management to reduce the “push” effect i.e. command&control
  • I would have liked to see the notion of Sprint as “pull system”, pulled flow for you ;b)
  • since 2011, I’m waiting for the Release Planning part which is a blocking point in organizations with multiple Scrums (mine)
  • clarification on SoS
  • the notion of Product Line, Governance and Portfolio Management linked to Release Planning
  • the notion of Level of Done (LOD), related to XP, defining the quality level delivered by developers.

@+ Pierre

Pierre, thank you for your feedback. (don’t have the courage to replace accents). As I said, comparing different versions and the historico-chronological approach matters little to me. What interests me more are the gaps with my practice.