Agile Lego Game – Agile 2009

As I mentioned before, one of the best moments for me during Agile 2009 was helping Glenn Bernsohn present the Agile Lego Game workshop. The room was full, and we had 6 tables working on an Agile project to create Animal using Legos.

Here are some pictures from that presentation :

We had two largely different groups of people there: the beginners in Agile learning the basics, and the experienced coaches learning a new game to add to their arsenal. Based on the feedback received, the workshop was a success!

Scrum is evil because… (part 2)

This is the second (and last) poster about why Scrum is evil, created during an open spaces conversation at Agile 2009. The first part of this list can be found here, as well as a list of reasons why Scrum is good.

Scrum is Evil because (part 2):

Scrum Is Evil - 2

• Encourages to stop thinking about process
• Easy to become micromanagement
• Has a Scrum “master”
• Does not fight “the man”
• Turns great developers into whiners/(??) ?
• Easy to play blame game
• Threatens work of good coaches (enforced pyramid scheme)
• Creates process opportunity cost
• Alliance did not come here [to Agile 2009]!
• Dogmatic practitioners
• Hard to know if you’re doing it wrong
• Ambiguous / contains paradoxes
• “big bang” Scrum
• Too advanced for us
• Assumes responsibility (by developers)
• lip service to self organized team
• Focus on Scrum, rather than on product

I don’t think I agree with this list as much as I agree with the first one. Many of the items listed here are more related to bad use of Scrum than the methodology itself (focus on scrum rather than product, easy to become micromanagement, etc). While these problems may reflect the fact that the ScrumMaster training and certification has its own problems, to me its not really a problem with the framework.

Other items in this list have a lot to do with Scrum being used in the enterprise. Why do we have to fight the man? Why would good coaches be threatened by hierarchies? What makes it easy to play blame game? These items to me sound more like personal problems turned into anger with the process than anything else.

The one item in this list that I really like though is that its hard to know if you’re doing it wrong. While this can be true for any Agile methodology, Scrum can be specially vulnerable to this because its really hard to get metrics related to the process itself. There’s no list of items to check as you go along; there’s no numbers you can collect as you go along to check if everything is going well. Scrum depends immensely on the work of the ScrumMaster, and in his experience dealing with issues.

This is my last post in this series about Scrum from Agile 2009, but this topic has been discussed in detail quite a few times already. If you’re interested in more info about this, I specially enjoyed this thread on stack overflow, and this post from Eric Le Frevre. This article from Mike Cohn is also really good at listing a few common smells in your Scrum project.

Scrum is good because…

In my previous post, where I listed the first half of the reasons why Scrum is Evil created during an open spaces session at Agile 2009, I mentioned there was also a “Scrum is Good”  list. Here it is:

Scrum is good because:

Scrum Is Good Because...

• It is laying the growth for Kanban
• I can ship in only 90 days
• Opens people’s mind to Agility
• Its easier than XP
• Certified in only 2 days
• Train a lot of people quickly
• Escalates risk
• PMI implementing it
• its “Agile”
• Includes feedback loops
• Improves communication
• Simple framework
• Exposes remaining problems
• Appeals to execs
• Don’t need to change culture
• Get rich quick
• Impress developers

Many of the items above have more to do with Agile in general than Scrum, like improving communication, simple framework, and feedback loop, so the same could be said about XP, FDD, Lean, or any other Agile methodology.

For me, the main value in Scrum is related to adoption: Scrum has made it a lot easier for companies to adopt Agile methods:

• While many developers usually are not big fans of the Scrum certification, the business side usually loves it. Its a quick, proven way of getting people up to speed on the new process;
• having names for each meeting and artifact simplify communication by providing a common language;
• separation from technical practices means that adoption is quicker/easier, and with less friction with the development team (which I do not consider a good thing, but I do accept that it simplifies adoption).

What do you think? Is anything missing from the list above?

In the next few days I’ll be posting the final list of why Scrum is bad from the Agile 2009 conference.

Scrum is evil because… (part 1)

The last day of Agile 2009 was very different from the other days. Most people had already left the conference, but those few hundreds who stayed were presented with a really fun Open Spaces day, with many discussions and presentations going on at the same time. Remainders of previous presentations decorated the walls and tables all around as people walked all over trying to find the right discussion to participate.

One of those remainders was a list titled “SCRUM is Evil Because…” (picture below). I did not participate in creating the list,  but I’ve had this conversation with friends who are CSM and CSP many times in the past, and this list basically lists , so I took the pictures. I you did participate, please let me know, I would love to add your name here!

Here goes the first part of the list:

Scrum Is Evil Because:

Scrum Is Evil

• It won’t solve problems
• Ignores good code practices
• Ritual over principle
• Just a “buzzword” with no meaning
• Certification pyramid  scheme
• False sense of agility
• Constrains too much
• Process over people
• Strict roles
• Promises [things] it can’t keep
• Implies barrier between customer and team
• Commitment over collaboration
• 30 days is too long
• Does not include XP
• Language encourages non-sustainable pace
• ScrumButs are a bad thing
• Mandates “small[?? can't really understand the slide] status meeting

Now, before people start complaining, there was also a “SCRUM is Good Because…” list, which I’ll post up in the next few days. There was also, though, another list as big as this one with more “evil” stuff (that will come later as well).

I agree with most of the items in the list above, and my bet is that most experienced Agile coaches and team members probably also do so.  Many of the things in the list above, though, make it easier for people to move from waterfall processes to Agile, which ends up being a good thing.

The lack of technical practices (other than saying “high quality is important”) is probably the biggest problem I see in that list: the risk created by building incrementally without a clear understanding of the practices needed to maintain the real quality of the project can be as high as the old waterfall. I do understand that Scrum is a generic, non-software specific process, but I don’t think that is an excuse for not listing things like continuous inspection, automated testing and so on.

Agile 2009 Reflections

Last week I had the pleasure of attending Agile 2009, the largest conference about Agile software development in the world. Here are some of the highlights for me:

• The quality of the speakers was amazing. From Alistair Cockburn‘s keynote, to presentations from J.B. Rainsberger, James Shore, Brian Marick to David Hussman (winner of the pask award), this was the first conference that I’ve been to which I cannot name a single bad session I attended.
• Helping Glenn Bernsohn present the Agile Lego Game was a lot of fun. We had around 40 people in the room and, as usual, everybody enjoyed the game and learned a lot.
• The off-session conversations in the corridor with all thevery experienced coaches/developers was really a lot of fun. I can’t really put the names of all the people I’ve met here, but you know who you are!
• ~2000 lines of notes collected during these 5 days.
• The PMI institute participation in this year’s conference. Jesse Fewell‘s humble request for help from the Agile community to spread the word to PMI practicioneers was a mind opener for me.
• The high amount of User Experience (UX) presentations in this years conference confirms to me that I’m not the only one working on projects with high impedance between UI and Development.

I can only really name one bad thing from the conference: the fact the the wireless network was not working and AT&T had no signal make it simply impossible to have an online conversation with other members of the conference. The twitter screen was amazingly slow during the entire event.

Overall, the most important item in the event was not the location, or the food, or the presentations. It was all the really good people who was there and all the really good conversation hapenning all around. The Agile community really is passionate about its craft and full of smart and interesting people, and Agile 2009 demonstrated that one more time. Individuals and interactions: isn’t this what we value the most, after all?