Downside of Dialogue Sheets

Something I’m very conscious of is that I don’t hear much about the downside of Dialogue Sheet Retrospectives. As much as I’d like to believe that this is because there is no downside I can’t honestly say I think that is the case.

There must be downsides.

I have had several suggestions for improvement and some of these have been incorporated into some sheets. There are also a couple of pending improvements which I’ve yet to action. Because there are several sheets and because not all of them are for retrospectives some improvements get incorporated into some sheets but not others. In part I’m happy with this because it increases the differences between sheets.

At XP Day this week I had several conversations about the sheets and I now think its worth listing some reasons people choose not to use the sheets or negatives that emerge. Some of these I’ve known about for a while and may have mentioned before, some are new.

In no particular order, and in my words summarise what I’ve heard….

“The team looked at the sheet and don’t see how they would be an improvement on the current retrospective format”

This reason has been given by several people/teams and while I respect it as a team’s decision to make I can’t help feeling that it pre-judges the sheets. Surely the “Agile” way of doing it would be to try a sheet and see what happens. After all, what have you got to loose? One or two hours, one retrospective.

“We need a facilitator”

Almost a continuation of the previous one another reoccurring comment is from people who can’t imagine not having a facilitator. Again I would suggest try it and see.

I have observed many retrospective dialogue sheet sessions and I find them very interesting. If a facilitator wants a role I have several suggestions:

• Take off the facilitator hat and join the retrospective, you will get insights for the next time you facilitator
• Observe silently from the sidelines: you will learn things just from observing
• Use the sheets from one retrospective as input to the next, go back and pick up items, delve deeper into issues
• Use the sheets as first exercise in a longer retrospective; do a sheet then go back over issues that arise

You might not need a facilitator but that does not mean you must not have one.

“Facilitator would go deeper”

I am convinced there are issues and times where having a facilitator will produce a better outcome. For example, some issues benefit from talking about in depth. That is why I always thing the sheets are one tool amount many. However I don’t think you always need to go deep. As with the first two items in this list i encourage you to try it and see.

Cross training retrospective facilitators

This might be a rare reason for not using the sheets but is quite valid. One company wanted to train a number of people to under take retrospectives so each retrospective was used as a training exercise for a facilitator.

“We have a company mandated retrospective format and we cannot change it”

This has to be the worst reason for not trying any new technique in a retrospective. If a team cannot change the retrospective format what chance have they got of acting on any findings from the retrospective? Actually I think this suggests a bigger problem.

Mechanical sheet filling

I only have a second hand account of this and I’d like to know more. It appears a team at a large media company in Salford do not engage in conversation in doing the sheet. It appears filling in the sheet has become something of a chore and they simply “do it”.

With out knowing more about this team (anyone know them?) it is hard to say what is going on. It sound like the sheet has been imposed on the team and they are completing it like another piece of administrative paperwork.

Fear of team dynamics

Some people are worried that personality issues on a team will disrupt the dialogue sheet process - conflicts, arguments, etc. I think this is a valid concern. Although I then immediately think of two things.

First: this is an example of a bigger issue - if these people can’t spend an hour together on a collaborative exercise then working together must be very difficult.

Second could this type of exercise actually help with those dynamics? I would guess the answer is sometimes Yes and sometimes No.

Bored by repetition

There are a few teams that have tried the sheets used the them regularly and then they have fallen into disuse. I suspect this is true of any retrospective format that is used too much. The trick is to find whats to keep the retrospectives fresh and keep them generating new insights.

If you know of any downsides or problems with dialogue sheet retrospective then please let me know. I might be able to correct it in a sheet, if I can’t then we can at least understand their use better.

10 pieces of advice for teams

I have started to write up a more useful description of Xanpan. In doing so two things have happened. First I’ve realised that I have an awful lot I would like to say about it, I’m terrified it will become another book. Second, I’m becoming more and more aware of how Xanpan differs from Scrum, XP and Kanban.

As a result I expect this blog will get a little quieter. But before the end of the year I’d like to get a few entries finished and published which have been languishing for a while.

So without further ado here are 10 tips for teams and those who manage, administer or simply organise teams. Of course, if you are a self-managing team you should all read this list.

