Some say that this is what the Scrum master is there for, however, I’ve noticed that this is something that the Scrum master doesn’t get to do much of as they are are often dealing with external pressures “to get things done”…

On many teams, once I move on, there is a coaching void. Despite my pleas and efforts to encourage them to at least establish a coach from someone in-house, the team is often left to just get on with it.

This isn’t a new idea. For example, Extreme Programming highlights “the coach” as a key role in the team.

In sports, teams have coaches. Have you ever heard of a professional sports team without a coach? Can you imagine a professional sports team hiring a coach for a while and then saying – “we think we’re ready to compete on our own now so thanks for your help but you’re not needed anymore”. No, I don’t think so. This is unheard of in competitive sports, yet all too common in competitive business.

Even my 12 year old son’s basketball team, the Islington Panthers, has a coach. He trains them 2-3 times per week and he (or an acting coach from the seniors) attends all of their games. In some training sessions he gets a member of the under 21s team to coach the under 13s training session – so there is always a coach even if they’re just borrowed from another of the club’s teams. Without him, do you think any of the club’s teams would make the national play-offs as they regularly do? Very unlikely.

So, competitive sports teams always have a coach. Temporary coaching in a professional sports team is almost unheard of… Sure, they could get by but would they be taken seriously? Would they be competitive? Would they save money by not having a coach or would this be an obvious false economy? What are their chances of generating sponsorship revenue if they are not winning games? What are their chances of winning games without a coach?

The same applies in software teams. For example, I worked with a client recently and helped a team of 6 people double their output in one day. They’d have to hire another 7-10 people in order to achieve that but instead, one good coach was enough.

So, if you have a professional software team without a coach, consider, are you really helping your business save money by going it alone? Or, like the professional sports team, is having a professional development team without a coach another example of a false economy.

Recently, I wrote about my views on using and estimating with task-cards. I highlighted that tracking progress with burn-up/down charts showing effort completed/remaining is not a true measure of progress, especially if we subscribe to the idea that we measure progress with working-software.

I also highlighted how tasks “horizontally slice” a “vertically sliced” story.

This inspired an article on infoq by Mark Levison. Since its publication, there have been several comments.

There are some specific points I’ll be answering on infoq, but some general points are more easily answered here…

True measures of progress
One of the key points I was trying to make in my first post (linked to above) is that if “working software” is our measure of progress then tracking task completion is not consistent with that.

One of the problems task-hours are trying to solve is to provide a visible indication of progress. It’s also something that many people find easier to understand. The idea of relative-points estimation seems to baffle many people when they first encounter it.

In my original post (linked above) I referenced an approach, blogged about by Jason Gorman, outlining a solution to providing a visible indication of progress that is compatible with the idea of measuring progress with working software. It also works more seamlessly with the solution of measuring throughput trends of the team (e.g. with story points) so that the team can estimate how much can be done in the next iteration.

Value Points & Task Points
Value points were mentioned in the infoq comments. Value points are solving a different problem and don’t help the team estimate what can be done. The value of a story isn’t an indication of its complexity. Value, combined with complexity points, can help determine priorities. Arlo Belshey explains some interesting views on this.

Prioritisation is, in my view, one of the few reasons to place some sort of estimate on value & complexity. Unfortunately, it seems to be often used to establish a contract with the team for when something will be done and apply pressure when the estimates turn out to be inaccurate.

Non-estimating pull systems
My preference is to use such estimates only for prioritisation… after that, things just take as long as they take. There is some benefit in tracking accuracy trends so that we can learn from them, however, spending too much time on these things simply slows down the process of getting things done. Interestingly, I have not yet seen the business be quite so passionate about evaluating whether their value estimates were accurate when the product makes it to the real world. Funny that.

Instead, I prefer to leave estimation behind once we’ve prioritised things and pull stories or customer valued work items through the system without using previous estimates to predict their completion date. With the way that most budgets are determined and allocated, this idea isn’t compatible with the way much of the business world works. For pull systems that eliminate estimation as a means of predicting the future to work (such as Kanban), we need a more adaptive approach to budgetary spend. Business needs to find a way to adapt budget allocation more frequently, perhaps as frequently as monthly, perhaps more frequently still. The business now needs to look at how it can respond to change rather than focus on following a budget-plan.

Business-world: now it’s your turn
Budget holders now need to be more agile. We, those who evolve the implementation of the ideas of the business, have responded to their demands to be able to respond to rapidly changing markets and provide that competitive edge. For the more mature implementation teams, the hindrance now is no longer how we make the products, but the business culture of inflexible and predictive budget allocation.

Others have talked about the virtues of stories as vertical slices of a problem (end-to-end capabilities) rather than horizontal slices (system layers or components). So, if we slice the problem with user stories, how do we slice the user-stories themselves?

If, as I sometimes say, acceptance tests (a.k.a. examples/scenarios/acceptance-criteria) are the knife with which we slice a story into even thinner vertical slices, then I would say my observation of ‘tasks’ is that they are used as the knife used to cut a story into horizontal slices. This feels wrong…

Sometimes I also wonder, hasn’t anyone else noticed that the idea of counting the effort of completed tasks on burn-down/up charts is counter to the value that we measure progress only with working software? Surely it makes more sense to measure progress with passing tests (or “checks” – whichever you prefer).

