Mark Needham

I've spent most of my time working on agile software development teams over the last few years so for the most part each pair is only working on one story, keeping the work in progress low and allowing them to focus on that piece of work until it's completed.

My pair and I ended up in a therefore somewhat unusual situation last week where we were attempting to work on three things at the same time and weren't doing a particularly great job on any of them.

It wasn't immediately obvious to me that we were doing this since the two extra tasks that we were working on were related to deployment issues on different environments.

However we eventually started making mistakes and in rushing to rectify those made even more mistakes since we were still trying to concentrate on three different things.

It became much more obvious at this point that we needed to just pick one of the items and focus on that until we were done which also served as a reminder that it's good to use the story board as an indicator of what everyone is working on.

In this case two of the tasks we were working on weren't on the story board otherwise it would have been more obvious to the rest of the team that we shouldn't have been working on two of them.

I've never really noticed the problems of context switching before so it was interesting to get such a stark example to remind me of its dangers.

Something which an agile approach on a project typically gives us is the ability to change requirements rapidly based on the different types of feedback we typically get over the course of the project.

One way that we can lose this advantage is by getting caught up by the number of story points being completed and using this as the measure of success.

The flexibility to change has an impact on the number of story points that may be completed in a given iteration – if we start doing some work on a story and then get feedback from the business while it is still in progress it's possible that we will end up with more work to do than we had previously.

Once a story is estimated we don't typically go back and change that estimate unless there was a change in the assumptions being made before we play it. This means that any changes we make based on feedback would not result in re-estimation of the story card.

We now have more work to do without our measurement mechanism recognising that.

It gets even worse if we start working on a feature and then get feedback from the business that the feature is no longer useful to them and we should just stop working on it.

At this point a fairly common response is to 'lock down' the requirements so that we'll only work on the currently defined requirements and no new ones or changes will be permitted.

While this might make some logical sense it misses the point that we're supposed to try and deliver something that is actually useful rather than something which just meets the initial requirements.

In reality one of two things, or perhaps a combination of both, ends up happening:

• There will still be changes and all we've done is create the illusion that there won't be any.
• The business will now push to get exactly the features that were specified originally even if the development team ends up spending a disproportionate amount of time creating those features for the value they actually provide.

Story points are really useful for allowing us to get an idea of the relative size of stories and can be helpful for getting a rough understanding of the amount of work we can complete in a given time period but we need to be careful how we use them.

Our goal at the end of the day is to deliver working software.

Story points are just a mechanism for giving us some feedback on how well we are doing that. They're not the goal in itself.

I went to watch the latest ThoughtWorks Australia Quarterly Technology Briefing in Sydney on Wednesday where my colleague Lindy Stephens, Suncorp's Josh Melville and Lonely Planet's Nigel Dalton presented on 'Agile Governance – Managing the Enterprise Issues'.

I was actually unsure of how interesting it would be to me as the title seemed a bit dull but it was actually quite entertaining and not at all what I expected.

These are some of the things I picked up from the presentation:

• Lindy started out talking a bit about the illusion of control that waterfall plans can lead us to, referencing the intial paper on waterfall written by Winston Joyce which actually criticises the idea of designing everything up front and suggests an iterative approach would work better.

  A recent article by Tom De Marco where he retracts the idea that you "can't control what you don't measure" was also referenced. The most interesting part of this article for me is where he points out that projects which provide minimal return are the ones that need the most control but perhaps we should be considering whether we should even undertake them in the first place.

  The idea of having software that is production ready at any time is also a very nice thing to aim for:

  So, how do you manage a project without controlling it? Well, you manage the people and control the time and money. You say to your team leads, for example, “I have a finish date in mind, and I’m not even going to share it with you. When I come in one day and tell you the project will end in one week, you have to be ready to package up and deliver what you’ve got as the final product.

• Traditional measurements of progress derived from a more waterfall process actually only tell us if we're proceeding not if we're succeeding – it's much more useful to keep our focus on whether we are delivering value to the end user instead of just focusing on whether we have hit our targets on delivery date and promised scope.

  The transparency and visibility that we typically have when following a more agile approach was mentioned by a couple of the speakers – progress is much more visible throughout and we don't suddenly have a project going from status 'green' to status 'red' right at the end.

  I think we need to be a little bit careful that we explain things carefully when showing this types of data to people who are new to the agile approach as it can very easily give the impression that we are totally failing when actually it's fairly normal for initial progress on a project to be slower than it will be once we get going.

  Nigel Dalton described a story where even the Lonely Planet chef knew how one of his teams was doing because the information was so transparent!

