Scrum basics: The process

As the start of my new series looking at the basic elements of Scrum, it seems best to start with the end … the end goal.  The end goal of Scrum is a team which is smoothly and effectively delivering business value on a regular basis.  Some will say that this is the goal of most, if not all, methodologies, but Scrum is the most effective in achieving this goal IMO.  As a developer, it is also the methodology which I have found to be the most fun!  But more on that later.

Now Scrum is really a pretty simple process to follow and there are a number of resources around on the web which can supply details.  What I’m going to try and delve into is not only the basic rules and mechanisms of the process, but I will give you advice from my experience on the things that do and don’t work.  As with all advice YMMV.  During the series we will be straying into human psychology, communication methods, testing methodologies, user-centred design and a number of other topics that may look unconnected, at first glance.

The basic parts of scrum are:

Some specific further topics which merit some discussion are:

  • Burndown charts
  • Taskboards
  • User stories
  • Team velocity
  • Release planning
  • Continuous integration
  • Variations on the estimation process

I’ll link from here to my posts, as they’re published.

August 17 2011

How would you like that developed, sir? Tactically or strategically?

Here’s a number of scenarios which I’ve seen played out repeatedly in different settings.  They all have a common root – see if you can spot it:

Business user: “Ever since you developers adopted agile you’re releases have been buggy!  Agile is rubbish!” Product Owner: “Great!  You’ve shown me exactly what I want!  Let’s launch tomorrow!”

Developer: “Oh no … it will take a least a month to get this ready for launch”
Product Owner: “That POC is spot on! Let’s start developing the next feature.”

Developer: “But it’s a POC … there’s a bunch of stuff we need to do to turn it into production-ready code.”
Project Manager: “The velocity of the team is far too low.  We should cut some of the useless unit testing stuff that you guys do.”


So what’s the common link?  Right … quality!  Or more specifically, different views around levels of quality.

Now in agile terms, quality is best represented in the definition of done.  This definition should codify exactly what you mean when you say “this story is done”, or “how long until it is done?”.  Scrum itself doesn’t provide any specific guidance around the definition of done, but says that it’s important the team agree this.

It’s important to note that the definition of done should not be specific to a given story.  So my story about bank transfers may have a number of acceptance criteria around how to debit and credit various accounts, but even if my code works I might not be done because I haven’t had my peer review yet.

With that all said, here is what I see is going wrong in the above scenarios:

The team have set their definition of done below the business user’s expectations (which are probably unstated) The team have set their definition of done below the product owner’s expectations - the product owner is expecting to include all release tasks The product owner doesn’t appreciate that there is a difference between POC code and code suitable for a long-term solution The project manager either doesn’t appreciate the benefits of unit tests, or thinks that the team have set their definition of done too high.


There are numerous good discussions and articles on the web about a definition of done (StackOverflow question, another question, an article, and another, and a HanselMinutes podcast), but I’d like to propose the idea that we should have some overall quality levels.  For instance, it doesn’t make sense to develop a strategic, long-term solution in the same way as a prototype.  So here’s what I propose as some overall quality levels:

  • Spike – Written to prove one single technical question.  Should never be extended unless that technical question needs to be explored further.
  • Prototype – Written as a quick-and-dirty demonstration of some functionality.  Can be used for on-going demonstrations, and so may need to be extended, but should never be deployed into production.
  • Tactical – Written to fulfil a specific, limited business requirement.  Life expectancy should be in the order of 2-3 years, after which it ought to be decommissioned and replaced.
  • Strategic – Written in response to on-going and continued business requirements.  Will be expected to evolve over time to meet changing business needs and emerging technologies.

And in terms of what I think these mean for a definition of done, here is my strawman (additional steps will most likely apply for a specific project, depending on the nature of the project):

Quality levels

So the next time you start a project, make up your own grid like this (or use this list, I don’t mind) and use it to have a detailed discussion with your product owner and scrum master.  It may surprise them to find that you are thinking about these issues, and their position on quality may well surprise you too!

The Mythical “Private Office”

