I thought I would give more details here.

Our goals

We didn’t exactly manipulate the participants, but we certainly did not reveal, on purpose, what our goals were:

• help dissenting voices come out of the closet — very few people are vocally criticizing Scrum today in France, and I have found no blogs. I wanted to show the pro-Scrum side that they do not have the final word.
• let people vent — both pros and antis
• make participants think — one later came to me and suggested that I should have offered “alternative solutions”. Well, I have none (though I do have some starting points, see below)

Alternative endings

We had prepare additional materials, in case the discussion died out. Fortunately, it was so lively that we couldnt use them at all. You’ll find all three of them below.

You are not alone

The first thing I wanted to highlight is that, though dissenting voices on Scrum (or Agile) are not currently heard in France, they do exist in the rest of the world:

• James Shore has blogged that “when people say “Agile,” they usually mean Scrum” and that “it’s very easy for teams using Scrum to throw out design“. Finally, he points out that the “Scrum makes it worse by ignoring important (but hard) agile engineering practices, and the Scrum Alliance makes it worse still with their armies of trainers [...] issuing dubious “ScrumMaster” certificates to people“. There is more in today’s article on InfoQ.
• David Anderson lobbyied hard for an ‘Agile Fringe’ stage at Agile 2009 Conference, feeling that the vocal agile community is too mainstream. I agree with him, and I feel that the Agile 2009 program could have given more room to dissenting voices. The Agile Frontier stage is not bad, but it should have gone further.
• Naresh Jain says that Agile (as practices today) is the new waterfall.
• which reminds us directly of Steve Freeman‘s aphorism, uttered during CITCON Amsterdam: “Scrum is the new RUP”
• some people did manage to get controversial sessions accepted to Agile 2009. Not all are directly related to Scrum:
  • JB Rainsberger: Integration Tests are a scam
  • Bas Vodde & Steven Mak: Let’s Stop Calling It Agile
  • Paul Hodgetts: ScrumMasters considered harmful – Where did it go wrong?
  • Brian Foote & Joseph Yoder: Big Balls of Mud: Is this the best Agile can do?
  • also, there might be good content at Linda Rising’s Agile: placebo or real solution?
• last but not least, Alistair Cockburn, author of the Crystal family of methodologies, signatory of the Agile Manifesto and Certified ScrumMaster Trainer, will host a keynote at Agile 2009 entitled “I Come to Bury Agile, Not to Praise It”

Scrum has Crossed The Chasm

There is a model that give hints to the current situation with Scrum. It is the Technology Adoption Life-Cycle, as amended by Geoffrey Moore in his seminal book “Crossing The Chasm“.

In short, it appears that many of the arguments against Scrum do not just mean that it is poorly explained, nor just that it is poorly understood, but rather that it is now being adopted by a large number of people. Or, to rephrase this, that it has been (consciously or not) packaged in order to be palatable to the mainstream. This implies trainings, books, consulting services, explanations, case studies, success stories. In short, packaging the approach just like a marketing team would do. That the people behind Scrum did it on purpose (as I believe) is beyond the point: the Agile approach that wins the hearts and minds of IT professionals everywhere is necessarily the one that comes with such as package, a whole product, in the words of Moore.

That is a reality that people that are blindly against Scrum must acknowledge.

ARXTA

Finally, I would like to point any aspiring Scrum-evil-ist to Brian Marick‘s writing on Agile roots. His argument is that “Agile” (and, I guess, the names of pretty much all Agile methodologies) is too easy a term to adopt. In other words, many people will look at the name, glance at the practices, and quickly come to the conclusion that “hey, this is exactly what we’ve been doing all along! Let’s avoid asking ourselves hard questions and let’s not change the way we work.” Which is, obviously, missing the whole point.

Brian has came up with a new name for the roots of Agile: “Artisanal Retro-Futurism, crossed with Team-Scale Anarcho-Syndicalism.” The name is cryptic (and even slightly repulsing) on purpose, so that people will have to ask, and will have to have a conversation.

Further reading

Check out

• my photos of the notes taken on easel pads
• the transcript (in French) of the session by Nicolas Martignole (Google translation in English); he even has a recording somewhere on his site
• my notes from the session at CITCON Amsterdam 2008
• “Is Scrum Evil?” a question asked by Jeffrey on Stackoverflow

According to an interview of Jeff Sutherland, for every CSM, there are 10 Scrum teams that have not had training.  That is, 300,000 Scrum teams.

Finally, Scrum defines that a team is made of 7 people, give or take 2. Taking the conservative value of 5, this means that we have 1,500,000 people doing Scrum.