• Nigel also spoke about the idea of outsourcing agile and suggested that the best way to ensure success with this is to work with people in a country on the same longitude so that the timezone difference isn't too great. He also suggested that having people from both locations going to the other works well for ensuring better communication.

  I went to a QTB last year where this was covered in more detail by my colleague Dharmarajan Sitaraman.

• The general idea behind what Nigel presented seemed to be that the individual teams effectively provided the governance of projects and that it wasn't necessary to have massive reports detailing progress every week.

  Josh Melville stressed the importance of looking at the value of all documents and getting rid of them if they don't provide anything useful. Nigel described how they had massively simplified one of their reports after listening to Josh's advice!

  Lindy pointed out that sometimes we'll be executing projects in an agile way in environments which more traditionally follow a waterfall methodology and that in this case it might be necessary for the project manager to spend some of their time converting the data into an appropriate report.

  In terms of the lean approach this seems to me to just be waste, but perhaps a necessary waste.

• Josh also talked about the importance of moving away from a process centric view of the world to a relationship based one when it comes to managing projects whereby problems could be talked through instead of just writing off a project as doomed because a 'checkpoint' wasn't reached.

  He also suggested that considering whether we delivered features and also whether they were actually used were more useful things to look at rather than looking at budget and time.

• In the questions afterwards one suggestion to the speakers was that the metaphor of software development as being similar to industrial manufacturing is not really helpful and that perhaps movie making is a better one to use because there is a level of creativity involved and the aim is to deliver something of value each day.

  Nigel pointed out that while traditional manufacturing didn't have much to teach us, lean manufacturing was a different story as it helps us cope with variation rather than just cost which is quite important in software development.

I attended the most recent ThoughtWorks Quarterly Technology briefing on Tuesday which was titled 'Agile Adoption – How to stuff it up' and presented by my colleagues Andy Marks and Martin Fowler.

There seems to be quite a few books out at the moment about how to introduce a more agile approach into your organisation – I've been reading Lean-Agile Software Development and Becoming Agile and there is also a book called Scaling Lean and Agile Development – so I was intrigued to see whether the messages from this talk would be similar to those in these books.

What did I learn?

• I often find when listening to Martin Fowler speak that although what he says is quite similar each time when speaking about agile there always seems to be something different that stands out for me each time.

  This time what stood out was his mention of the Dreyfus model with regards to people's level of skill when it comes to agile – when you first start out as a novice it's quite hard to keep the principles in mind so you spend a lot of time focusing on the practices and getting better at these but if you want to keep improving then at some stage you need to move up to a level where the principles do become more predominant.

• Andy made an interesting point that IT and in particular software development is pretty much made for people who want to learn new things and he also pointed out the myth that 'learning finishes at school'. I never really considered this before but for me it definitely applies – the process of learning new ideas appeals far more to me than the results and outcomes of projects so it was interesting to hear this coming from someone else.
• Transparency with regards to bad news was something else which was pointed out as being fairly important and it's certainly an area where we often run into trouble – often organisations aren't used to bad news being delivered to them early and they get the impression that if it's going badly now then it's going to keep on going badly, rather than seeing that it's quite good to get bad news early because then you have time to fix it.
• Martin described the 'pilot project anti pattern' which he has come across where organisations make use of agile on a project which noone really cares about and use it as a training ground. It was suggested that this is not an effective way of introducing an an agile approach as it doesn't matter to anyone so there's no incentive to work out whether the new approach is really beneficial or not.
• I liked the question that Andy posed about success and failure. He first of all asked anyone in the room who had seen an email from their CEO talking about a really successful project and congratulating the team to put their hands up. Pretty much the whole room did.

  He then asked who had received an email from their CEO talking about a failure and the lessons learned from that and only one person's hand went up!

  Andy is definitely right when he suggests that "if you're not failing you're not learning anything" and this is something which I've also come across from Andy Hunt in Pragmatic Learning and Thinking and more recently I'm trying to get into the 'improvement ravine' with regards to learning F# as I'm still writing object oriented F# which I think is missing the point a bit. Thinking in a more functional way is the key for me there.