1. Don’t load overload teams - consider 76% utilisation about the max
2. Keep teams together - bring the work to the teams, don’t form teams around pieces of work and then break them up when it is finished (Corporate Psychopathy)
3. Minimise disruption to the team, if the team needs to be regularly interruptible and responsive then set processes and expectations accordingly
4. The more self-standing, free of dependencies, the team the more effective they will be
5. The team should own the process and methods of working as well as the things they work on. By “own” I mean: they are allowed to change the process and methods.
6. Make the boundaries and responsibilities of the team clear
7. The team needs a full skills set to fill 4,5 and 6; and those with the skills need to be on the team full time
8. Aim for an MVT (Minimally Viable Team) so put slightly fewer people and skills on than you initially think, expand the team as they show success but always keep them minimal
9. Aim to recruit slowly and regularly, avoid foie gras recruitment, i.e. stuffing the team full of new people in the hope of increasing quantity in the near future (you won’t, you’ll cripple yourself in the short term)
10. Give the team as much authority and power as possible to do their work, the more decentralised the organisation the more effective this will be

Looking at that list two things strike me. First is how many of my older blog entries are linked. Second about three of those items are things not to do. Simply not doing bad/mad/stupid things can deliver benefits.

Hard-Core Scrum, Common Scrum and Scrum (continued)

Since I published Scrum, Scrum and Scrum on this blog last week the piece has received a lot of attention and I’ve had a lot of feedback: comments on the blog, comments on Twitter and comments to me in person at Oredev last week.

On the whole these comments have been in agreement. My impression is that people find the posting a useful distinction between Synonym-Scrum, Hard-Core-Scrum (or ScrumTM as I’ve also called it) and Scrum-Lite (or Common-Scrum as it might better be called). In this blog entry I’d like to clear a few things up and reply to one particular comment from Kurt Häusler which I think deserves more attention.

Just to be clear: I’m not attacking Scrum here. I’m discussing difference in how it is perceived, what people call Scrum, and where I think “Scrum” is inconsistent (OK, that might be criticism.)

First terminology.

In using the term ScrumTM I am being sarcastic. Nobody owns a trade-mark on Scrum, anyone can use the term Scrum and the ideas in it. So lets stick with Hard-Core Scrum.

Scrum-Lite also seems to upset people, this name was meant to designate a form of Scrum which is not Hard-Core-Scrum. Lets use the term Common-Scrum because this is the way I most typically see the Scrum ideas implemented.

Next the issue of Project Managers, and to a lesser degree Architects and other specific roles on Scrum. Kurt wrote:

‘Anyway, anyone saying project managers and architects are not allowed in Scrum is simply wrong. Are they really saying that though? And are people saying that really representing a different meaning of the term "Scrum”?’

Taking it in reverse order: I am the one who says there are two-forms of Scrum. I think this makes a useful distinction which helps me, and I think others, understand the world we live in.

Kurt’s first question is the more interesting one, if the answer was “No”, if the world did have a homogenous view of what Scrum is the second question, and the distinction would be unnecessary.

So Kurt, the answer to the first question is a most definite Yes. I think the point is well made by Christin Gorman in her 10 minute video on Vimeo from the Roots conference - “Putting an architect in a Scrum team is like putting mayonnaise in a cake.”

Let me say straight away I’m not picking on Christin here, I actually agree with much of what she says and she is not alone in this view. There are other - better known - names who say the same thing:

• In The Scrum Primer Deemer, Benefield and Larman say “there is no role of project manager in Scrum.” These words are in version 1.1, there is a Version 2.0 on the Scrum Foundation website which adds Bas Vodde to the author list and contains the same words. I haven’t read v2 in detail so maybe in contains more advice for project managers.
• The Scrum Handbook on Jeff Sutherland’s website contains the same words - in fact the biggest difference to The Scrum Primer seems to be the author list.
• I personally heard, several years ago, Craig Larman answer the question “What does a project manager do in Scrum?” by saying “If you have a project manager in a Scrum Team you are not doing Scrum.”

The important point is: Christin understands Scrum to mean “No project managers” and Kurt understands Scrum to allow project managers.

