XP Days Germany 2010: Scrum Norris

At the XP Days Germany 2010 I presented a Pecha Kucha about Scrum Norris, initially a blog post merely collecting Chuck Norris for Agile software development initiated by some of my colleagues from it-agile. Here is the translated transcription of that talk with the pictures included as well. As I missed to mention this during my talk, take this write-up as an over-sketched situation, and see if you can find Chuck Norris in your project as well. Oh, and take it with humor if you find out that you’re Chuck Norris in your project.

Check Norris, the hero of many action movies and deified idol on the internet, is able to do anything. Anything! But Chuck Norris is also able to develop software. This wouldn’t be dramatic, if it wasn’t for Agile Software development valuing teamwork. Let’s take a look how Chuck Norris develops Agile software.

Chuck Norris pairs alone. Chuck Norris slides the keyboard to himself at Ping-Pong-Programming; and he develops code and tests faster than the usual developer can take on. How comes?

That’s simple, Chuck Norris’ unit tests are green before Chuck Norris has written a single line of production code. That’s not caused by Chuck Norris writing the most simplistic tests. Quite contrary.

But that’s not enough, since Chuck Norris’ tests are never failing. Facing Chuck Norris there is nothing failing. Really nothing!

Chuck Norris also doesn’t need mocks and stubs, or even TestDoubles (as if Chuck Norris needs a double). The code knows that it doesn’t have a chance against Chuck Norris, and does exactly what Chuck wants it to do.

Beyond that Chuck Norris does not need refactoring. Chuck looks at the big ball of mud as long as it needs to reveal its intention to Chuck.

Documentation? What’s that? Chuck Norris does not need documentation with all these practices – the code reveals its intention, tests pass all the time, and so forth – documentation becomes superfluous anyways.

Churk Norris does not practice Collective Code Ownership. Having Chuck Norris on your team there is just Chuck Norris Code Ownership… and dare you, if you touch it!

Of course, Chuck Norris not only influences the code basis, but he also coins the meeting culture significsntly. For example Chuck Norris does not move Stories during the daily standup meeting – instead he moves the taskboard.

Chuck Norris starts each iteration with a round-house kick-off meeting. By then every project participant knows directly what’s up – or who’s up (Chuck).

Also Chuck Norris’ velocity is unlimited. Therefore he’s able to develop any project in any arbitrary time-frame.

Even the daily stand-up meeting is contaminated by Chuck. Chuck Norris sits at the stand-up meeting. This reveals quickly who’s got the biggest voice during the daily coordination.

Beyond this, Chuck Norris just answers two questions. Chuck Noriss doesn’t know about obstacles. Therefore the ScrumMaster becomes without work rather quickly.

Within every Scrum Team Chuck Norris is the ScrumMaster anyways. Chuck Norris is also the Product Owner – who else could dictate the quality? This is possible, since Chuck Norris is ScrumMaster and Product Owner in one person.

Since Chuck Norris doesn’t need acceptance test – either Chuck accepts, or not – the Iteration Demonstration or Sprint Review becomes obsolete as well.

Since Chuck Norris is the ultimate acceptance tests, Chuck’s customers conform to his opinion. Who would dare to contradict Chuck?

Chuck Norris’ iteration do not need any retrospective. (No tree-hugging for Chuck!) There is nothing to improve at Chuck’s process, and if something doesn’t turn out well, Chuck will be dealing with it personally!

The only true “Burn-Down” charts in Scrum are the ones from Chuck Norris. Even the fire department knows this!

Burning down the charts does not affect the project in any sense. Chuck Norris uses Gantt-Charts even in Scrum. This works very well since the only dependencies in a project with Chuck Norris depend upon Chuck directly.