Ricardo Mestre’s Blog

It’s a known fact that even though Scrum is a simple methodology, its simple concepts are frequently misunderstood. So, let’s mix the aforementioned quest for a software productivity measurement with those misconceptions around Scrum, and what do you get? Answer: the use of Velocity as a productivity measurement.

Using a single number (like Velocity) as a measurement of a team is plain wrong for several reasons:

1 - It’s very easily cheatable - inflate your estimates in story points, add water and… voilà: higher Velocity.

2 - For starters, Velocity doesn’t ever tries to measure productivity. Velocity is an agile planning tool! It tells us, as a team, how many story points we can “burndown”, on average during a sprint. Therefore, it helps the team to get an idea of what they can commit (roughly) on a Sprint Planning. So, let’s use Velocity for it was intended: to help us plan.

In my opinion, this focus on measuring productivity is misplaced. Let’s use that energy in measuring return of investment, on post-controlling the projects we delivered - in short, in analysing the true results of our finished product… instead of obsessing over an abstract number.

If you parachuting from a plane, you can cut the strings to the parachute in order to go faster - but will you get the desired results in the end?

If you are used to work in the command and control way that is implicitly imposed by futurology-based predictive processes, such as Waterfall, Scrum might look (at first site) like a “The Captain is Out to Lunch and the Sailors Have Taken Over the Ship(*)”-process. It’s the team members that attribute tasks to themselves? Whoa, what a chaos!

Not really. Remember that using Scrum means that the team is self-organized and (hopefully) autonomous. In order for a team to be self-organized, it takes a lot of discipline!

Let’s look at some examples - it takes discipline to:

• be at time everyday for the daily scrum meeting
• update, at the end of all working days, the estimated time remaining to complete the tasks you were working at
• concentrate on finishing the task you have in your hands, instead of starting 6 different tasks (and then finishing none, in the end)
• don’t interrupt co-workers when the are reporting their status during the scrum daily meeting

.. and that’s just for starters.

It takes a lot more discipline to work in a Scrum team, than to work in a command and control environment: on the later, you just do what you have been told to.

—————————————————
(*)winking at Mr. Bukowski

Boris Gloger this (on his blog) about the role of a Scrum Master.

“That [struggling] is the measurement if you do it right. If it is easy you are failing in doing the job right. Changing the work behavior of a team, an organization or even a whole enterprise is not a piece of cake. It is terrible hard work.”

Exactly! And I must add: if you think that filling the role of Scrum Master will win you a popularity contest… think again.
So, only bad news in this post? Not really: if you’re doing right, nothing beats the feeling of “fighting the good fight”.
Have a nice weekend, everybody!

As promised to Cairo, here are the criteria I recommend for a Team to split user stories. Please take into account that none of this was invented by me: I’ve been following the criteria mentioned by Mike Cohn in his great book “Agile Estimating and Planning” - which is a must-have for anyone using Scrum.
So, after the proper attribution, here go the criteria:

When to split:

• A user story must be split when it is too large to fit within a single iteration. And why is that? Because it makes no sense that the Team commits (during the sprint planning) to a user story that it knows, beforehand, it will impossible to finish (according to the Team’s definition of “done”) during the sprint duration. That would be commiting to do the impossible, which must be avoided.

• When a user story is small enough to fit within a sprint, but it won’t fit within the sprint being planned because there isn’t room left. Again, this must be done in order to prevent over-commitment.

• It can be useful to split a large user stroy (an “epic”), if a more accurate estimate is needed. Why? Because we, humans, are much better estimators when we are estimating within the same order of magnitude.

How to split:

• Split a large user story along the boundaries of the data supported by the story. For example, the user story “As a user, I want to be able to enter my personal information” would be splittable into several small user stories, like “As a user, I want to be able to insert my name” and “As a user, I want to be able to insert my birthday” and “As a user, I want to be able to insert my phone number”

• Split a large user story based on the operations that are performed within the story. A good way to do this is split the story along the proverbial CRUD (Create, Read, Update, Delete) operations.