• A question was raised about how agile can fit in with fixed price projects at the end where it was pointed out that if the price and the time are fixed then the scope has to be variable – it can be infinitely flexible. It's actually often the case that a lot of value can be delivered with reduced scope even though it doesn't seem that way when you're told that all three of them are fixed!

Chris Johnston has another interesting post in which he writes about the practice of re-estimating cards after they have been completed.

I think this somewhat misses the point that the estimate is indeed supposed to be an estimate. It might turn out to be too optimistic or too pessimistic, the theory being that overall we will end up with a reasonable balance that will allow us to make a prediction on how much work we believe we can complete in a certain time period.

I've always seen estimates of story cards to be a relative thing – on all the teams I've worked on after initial cards have been estimated we've looked at the difficulty of upcoming cards and tried to score them relative to the ones already estimated.

Re-estimating cards (presumably) individually means that you lose the benefits of this approach and end up with a fairly meaningless value.

We are also ignoring the inherent uncertainty involved in estimating if we do so afterwards and I don't really see it helping us that much for future predictions since there is still going to be uncertainty with regards to the implementation of future cards no matter what we try to do.

If data needs to be collected after a card has been played then I would say the time it took to complete a card might be a more useful metric although there are more than likely going to be some cards that take longer than expected and some that take less than expected, so I'm not sure what extra value this data would provide.

As Chris points out if there are times, when we come to play a card or just after we start work on it, when we realise that some of our assumptions are incorrect therefore meaning that the estimate is inaccurate.

In this case I think it's reasonable to talk through the new assumptions and re-estimate the card so that we have a more accurate estimation of its difficulty.

When trying to work out how much work we can do in a certain time box, averaging the data we have from the original estimates is likely to provide the most accurate prediction in my opinion.

Apart from times when we have story cards overflowing from one iteration to the next, meaning that we end up with one high scoring and then one low scoring iteration, I have found on my projects that the amount of work points wise doesn't tend to vary very much which lends credence to the theory that the estimates eventually balance out.

My colleague Chris Johnston wrote recently about his experiences in agile software development, posing some questions that he has.

Specifically:

• Why comments are evil?
• Why design is evil?
• Why must you pair all the time?
• Why Agile principles become Agile rules?

Now I'm assuming that most (if not all) of Chris' experiences with agile have been at ThoughtWorks, in which case the mix of agile we use on our projects tends to be a combination of Scrum and Extreme Programming.

The last question seems the most logical to start with:

Why is it that for many people and many shops, Agile principles become rules and the only way to do things? I have met people and worked in shops were they have Agile all figured out and any deviation is heresy. If you are doing Agile this one way, then you are unprofessional and a very bad programming.

I'm with Chris on this one – as far as I understand agile is all about adapting a set of principles to the environment that we find ourself in. It's unlikely that the exact same approach will work in two different projects.

I've worked on 6 or 7 projects at ThoughtWorks and each has taken a slightly different approach to agile, varying the amount of process we use, the amount and type of tracking done, the approach to gathering requirements, and so on.

Our client's wishes, the availability of the business, the number of integration points, the size of the team, are all things that will influence the approach that we end up taking.

Why must you pair all the time?

Extreme Programming (XP) defines a set of practices that we can use on an agile project although there are certainly other approaches that are equally valid.

Pair Programming is one of the XP practices rather than something you need to do in order to be 'agile'.

I've worked on teams where we haven't paired, teams where some people on the team pair and teams where everyone does pair all the time but I wouldn't say as a rule people have to pair all the time.

When a team is responsible for the delivery of some software pair programming is the best approach that I have worked with for ensuring that people on the team have a good understanding of all areas of the code base.

While someone working alone in 'flow' might be able to write some brilliant code, noone else on the team knows anything about that code meaning that the knowledge of the implementation takes longer to work its way to the rest of the team.

Why design is evil?

I don't think design is evil and again all the teams I've worked on have done some design work up front, it would be fairly foolish not to.

Finding the balance between over architecting up front and doing just enough design to allow us to keep moving forward is the key here.

Why comments are evil?

I've previously written about the dangers of commenting code so I don't want to revisit that too much, suffice to say that it it usually possible to describe what you want to in a comment using an appropriate method name instead.