One and a half million?! Is it really possible? That said, even taking more conservative numbers, there is no doubt that many people are using (trying to use?) Scrum. The annual Agile Survey showed that more than 60% of agile projects are using Scrum, or Scrum combined with XP.

To be honest, this is probably off the mark but maybe not by an order of magnitude. Some estimates put the number of developers worldwide to something between 8 to 13 millions. I’d be surprised that even 5% of developers worldwide are using Scrum (400,000 to 650,000 individuals), but the 1,500,000 figure contains all people in a scrum team, including some that probably do not qualify as developers, such as business analysts, testers, graphical designers, etc. So it could work.

At least it would explain why many people now start to think that Scrum Is Evil.

This was a typical discussion where antis are much more vocal that pros. When Jeffrey asked who thought Scrum was evil, maybe 12 raised their hands. Only 3 or 4 (including me) thought that Scrum was NOT evil. The majority stayed silent.

Most of the session was spent listing arguments pro and anti Scrum. You could say it was lively ;-)

“Scrum is evil because…” (I am not saying that I agree with all of them…)

“Scrum is good because…” (I am generally OK with them)

The first conclusion of the session to me was that the people against Scrum were mostly complaining about the fact that some projects were failing with Scrum.
Further, I feel that this reveals that they are in a post-agile mindset, which could be more prevalent in the US/UK (maybe the Netherlands, too?) than in France where Agile still faces an uphill battle.
Another thing is that, when you look at it, the people were really complaining about its success. After all, many of these arguments (pyramid scheme, some people feeling it solves all problems) were the very reasons Scrum was successful.

As Jeffrey pointed out during the session, it meant that, as per described in Crossing The Chasm, we are simply moving from the ‘enthusiasts’ stage to the ‘early adopters’. Many more people are now using Scrum, and its message is bound to be altered somewhat.
Jeffrey further pointed that, since it seems that 80% of projects fail now that many are using Scrum, just as there were 80% of projects that failed before, it simply means that 80% of the population is just not very competent. It has little to do with the methodology. This is also what Alistair Cockburn meant when he mentioned that “Process is a second-order effect”.

So, my undertanding is that Jeffrey’s goal is to change people and to use tools such as psychology to do so.

I am more nuanced, maybe because I am living in a country were Agile is still not being widely accepted. After all, this is all a short-term vs. long-term thing. Having a manager doing Command & Control was very short term. Agile (and Scrum) is medium term: you are providing a tool for people to get better in the medium term, if they are competent enough. Changing people is much longer-term thing. It might take years, generations, or may not ever happen.

For me, Scrum still seems to be providing those medium-term benefits, at least for now, in my environment. When it won’t be the case anymore, I might bash it like everyone else does.

Update (07/10/08): changed title from “Scrum is evil!” to “Is Scrum Evil?”

The idea came from the book Toyota Way, by Jeffrey Liker. At the beginning of the book, the author warns the reader against a classic trap: after reading about the success met by Toyota, many want to implement their practices verbatim. Well, my philosophy is that, if I got only one useful practice from the book, then it was worth paying for ;-)

So anyway, the author is telling about the fact that Toyota employees do “A3 Reports”. The idea is that, when there is a problem, after careful thinking, the people in charge produce a report that fit on an A3 page. The reason for this constraint is that 1) is it quick to read, 2) it can be faxed around the company with the fax machines they have.

Another thing is that they tell about the problem and the solution using Plan-Do-Check-Act (PDCA). Which means that their reports typically contain:

• a description of the problem
• an overview of the possible solutions, including options that were later discarded
• a description of the implementation of the solution on a limited scale (Plan & Do)
• a description of what needs to be monitored, and milestones (Check)
• if the solution is proving a success, a description of the implementation company-wide (Act)

I was personally attracted to the reports, because they force the writer to keep the information concise, though readable. Graphs were good too, as long as they make the contents clearer to the reader.

My personal problem was that, as a ScrumMaster, I have to produce reports every time we complete an iteration. The reports are boring to write, probably boring to read, and they were getting longer as the various stakeholders regularly demanded that I add more information. Other metrics that had to be maintained included productivity, progress on project, etc. I felt that these metrics were not very useful and I had also been getting into arguments with my boss’ boss, especially after a steering committee where it had become clear that I couldn’t make the situation easily understandable to our clients, even with an Excel document containing 6 sheets. So I was feeling some pressure to show goodwill, and to produce something that was actually useful.

One day, my direct boss demanded that I produce not only my usual textual report (generally 2-page long), but also a 10-slide PowerPoint presentation. I was underwhelmed, since I already felt my report was not that useful. I got her, though, to agree that, in addition to what she wanted, it’d be worth trying those shorter reports.