These are two of the reasons I’ve never felt very comfortable with tasks, because:

• they’re often applied in such a way that the story is sliced horizontally
• they encourage measuring progress in a less meaningful way than working software

Tasks are, however, very useful for teams at first. Just like anything else we learn how to do, learning how to do it on paper can often help us then discard the paper and do the workings in our heads. However, what I’ve noticed is that most teams I’ve worked with continue to write and estimate tasks long after the practice is useful or relevant to them.

For example, there comes a time for many teams where tasks become repetitive. “Add x to the Model”, “Change View”… and so on. Is this adding value to the process or are you just doing it because the process says you should do it?

Simply finding that your tasks are repetitive doesn’t mean the team is ready to stop using them. There is another important ingredient, meaningful acceptance criteria (scenarios / acceptance-tests / examples).

I often see stories with acceptance criteria such as:

• Must have a link to save the profile
• Must have a drop down to select business sector
• Business sector must be mandatory
• …

Although these are “acceptance criteria” they aren’t what we mean by acceptance criteria in the context of user stories. Firstly, they are talking about how the user interacts rather than what they need to achieve (I’ve talked about this before). Secondly, they aren’t examples. What we want are the variations that alter the behaviour or response of the product:

• Should create a new profile
• Profile cannot be saved with blank “business sector”

As our product fulfils each of these criteria, we are making progress. Jason Gorman illustrates one way of approaching this.

So, if you are using tasks, consider an alternative approach. First, look at your acceptance criteria, make sure they are more like examples and less like instructions. Once that’s achieved, consider slicing each criterion (or scenario) horizontally with the tasks rather than the story. Pretty soon, you’ll find that you don’t need tasks anymore and you can simply measure progress in terms of the new capabilities you add to your product.

There are, IMHO, some good reasons and some bad reasons to consider switching from Scrum to Kanban… or for considering Kanban over Scrum as a starting point for ‘going Agile’ (so to speak)…

‘Good’ reasons for considering Kanban are…

• Wanting/needing more visibility of specific development process constraints (bottlenecks) than Scrum gives you (Scrum shouts “there’s a problem!”, Kanban points at where the problem is)
• Kanban can avoid waste of stories not filling a Scrum sprint (although finishing ‘early’ can allow teams to make improvements they might not otherwise have afforded themselves)
• Kanban can focus teams on vertical stories from the outset whereas new Scrum teams seem to start with horizontal slicing.

‘Bad’ reasons to choose Kanban over Scrum are…

• Wanting to say you are “Agile” without really changing your development process
• Because using Scrum is exposing rigidity and brittleness of software that is the output of your development process and wanting to hide that behind Kanban words like cadence
• Hiding impact of speculative design behind Kanban work-items when it fails in Scrum because the work never seems to fit into a Sprint, spilling the story over multiple sprints

(by speculative designs I mean implementing architecture that is more than is necessary for current valued-work-item)

For a team that has legacy development practices, producing legacy code for which it simply isn’t realistic to do incremental and iterative development but wants gradual and continuous improvement… I think Kanban is perhaps a better place to start. Your first ‘work-item’ may take 3 months… but it’s an honest 3 months! The trick is to make continuous improvements to gradually increase the tempo of your delivery.

If a team needs to suffer the pain – that comes from seeing that no matter how hard you try you simply can’t fit the implementation of even the smallest feature into one month – before it realises it has a problem… Then maybe Scrum is the better place to start.

Whichever you choose, I hope you choose the right approach for you, for the right reasons

In a previous rant about the misuse of the term mitigate in the context of risk management I listed the following strategies (I call them MARTA) for managing a given risk:

• Mitigate – Reduce the severity of its impact
• Avoid – Don’t do the thing that makes the risk possible
• Reduce – Make the risk less likely to happen
• Transfer – Move the impact of the problem to another party (e.g. insure such as paid insurance or outsource with penalties for failure)
• Accept – Do nothing or set aside budget to cope with the impact

I recently found myself having to explain this and used the analogy of crossing a busy road with fast-moving cars. What’s the risk? Well, you might get hit by a car.

This will probably be more useful if you take a moment to think of a busy road with fast moving traffic that you know of and then use each of the above strategies to identify different ways of managing the risk. What factors would be significant in deciding on which strategy (or combination of strategies) was the way to go?

Ok, now that you’ve had a chance to think about it, here is what I came up with:

• Mitigate – Walk down the street until I can find a section of the road where there is a 20mph speed restriction. (This is mitigation because I’m not necessarily making it any less likely that I’m hit, but if I am hit the ‘impact’ is reduced – i.e. I’ll probably live – albeit with injury).
• Avoid – I could simply not cross the street, by deciding that whatever is on the other side simply isn’t that important or I could use an underground subway (which of course has other risks associated with it depending on the area you’re in).
• Reduce – Find a stretch of road where there are fewer cars – reducing the probability of being hit by a car.
• Transfer – Get someone else to cross the street, maybe someone more skilled at crossing the road than me.
• Accept – Now, if it was a busy street, I wouldn’t ‘accept’ the risk. But, if the road allowed for lots of visibility and there were very few cars and there were speed bumps slowing the traffic down to 10mph then I might just accept the risk.

The person I explained this to found this to be a useful exercise in understanding my views on risk management – beyond mitigation. Hope you find this way of explaining it useful too.