Several years ago I read an interesting book dealing with, among other things, developers productivity: based on research done at  IBM’s Santa Teresa facility, the author suggested that the productivity of developers can be substantially higher than industry average provided that they have private offices. Apparently, if you allow developers to work in an environment which does not provide any distractions, they are able to crank more code. Fair enough. I have to admit here that I read the text several years ago, so I might have gotten some names wrong here, but the idea stuck with me (and some other people as well) for a long time: the private office was the holy grail of software development.

I see and hear similar ideas surfacing from time to time and what amazes me nowadays is the fact that people still believe that number of lines of code (commonly used measure of developers productivity) is indeed a valid metric. If so, how come we’re all not paid by the number of lines we produce each month?

People pay us to develop software, hoping that they will get more out of it when it is up and running. When evaluating software projects they are interested in the value the product can provide to their business, not in the lines of code cranked in order to produce it. And this leads to an interesting conclusion: the amount of code anyone writes per month is completely irrelevant, it’s the value they provide that matters.

In contrast to “private office” camp, one of the fundamental aspects of Agile development is co-location of team members: the team should occupy the same office space. I have to admit that initially I was a bit skeptical, wondering why are the prophets of Agile so insistent on entire teams (not only devs) working so close together. But if you were lucky enough to work on a properly run agile project, you must have witnessed first hand the continuous buzz of conversation between team members: people will bounce ideas of each other, testers will harass developers and vice versa, pairs will discuss or argue approaches to solving problems etc. Some will say that this is not the most productive environment, and surely it’s not, but only if  measure productivity by the amount of code cranked per man-month.

The “conversation-bus” allows team members to publish/subscribe on demand so they can “plug” themselves into any conversation at any time in order to either add something of value or get something out of it. This has two major effects: first of all it promotes knowledge sharing and secondly (and more importantly) it allows pretty much anyone to contribute and add “value”. If you ask me, this is far more important than time lost writing code as out of those tiny conversation a better solution will invariably emerge. So keep the conversation-bus up and running and for those rare moments when you want to be all on your own get yourself a pair of headphones.

On the other hand if you ever hear someone on your team saying  “oh no, this is not the way you do it, why didn’t you ask?”, or people generally complaining about “communication”, read between the lines: they are not complaining about communication, they are complaining that they were not involved in the decision making process and no amount of meetings, emails, approvals, committees, steering groups or similar “remedies” is going to change it. Deprive people of ability to contribute, lock them in cells (or private offices) and the net effect is sinking team morale as there is nothing more frustrating than seeing your teammates trying to reinvent the wheel and invariably ending up with a square. Trust me, I have seen it way too many times, very often through the window of my virtual “private office”.

September 9 2010

Sometimes bed is not an option


"What passed for society was a loud, giddy whirl of thieves and pretentious hustlers, a dull sideshow full of quacks and clowns and philistines with gimp mentalities."

Hunter S Thompson - The rum diaries

How many times do you hear that to do the right thing is “Not an option” because of your client engagement.

I sometimes suspect this is much more driven by fear of the Consultants engagement than by the actual need – Sometimes being unpopular is the only option. Let me illustrate a fairly common scenario for you.

You have a piece of work where the client hasn’t actually agreed to the tech and visual design yet, this piece of work may be quite important and needs to be done very soon and as a team you might really want to get it out of the way? – The correct response is to NOT do it until we have a consensus on what the functionality should do – Hold off it – drop it – The product owner may be unhappy in the short term but then it saves you generating waste willingly. The problem is you don’t actually know what they want so are you building it because;

You are arrogant enough to think you know your product owners business better than they do?

Or because you are in the “More haste less speed” camp of “How wrong can it be?” (See above)

Now this happens all the time but let’s take this situation out of its comfortable context and put it somewhere where it really shows its flaws.

You take your car to a mechanic (You are now the Product Owner and the mechanic is the team) and the mechanic states that there is some serious damage to your engine. He will likely be able to get away with re doing the head (£x) but thinks it is wise to replace the engine (£3x)

If you have a good quality late model car maybe the engine replacement makes sense

If it’s an older car you are considering replacing in a year or two most likely the head

If it is an old banger you will probably tell him to not bother and scrap it.

How do you think you are going to feel when you decide to tell him to scrap it, call him up, and he says “We got bored waiting so we put in a new engine. You owe us £1800”

I reckon you are going to be a little less than pleased.

June 8 2010
Newer Posts Older Posts