My experience with comments is that they go out of date more quickly than code does and therefore can end up being misleading to someone reading the code.

The only real time I have seen a valid use for them is when used to describe a problem the code is getting around where the explanation is fairly verbose and can't be expressed easily in code – for example, when using one of the jQuery validators there was some strange behaviour with regards to the behaviour of the plugin when different options were set.

For a while we didn't put a comment and others in the team would change the code not realising that it would cause a problem.

With the comment in place people have a better context before they make a change.

One of the inevitabilities of most projects is that at some stage there is going to need be some sort of integration.

The likes of Alistair Cockburn in Crystal Clear and Andy Hunt/Dave Thomas in The Pragmatic Programmer talk of the need to do integration early rather than letting it wait until later, but why?

Get the pain out the way

To some degree every time we try to integrate there is going to be some level of pain – for me it therefore makes sense that we take this pain early on when we have the chance to do something about it rather than leaving it until later and being surprised at the problems it causes.

We never really know that the system actually works as expected until it is fully integrated, and integration inevitably leads to situations which we didn't know existed previously.

The potential problem we need to be careful about here is that we still deliver features with business value while doing our early integration otherwise we end up with the problem that we seem to be delivering absolutely nothing.

Code can be more example driven

When we integrate later on one problem we face is that we have to try and assume what the integration will be like rather than actually knowing.

While it is possible to somewhat isolate ourselves from other systems, at some stage we need to integrate and this can typically lead to different data flowing through, in a different format than expected and we need to handle these differences.

If we integrate late we are putting ourselves into a guessing game of what we think we are going to integrate against and this leads us down the path of assumption driven development.

This inevitably leads to us coding for some situations which won't actually happen when we are integrated and missing out some situations which we didn't actually know could happen until we integrated.

Less inventory

In lean terms inventory is a product or part of a product which is basically in a state of waiting – either waiting for something to be done to it or waiting for a customer to buy it.

I think we can find a similar analogy in terms of story cards where a part of that story is to integrate with another system for example.

When we do the integration work needed later on the additional problem we face is that we naturally lose some knowledge in the time that the story is sitting waiting.

In addition there is also wasted time as people regain the context of how the integration fits into the overall functionality of the story.

One of the cool features in build servers like Cruise and Team City is the ability to create build pipelines.

I have done a bit of work using this feature in previous projects but the key driver for doing so there was to create a chain of producers/consumers (producing and consuming artifacts) eventually resulting in a manual step to put the application into a testing environment.

While this is certainly a good reason to create a build pipeline, a colleague pointed out an equally useful way of using this feature to split the build into separate steps pipelined together.

By doing this we get a nice graphical display from the cruise dashboard which allows us to see where the build is failing, therefore pointing out where we need to direct our focus.

One way to use the pipelines is to work out the distinct potential areas where you would want to signal that something needs to be investigated and then make each of these targets a separate build target.

For example we could set it up like so:

No dependency build =>
Services build =>
End to End smoke test build =>
Full build

Benefits of this approach

The benefit of this approach is that it helps to create more confidence in the build process.

When we have a long running build it is easy to get into a state where it is failing after 3/4 of the build has run and all we get is the red failed build to indicate something has gone wrong. We can drill down to find out where the failure is but it's not as obvious.

The approach we have taken to checking in is that it is fine to do as long as the first stage of the build is green. This has worked reasonably well so far and failure further down stream has been fixed relatively quickly.

Things to watch for

We have setup the final step of the build to be a manual step due to the fact that it takes quite a long time to run and we've been unable to get a dedicated machine to run an agent on. Ideally we would have it running constantly on its own agent.

This isn't run as frequently as when we had it running automatically and I guess the danger is that we are pushing problems further down stream rather than catching them early. Hopefully this issue will be solved if we can get a dedicated agent running this build.

We're still looking for ways to improve our build process but this is what's currently working for reasonably well for us at the moment. It would be interesting to hear what others are doing.

I've worked on a few different agile projects and one of the things that hasn't been completely consistent is when we consider a story to be 'done'.

There seem to a few different approaches, each of which has its benefits and drawbacks.

Why do we care?

We care about 'done' for tracking the points we have achieved in an iteration and for knowing when we have added the value the story provides. For this post I'm interested in 'done' in terms of when we count the story towards our points total.

Business proxy signoff

