Agile

Beware Backlog Tunnel Vision

pauliomLeave a comment

Many Agile techniques rely on a backlog of items to work upon. Ideally everyone would know all the items that are in the backlog, but practically this is not always possible. A typically process is to have a handful of team members groom the backlog to prioritise the order the items. The very real danger is that when a team starts working on an item they do not have a holistic picture of the backlog. Without acknowledging (rather than needing to fully understand) the future requirements the team risk making choices that will need to be redone.

The Tour Bus Example

One of my favourite Agile examples is the Band Tour Bus. A band has struck it big overnight and they need to go on tour quickly, so they need a tour bus. A waterfall model would dictate that all the requirements for the bus are fully specified, costed, prototyped, etc. When the bus is ready everyone’s forgotten about the band and many new groups have replaced them. There is no money to pay for the bus – sad times. Enter Agile, a backlog of all the features for the bus are created and it’s deemed that a basic bus will be delivered first. Hurray the band make it to their first gig, granted not in style, but they get there. Now, let’s say that part of the bands master plan requires a long tour and they need to take their families. The occupancy requirement goes from 4 to 12. Upon grooming the backlog it is decided that feature will be done 6 sprints into the development. However, the development team haven’t been told and create a lovely in-bus bathroom. Sprint 6 arrives and there is no real-estate to create the additional living quarters, disaster. How can we avoid this problem?

How to clear the blinkers

As with most things in Agile the simple solutions are often the best;

a) Grooming team review the start of the work. The grooming team have the facts, they should review the start of work to ensure there are no obvious clashes or dependencies on items in the backlog

b) Items are categorised to allow all team members to quickly search for potential dependencies. When a new item is examined the team run a quick search over the backlog.

Whilst (b) is a useful mechanism, especially for longer running projects (e.g. products) where the grooming team changes, I would always recommend at least (a). If your team only considers the narrow view of the next Sprint or the next set of work items then the project will be at a real risk of expensive re-writes.

Why TFS Online Task board is Anti-Agile

pauliomLeave a comment

I like Visual Studio, and I like a number of things about Visual Studio Online (VSO). However, there is one part of VSO that I think I very dangerous and can easily put your Agile project at risk. What is this terrible evil? Well I’m guessing you’ve read the title so it will be of no surprise when I say, the Scrum Work Item Task Board (see https://msdn.microsoft.com/en-us/Library/vs/alm/Work/scrum/task-board?f=255&MSPPError=-2147217396).

My experience of this task board is that it leads to a complete disintegration of the Agile practice. But it looks fine, how can such an innocent artefact lead to such problems? A number of Agile practices rely on a set of key overlapping points; 1. Transparency of the work 2. Collaboration and trust 3. Exiting with completed work. When you work on an Agile solution you will have a group of people with a set of specific skills, or at least wear the hat of a specific skill. Let’s assume we have a project owner, tester and developer. I firmly believe these are the minimum roles, even if you chose to only employ one person for all of them.

When you use a non-electronic task board you will, typically, go though a process that encourages collaboration. A note representing the ‘task’ will be placed on the board and those involved will discuss the issues around it. At first the team will agree what will be delivered and, crucially, how you prove that it has been successful. A common strategy here will be that at least the owner and test team will be responsibly for delivering an automated acceptance test for the task. The development team will be involved but perhaps not so hands-on, their main interest is to ensure the task is available for them work on. I.e. it is in the developers interest to track the progress of the owner/test team. Next the roles switch, the developers will implement the task to meet the acceptance criteria. The owner/test team play a lesser role but now they are interested in ensuring that the progress of the development is kept on track. Once development finish the owner/test team will then give the final yes/no on the result. Even without a Limited Work In Progress (WIP) strategy the team are always aware of the progress of the task and that it is their collective responsibility to collaboratively complete the task. Various process methods are used to help re-enforce this but the majority come down to a simple level of communication and, importantly, participation. So back to the topic, what is the problem with the VSO (Scrum) task board?

The first problem is that VSO wants you to separate out responsibility by creating a task per person. So rather than a task move through the team members hands, each person has their own task. Now when the team meet up each person has their own, pardon the overused term, story to tell. As their individual tasks progress it is an unfortunate human trait that the teams interest in individuals tasks wanes. Worse still, when a task completes in simply finishes and is really only of interest to that person. One task finishing does not trigger the start of another. What we have now is a system that purports to be agile but is really just a system crying out for a Gantt chart.  This is not VSOs problem per se. The task board is based, or bolted onto, old Team Foundation Server (TFS) non-agile templates. I.e. the agile processes, in this case Scrum, has be coerced onto a platform that doesn’t really support it. Happily the VSO team have working hard and have recently allowed more customisations that may offer a way out. Also this blog has been focused solely on VSOs Scrum process, you could choose Kanban instead. Whatever you choose, you should consider what are the human ramifications. Also try to keep the team, as a whole, focused on the progress of the work. It is everyone’s responsibility to deliver the work, that only ends when it is delivered. Ok, even that’s not strictly true, but lets keep those worms in the tin for now.

Be very careful of VSO Work Items, don’t be fooled into thinking you have an out-of-the-box agile process. Or just don’t use Scrum…

Burndown charts and 2 week Sprints, what’s the point?

pauliom1 Comment

I’ll be honest, I much prefer burn-up to burn-down charts. However, for some reason the tooling to support these is horribly lacking so I often find myself being presented with a well meaning burndown chart.

A burndown chart is there to show an estimate of how likely a team will deliver a block of work in an amount of time. A Sprint is there to provide a focused deliver of a block of work. The two often go together, and this is where I start to have an issue with them. When software delivery described an early delivery as 6 months it was very important to attempt to track if the development was on schedule. In order for a burndown chart to help with this the team needs to spend a certain amount of time recording what they’ve done and re-estimating what they have left to do. When Sprints first became popular a 4-6 week time-box was not unusual. This still represented an expensive period to fail in, so tracking was still important. Today a 2 week Sprint is very popular, if you fail then it’s not nice but lessons will have been learnt and you have only ‘lost’ 2 weeks. So is it necessary to track the progress of such a short time period? If you get to the end of the first week and your burndown trend isn’t on track, what are you going to do about it? To maintain the burndown chart the team have to expend time to keep the estimates updated. This doesn’t represent a trivial amount of time from a 2 week period. So…what is the point of a burndown chart for a 2 week Sprint? In my view you will be better off simply recording the outcome of the Sprint in terms of delivered items and save the effort on re-estimating and daily report production.

Myths of Agile

pauliomLeave a comment

This is a post I’ve promised to write for a while, this isn’t a critic of ‘Agile’ in any of its guises but simply a guide to avoid incorrect statements.

Before I dive into this, let’s just remind ourselves of the Agile Manifesto;

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more

Sprints therefore I’m Agile

A Sprint is essentially a time-box, nothing more nothing less. How the time-box is used depends on the team’s implementation. I’ve seen Sprints used to simply slice up months of development. Whilst I suspect that this practice is not uncommon I think most people would recognise a Sprint from definition popularised by the Agile strategy, getting close to process, of Scrum. Here a Sprint is typically used to create a small deliverable. There are many good reasons for this; quick feedback, leave in a deliverable state, focused priority based development, etc. However, a Sprint neither makes a development Agile nor it is necessary to be Agile. I say again, Sprint != Agile and Agile does not need Sprints.

Velocity will lead to predictable delivery

Another concept popularised by Scrum is that of a team’s Velocity. By attaching a notional cost to each item we deliver we can measure how long (or fast) a team takes to deliver them. Once we have the teams Velocity then we make better predictions about future deliveries. Once again I’m not going to judge the merits, or otherwise, of Velocity but I would like to point out the assumptions;

Velocity measurement is more accurate when you;

a) Retain the same team from Sprint to Sprint