I set myself the following constraints:

• must fit on a single A4 sheet, as this was the only format of paper supported by our printers
• character size must stay at 12 points for normal text; text that was part of graphs just had to be “as readable as I could make it”

The result for the first Sprint to have an A4 report is the following (in French):

Things of note:

• the 3 columns; they are the key to fit as much text as possible when you have many bullet points
• the charts, especially the burndown chart. This was the first time I managed to show the burndown chart in a readable fashion in a report to people external to the team.
• the content, which is made largely by the information gathered during the iteration retrospective

When my boss saw this report, she was delighted. It became the main document discussed during steering committees between the various stakeholders, including the CEO of the company. I also sticked it to the walls of the development room, in full colors.

In later iterations, I refined the report a bit, but it stayed largely the same. For a few iterations, I had a tendency to change the charts, depending on the situation (for example, if speed of development was an issue, I’d add a chart showing the number of actual work days per iteration). I have found that it was not as necessary in later iterations. Probably a good thing, as I would not be able to gather all the data necessary.

Here is how it looked in a recent iteration (in French again, so it might be hard to figure out what each box is for):

How I build the report:

• The report is built using Excel. Some charts come from external sources, such as the burndown chart which I extract from the Google Spreadsheet-based Sprint Backlog; an issue is that, being images, they are hard to redimension. Other charts come from separate Excel files, which is a bit annoying as Excel suggests pulling data from the other Excel files every time I open the report. Finally, some charts are made from data that are hard-coded in the same Excel file, such as velocity and code coverage.
• A lot of information is actually coming from the Sprint Retrospective. I can prepare a few things before the retrospective (mostly the charts) but much of the data is mined from what was learned during the retropective.
• I spend quite some time adjusting the boxes on the sheet. The best way I’ve found is to use drawing features from Excel that let you perfectly align or center elements together. Still, it takes significant time to clean up at the end.

For your information, here is a list of the noxes used in the last report. You will want to adapt this to your needs:

• Sprint Number & Dates
• Implemented Features
• Features that Were Not Implemented
• Important Facts from the Sprint
• Burndown Chart; this is now coming from a Google Spreadsheet ;-)
• Statistics on bugs
• Things We Could Improve Upon
• Things We Are Happy About
• Actions For Next Sprint
• Project Trends
• Velocity
• Overall Progress on Project
• Overall Bug Statistics
• Code Coverage By Tests

I hope all this will help. Let me know your improvements on my design!

First, it should be clear that all these are technical debts. Yes, they are very common. Yes, it might be impossible to completely get rid of them. But still, they are evidence that the work done in previous iterations was less than optimal. It is therefore appropriate to address them during the retrospectives. Ask the usual questions: “we received 20 bugs during the last iteration. What can we do to reduce that number in the future?”

Because these items are technical debts, they should not be estimated in story points. We want to make clear that there is no functional gain from fixing bugs or refactoring the architecture. This means that, in practice, the number of story points that can be handled during an iteration might be less than before because of the time spent on bug-fixing. This is a good thing (of sorts): it makes clear that things are going slower, precisely because of our sub-optimal work in the previous iteration.
So, I recommend not estimating them in story points. I also recommend dimensioning the iteration with the same number of points as before: generally, with the developers increasing their velocity, it might be possible to work on the technical debts while still maintaining the same velocity. If that is blatantly impossible, then take a drastic measure such as halving the number of points for the coming iteration. You want to make it clear that things are not going well.

Although the technical debts should not be visible in the Product Backlog, it is probably worth having them in the Sprint Backlog.

From the point of view of tracking, this is not strictly necessary: the team members should handle bugs as soon as they hear about them. However, I have found that they are more comfortable when they can relate to an actual task in the Sprint Backlog. The simple fact of moving a sticky note on the wall make them more confident during the Standup meeting.
For some tasks, it is also useful to have sticky notes as a reminder that they must be dealt with. This is particularly the case of architecture refactoring.

At any rate, these tasks should definitely be estimated in ideal engineering hours. Usually, this is not a problem for architecture tasks (“we feel we’ll need 16 hours to update this package”). For other bugs, the best is to make an educated guess using yesterday’s weather (“we’ve spent 40 hours last iteration on bugs, but there are more users this time, so they might catch more of them. Let’s say 50 hours.”).

It is possible that bugs will reveal to be much more complex than expected. In this case, simply tell the Product Owner as soon as you are aware the iteration goals cannot be met, and see if some features can be dropped.

