Scrum-o-matic and the time box

“Scrum is an agile software development method for project management. It enables the creation of self-organizing teams by encouraging co-location of all team members, and verbal communication across all team members and disciplines that are involved in the project”

A key principle of Scrum is its recognition that fundamentally empirical challenges cannot be addressed successfully in a traditional predictive manner. As such, it adopts an empirical approach – accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team’s ability to deliver quickly and respond to emerging requirements

The Dad of Scrum (Scrum Daddy…?) reminded me the other day that “everything is happening in a time box”. He has a point. I agree, if you’re working on a product and some part is missing, then… it’s not finished, right?

I like this heavy handed approach to challenging a product and development team: So… only 95% of specifications are done…? It’s incomplete! So… almost all code is written but X or Y function is not tested…? Go back and test! So… you did not reach pass rate in acceptance testing…? WTF are you thinking! (You could go on like this for quite a few iterations and variations therein…).

And he’s right. If it’s not working, documented, tested, reliable, working (again, again, again…), usable (as in: has functions for end users) is understandable… then… It’s just maybe not there yet.

Go back and make it something that can be called a product!

So, with this, Scrum Daddy was hammering some software engineering teams at Google in an on-plex conference. I liked a lot the concept of deliver-ability associated to the whole Scrum thing: in the time box, which is finite, there is a clear deliverable: It’s something that is ready to go and make your company some $$$.

This immediately eliminates incremental crap: you cannot really sell crap (or let’s say dis-functional functional objects ;-) in a sustainable manner. But you can make cross functional teams of real veterans and thinkers in your company, to ensure that at the end of each sprint you have, infact, moved forward.

 

Some clear and resounding comments from Scrum Daddy remained:

1. Velocity under pressure = drop in quality (for the most part)
2. 12-14h days statistically = +60% defects (which, BTW, will double-to-triple the cost of defect management and almost certainly kill the ROI of the product)
3. Over 65% of functionalities delivered and maintained are rarely used (“if at all” amount to 15% of those)

So, now that I got it out of my system, let me just give you the briefing on what Scrum actually is (besides a way to re-start a game of rugby).

Here comes the official list of characteristics of Scrum:

A product backlog of prioritized work to be done

Completion of a fixed set of backlog items in a series of short iterations or sprints

A brief daily meeting or scrum, at which progress is explained, upcoming work is described and impediments are raised

A brief sprint planning session in which the backlog items for the sprint will be defined

A brief sprint retrospective, at which all team members reflect about the past sprint

Great! But who actually does all this? Scrum teams are divided into roles. There are a number of them, but basically 2 groups: Pigs and Chickens

Pigs are committed (as in: pigs are “ham”) to building software regularly and frequently, while everyone else are chickens (as in: chickens lay “eggs”) that are interested in the project but are really irrelevant because if it fails they’re not a pig, that is they weren’t the ones that committed to doing it, their legs will not be roasted! The needs, desires, ideas and influences of the chicken roles are taken into account, but not in any way letting it affect or distort or get in the way of the actual Scrum project.

If you need more detail on the roles which are encompassed by pigs or chickens in Scrum, get the overview to start thinking hyper-productively

Tags: agile development, hyper-productivity, pigs & chickens, schwaber, scrum, software