I sympathise deeply Christin’s point at the end of the video, if I may paraphrase: “lets save Scrum to mean what it was meant to mean”. I just happen to think this particular cat is out of the bag. Rather than trying to “save” or “reclaim” the name “Scrum” I prefer to differentiate.

Interestingly, as I have commented before (“When did Scrum start loving project managers?”) Ken Schwaber hasn’t always shared this point of view:

• In Agile Software Development with Scrum Schwaber says “The Scrum Master is a new management role introduced by Scrum” and a little later “The team leader, project leader or project manager often assume the Scrum Master role.”
• In Agile Project Management with Scrum Schwaber says “The Scrum Master fills the position normally occupied by the project manager. I’ve taken the liberty of redefining the role.”

Now perhaps I’m guilty of not checking my facts. I haven’t e-mailed any of these people to ask where they stand on Project Managers and perhaps I should have. (If any of you are reading this please feel free to comment.)

However, I don’t believe a definitive statement would make much difference. What if I had a statement from one of these people saying “Project Managers are in” (or out) ? There would still be people out there interpreting Scrum the other way. It is too late to change this now.

Personally I believe that overtime those who define what Scrum is - those named here plus a wider community - have changed their position on Project Managers. I suspect that in the beginning there was no anti-Project Manager bias. Then is crept in, and now it is less, or perhaps gone altogether.

The points I want to make are:

• there is are different understandings of what Scrum is
• I, and I think others people, find it useful to make a distinction

I really don’t care if you want to say “Common Scrum is not Scrum because…” or “Hard-Core Scrum because…” is not Scrum, because I’m not describing what should be, or not be. What I am describing here is how I find the world.

Comments please?

Scrum, Scrum & Scrum

I’ve come to believe there are three different meanings of the term “Scrum” - well, three inside the software development community at least, if we consider sport we can probably add a fourth.

Even if nobody else does I differentiate between:

Scrum as a synonym of Agile

“Scrum” means “Agile” like “Hoover” means “Vaccum Cleaner” in English English, or like “QTips” means “Cotton Bugs” in American English, or increasingly “Google” means “Internet Search” whether you are using Google, Bing, Yahoo or some other search engine.

This is the way I believe a lot of software people use the term Scrum. Although Agile is more than Scrum alone often (mostly?) when people say Scrum they mean some a general form of Agile, something with iterations, stand-up meetings, perhaps User Stories, perhaps some technical practices, etc. etc.

Hard Core Scrum, ScrumTM

This is Scrum without Project Manager or Architects, maybe even without Testers. This is Scrum of Commitment and Abnormal Termination of Sprints.

I once heard Craig Larman say “If you have a project manager on a Scrum team you aren’t doing Scrum.” Only last week Christin Gorman Tweeted saying: “If you want to use managers and architects, you won't be doing scrum. And that's ok.”

I’ve written before about how this hard-core Scrum might actually conflict with Scrum (When did Scrum start loving Project Managers) and XP (Two ways to fill an iteration).

This view sees Scrum as a kind of Communist Manifesto but with Managers as the Bourgeoisie. It would be funny if this weren’t so serious. I believe that if you take this interpretation you will soon run into opposition from a layer of managers. The paradox is that Scrum is as popular as it is because those manager don’t like Extreme Programming and saw Scrum as the management friendly alternative (The Three Advantages of Scrum).

Common-Scrum or Scrum-Lite

This is Scrum but without the anti-manager zeal. Of course for many people this strips Scrum of its primary asset - and they might be right. It might be that if you neuter Scrum you get a less effective result.

In this form of Scrum Project Managers still exist - assuming you had them to start with, a lot of places don’t. However they have been renamed Scrum Masters - see my example from 2008.

In Scrum-lite the word commitment really means “agreement” because the team are probably using velocity to judge how much work they can do. Architects and other ranks, sorry, roles, still exists. And companies still kill teams - corporate psychiatry is rampant.

In other words: it is full of compromises. It works for some companies, it doesn’t work for others and ScrumTM purists will hate it.

Anyway, I find it useful to distinguish between these three uses of the term “Scrum”. If you know any more please add them to the list.