To sum up:

• if technical debts are more or less recurrent, just deal with them in the Sprint Backlog, and do not change your velocity (much)
• if the technical debts appear very complex to fix, negotiate with the Product Owner before the start of the iteration (“how would you feel if we spent the next entire Sprint fixing bugs? what about half of the Sprint?”), or during the iteration (“we thought at the beginning of the sprint that there would be a certain amount of bugs, but evidently, there are much more than that. What task can we drop?”)
• in all cases, always reflect on how to improve the situation.

Update (05/01/08): a translation in French of this article has been posted to the Valtech France Blog.

I joined the project in February this year. My first idea was to convince the project lead that Agile Is Good ™, but I quickly gave up, especially since he had made clear in pre-assignment talks that he was rather skeptical.

I then resolved to do whatever I could on my side. TDD, some Continuous Integration, some rare Pair Programming… all good stuff, but my heart was not into it (except for TDD).

Then, just a couple of weeks ago, I was joined by another consultant colleague who had agreed to the assignment because we would be doing Agile stuff. Finally, we did real Pair Programming, real Continuous Continuous integration, and still real TDD.

And, best of all, we finally came up with something that looks like a Sprint Backlog. Not that I didn’t know how to do it (between my 2 years of experience on Scrum and Scrum trainings that I give, I have written a few), but the simple fact that I was by myself made me gave up on it. Originally, I wanted to write one in order to show the project lead how things can be done, but that had never materialized.

Of course, not all is good yet. To start with, we don’t have proper iterations, just a deadline 6 weeks from now (we could easily do 1-week iterations). Another thing is that each pair of developers is isolated in a separate room. To mitigate this, we have started displaying the Sprint Backlog as post-it notes in our doorway. We haven’t dared displaying it in the corridor yet, but already many people stop by and are intrigued.

For the moment, we keep the Sprint Backlog in an Excel file as well. This is to help us communicate with the project lead who prefer documents that look more “official”. It is also a simple way to communicate with our managers at Valtech who want to know if there are any risks with us not delivering on time.

I am leaving for a 3-week holiday at the end of the month. Considering that my colleague is highly motivated, but all by himself, I’m curious to see how things will be when I return.

Maybe the rest of the team will be impressed enough to try it themselves? I already heard one person asking if the project is officially using Scrum or XP now.

I have been very impressed by Jean’s easy-going personality. As most people had left the office, I was still hanging around with the boys for a few more minutes when Jean came over and ask if there was anything left to drink. Well, our resourceful Gian managed to find 2 bottles of red wine and the party went on till 10pm.

This is very much in contrast to the only other ScrumTrainer I know, Craig Larman, who I think can be fairly described as “frugal”.

Benefits:

• each team feels more committed to the document and to the burndown chart
• delays specific to a team would not get hidden by progress made by other teams
• designing the Sprint Backlog would take less time
• one Track Master (if applicable) per team can be in charge of the Backlog, as opposed to one person in charge of the entire project

Cons:

• more documents to manage, but responsibility is clear and one person is still in charge of no more than one
• document styles may diverge (not a big deal)
• when starting from the Product Backlog, it is more difficult to figure out where to look to see progress on a particular feature; this should not be much of a problem, considering that stories are usually clearly assigned to particular teams; it might help to add a column in the Product Backlog that gives the name of a team in charge of each story
• no synthetic view for PO & management; this might be the real difficulty. For example, in our case, management and customer have been sold on the idea of applying Scrum because it would make it easier to see progress during in the course of an iteration. This should be mitigated by the facts that

• a Sprint Backlog is made for the Pigs (the Team), not for the Chickens (management) or even the Product Owner; it is the team’s own tool, not anyone else’s

• it is probably not too hard to combine automatically the teams’ Sprint Backlogs into an overview document

All in all, it seems that the benefits are much higher than the disadvantages. So, what are you (& we) are waiting for?
Check out the complete discussion on that very subject in the Scrum Development mailing list.

Apparently, this is also expected by Ken Schwaber. This sounds quite contradictory to one the reasons for adopting Scrum, mentioned by Ken himself:

“Why should I be thinking about adopting Scrum? If you develop software and are unhappy with the turnover of staff[...] you should consider adopting Scrum.”

Well, as one can expect, the plan is that Scrum introduces disruption. Some people will leave, some will join, and hopefully the result will be a more stable team. This graph explains it better.

But that’s still hard to hear, isn’t it?

…not that I have noticed any difference so far. It happened 2 or 3 weeks ago, and I still have a single person to talk to in Scrum meetings, and nobody has identified themselves as part of a particular team.