b) The uncertainty/complexity of the tasks remains constant

When the team changes then Velocity becomes very suspect. How significant the change is will depend on the team changes but you need to be aware that it will affect the measurement.

Uncertainty/Complexity have always been the bugbear of software development and it is still true when using Velocity. Consider the concepts of Cynefin (taken from the excellent summary Agile Development and Retrospective Coherence)

clip_image001

Velocity is more useful when the tasks are in the ‘Order’ domains. These are the tasks that we fully understand regardless of if they are easy or complicated to implement. However, anything outside of that becomes an unknown. I.e. if your last Sprint was Ordered then you will have a velocity of O, but if your next Sprint in Complex then you are likely to have a very different velocity of C. This means that for the third Sprint your Velocity is (?)… O, C, O+C/2, etc. We cannot even say that all complex Sprints are always C. If you consciously look out for Complex tasks then you can mitigate them by converting them, as much as possible, to the Order domain via non-deliverable Spikes. In this strategy you honour the goal of velocity in the sense of knowing what will be soon be started, but not necessarily about stating how much you can deliver for any given future milestone.

Be warned, Velocity can be useful but it can also be very misleading. If you do choose to measure velocity then use it wisely.

Burn-down charts accurately show the state of the project

Another popular mechanism with Agile development is the Burn Down Chart. The premise is simple, start the graph with showing the amount of work to be done, and as the work is completed the graph will tend towards zero, i.e. the development has completed. However, in my experience this rarely shows an accurate view of the development. The problem is that teams do not stick with the items in a Sprint. Often other items creep in, be it additional features or bugs. Nothing wrong this, after-all we should be expecting change (not wishing to start a discussion about using the size of Sprint to mitigate this). The problem is that it is now very difficult to discern from old or new work. If the burn-down chart is a flat line is that telling you that you haven’t completed any work or that the input of work has matched the output? Whilst I’m struggling not to criticize Burn-Down charts it would remise not to mention Burn-Up charts that provide the same information but can also resolve this confusion. See Pawel Brodzinski’s excellent review of the issues.

Scrum or Kanban

This post has mentioned Scrum a few times, and there can be no denying its popularity with Agile devotees. Another popular strategy is that of Kanban. I have read a number of conversations that take the form of Scrum vs. Kanban and offer them up as a polar choice. Essentially Kanban is about assessing your current process and smoothing it out. If your current process, oh dear I’ve said process, is Scrum then you can apply Kanban to it. It’s not one or the other. In reality, if your development suits Kanban then over a period of re-assessment then you may find that many of the Scrum stages are also causing your bottlenecks and you will end up dissolving some of them, including Sprints. However, again that is not the conclusion of using Kanban, it is one possible outcome. It all depends on what best suits your particular issues.

 

Summary

I’ve had these conversations a number of times, so I hope other people will find it useful. When something is Agile, look back to the manifesto and evaluate the rationale. If it doesn’t help you with those goals then challenge why you should be using it.