• Remove cross-cutting concerns (such a security, logging, error handling, etc.) and creating two versions of the story: one with and one without support for those cross-cutting concerns.

• Split a large user story by separating the functional and nonfunctional aspects into separate small user stories.

• Split a large user story in small stories, if those small user stories have mixed business priorities.

Hope it helps. Oh, and go get the book: it’s that good!

• Interesting post from Nathan Jamin, regarding Retrospectives in Distributed Scrum Teams
• Another interesting post from McLean (via Nathan Jamin), regarding Retrospectives

A real life example, during a work interview:

“Me: So, Scrum is an empirical method of managing projects.
xpto: So, it’s something random, right?”

Way wrong. There is a huge difference between: random and empirical.
Let’s start with the first one: the empirical method which is in the base of Scrum is not random - far from it. If you prefer, substitute the term “empirical” by “adaptative” - because that’s what’s done in continuous feedback cycles in Scrum: Inspect, Adapt, Do, Repeat, etc.
In Scrum, you have 3 cycles of feedback:
- every 24 hours, at the Scrum Daily Meeting
- every Sprint (2 to 4 weeks, in average), at the Sprint Review
- every Release (several Sprints)

So, it’s far from random. In fact, is much more reliable than the Waterfall methodology. Waterfall is a predicitive model - i.e., you pretend you have a magic crystal ball, in which you predict everything which is going to happen during the project(!). That sounds a lot more like random wishful thinking, IMHO.

To sum it up, in Scrum, you have an empirical/adaptive methodology instead of a predicitive one.

I’ve got another interesting question from Artur Martins:

“Which books I need to read in order to know how Scrum works?”

Nowadays, there are tons of books regarding Scrum. When I started to get some information regarding Scrum, I did a very common mistake: try to get my hands in all books I could manage to. Is that useful? Not really.

IMHO, the best thing to do is read the book that started it all: “Agile Software Development with SCRUM”, by Ken Schwaber and Mike Beedle. Some approaches stated in the book are a little dated nowadays, but it’s still the best place to start.

Then, if possible, get a CSM (Certified Scrum Master) course: I can recommend you the services of Boris Gloger - not cheap, mind you, but for sure he delivers!

Next step? Three next steps, in fact: Practice, Practice, Practice.

Only after that you’ll reap benefits from reading other books about Scrum, which deal with specific parts of applying Scrum.

So, how went the workshop at Barcamp Portugal ‘08? Great, thanks to a fantastic audience, which hanged tough for almost 4 hours(!) - it seems that my inital estimate was really way off :).

My big Thanks! to all the participants - it was a pleasure to be with you! Now I just have to recover my voice.

Please feel free to download the slides from the workshop here: scrum101

Next step after Hamburg? Well, really close to home - I’ll be giving a talk/presentation in Coimbra, Portugal, on the 3rd Edition of Barcamp. Curious about what is a Barcamp? Take a look here. The event is organized by those tireless guys at WeBreakStuff, whose work and “can-do” attitude I admire.

About the talk: it’s an overview of Scrum (what else?), with an estimated duration of one hour and a half - and it’s prepared for a maximum of 40 participants. And, of course, it’s free, as everything in Barcamps is.

Interested? Drop me a line, if that’s the case.

I’ve got a good question from Cairo Noleto, regarding Scrum, which I’ll answer here:

“In Scrum, a Team is always mapped in only one project. Is it possible to manage several projects with a single Team? That’s something that happens quite a lot in the real world, specially in small organizations. How does Scrum deals with it?” - Cairo Noleto, Add4 Comunicação, Brazil

One thing which is crucial in a correct Scrum adoption is to avoid (and that’s a part of the Scrum Master job) that the team is interrupted during the duration of a Sprint. If the Team members have their effort splitted over several projects, then their concentration will be interrupted and cut off several times per day!
For a Scrum approach, the right thing to do is change from a team such as:

Team A: 8 members, working in projects P1, P2 and P3

…to, for instance….

Team A: 3 members, working in project P1
Team B: 3 members, working in project P2
Team C: 3 members, working in project P3

More questions? Feel free to ask, to ricardomestre at fastmail dot fm.