With this approach we count a story as done when it has been signed of by a business proxy, typically a client business analyst or maybe a combination of a BA/QA.

The benefit of this approach is that we have normally have better access to a BA meaning that we don't end up having stories piled up waiting to be signed off as being done.

I have seen 2 mini approaches, both of which require a story walk through with the BA/QA:

• Acceptance tests pass => Done
• Acceptance tests pass + exploratory testing satisfactory => Done

With the first approach any bugs beyond the acceptance criteria will be tracked as bugs whereas with the latter the story will be moved back and just considered incomplete.

The disadvantage of either of these approaches is that we are counting something as done before it's actually been signed off by the business, which means that we might have a false sense of the value we're delivering. If the business proxies are communicating regularly with the business though I don't think it's necessarily a problem.

Business signoff

With this approach we only count a story as done when it has been signed off by our business stakeholder.

The benefit is that when a story is classified as done we have actually delivered something that is acceptable to the business.

On the other hand, when using this approach it's fairly important to have access to the business stakeholder on a regular basis if the velocity of the team is to be measured accurately. When we don't have this access we can end up with a backlog of stories waiting for sign off, all the while lengthening the time from when it was last worked on to when it is eventually considered complete.

In production

This is an approach which I haven't seen used on a project but which I read across in a post written by David Laribee.

I can see how this makes sense as we haven't actually delivered any value to our customer until the software is actually being used.

I think the difficulty of using this approach would be if we aren't releasing code into production regularly – we wouldn't get feedback on how we're progressing and therefore would have more difficulty noticing when things in our process aren't working as well as we'd hope.

In Summary

I think the further down the process we consider a story as done the more accurately our points total represents the value added to the customer.

Although we can get quicker 'points feedback' by classifying done earlier in our process, the accuracy of what that points total actually means is perhaps lowered.

I'm not sure which approach is the best one because each has its benefits and drawbacks. It will be interesting to see whether there are any further variations on what is considered 'done' on future projects I work on.

I am aware that I may be asking completely the wrong question and what we should be asking is 'Does it matter when it's done other than for reasons of tracking velocity?'

I came across an interesting article written for Visual Studio Magazine about agile methodologies where the author makes what I consider to be some misconceptions.

The first is around the level of experience of people working on an agile team:

For example, agile teams have a tendency to require a high level of experience and professionalism just to join the team.

I wouldn't say I have a high level of experience and I've been working on agile teams for the past two years, just one data point suggesting that this statement is not actually accurate.

I think it is important to have experienced team members, at the Journeyman or Master level to use the lingo of Software Craftsmanship, but I don't think you'd want your team to be completely filled with these types of people.

This is one of the things that is pointed out in Pragmatic Learning and Thinking referring to the Dreyfus Model definition of expert in this case. We need to have people of differing levels of experience if we are to create a successful team.

Ideally you want a mix of skills on a team: having an all-expert team is fraught with its own difficulties; you need some people to worry about the trees while everyone is pondering the forest.

This is referring to the fact that as people become more competent they tend to start focussing more on the big picture than they did when they just started learning. As the authors point out, it's useful to have some people on the team who just want to focus on the details and get things done.

Of course I'm sure there are examples of 'dream teams' of software developers who have worked successfully together, but maybe this is more the exception than the rule.

The second point the author raises whether agile is just about making developers comfortable by allowing them to write more code:

Finally, I wonder how much of agile development exists simply to make developers more comfortable. Most developers love to write code, and agile does a pretty good job of rationalizing why developers don't need to do anything else. Design? Code it with test-driven development. Requirements gathering? I've heard proponents of agile development say that the user doesn't know what they want until they see something, so you might as well get straight to coding.

It is fair to say that when working in an agile way we get to the code more quickly than when following some other approaches but surely that's a good thing?

Although certainly some part of design is best done at the whiteboard, we can't actually know whether our designs are going to work unless we put them in the code so I don't see design by TDD being a problem.

There is a need to do some requirements gathering before we start working on features/stories but quite often we don't find out about constraints and trade offs until we begin implementing a feature, at which time the customer can decide what approach they want us to take. The goal here is to try and provide them quick feedback so that what we develop is actually what they want.

I would encourage the author to go and see an agile team at work (maybe using the Patterns and Practices team at Microsoft as an example) and see whether he believes this points still hold true.