Mark Needham

On the majority of the projects that I've worked on at ThoughtWorks we've held a showcase at the end of each iteration to show our client what we've been working on and finished over the previous one or two weeks.

The format of these showcases has been fairly similar each time but the people who attended has tended to vary depending on the situation.

As part of the project being worked on at ThoughtWorks University we've run a showcase at the end of each week which the whole team have been attending.

Toby pointed out that having everyone there didn't seem to be the best use of people's time since the majority of the developers in the room didn't actually have any input during the showcase.

I've often felt the same in that situation although we used a similar approach on a project I worked on last year and it seemed to be quite useful for addressing the human aspect of the project.

The client was able to meet all the people on the team and equally the developers were able to gain some insight into the types of conversations that the analysts were having with the client.

In that particular example we had around 10-15 developers so there was quite a big gathering but on the other projects where we've had the whole team at the showcase there's only been 3 or 4 of us.

On the last project I worked on we took it in turns to go to the showcase. I think it's quite useful to have at least one technical person in a showcase as they're able to give instant feedback on implementation details such as how difficult it will be to change the way a certain piece of functionality works.

A lot of the time we didn't have any input but it was interesting that quite often we'd come out of those showcases with more understanding of what the client was trying to achieve with a specific feature.

If we don't have all the developers in every showcase we do tend to have them all there for the first showcase at least as that tends to be the one where the most stakeholders will be present.

Overall though it's a call to make depending on the situation and the difficulty in judging the value of attending the showcase seems to come about because a lot of the benefits of attending are indirect whereas staying at our desk and coding has a direct benefit to the project.

I recently came across an interesting post about pair programming by Paritosh Ranjan where he outlines some of the problems he's experienced with this practice.

While some of the points that he raises are certainly valid I think they're more evidence of pair programming not being done in an effective way rather than a problem with the idea in itself.

To take one example:

Generally people don’t think a lot while pair programming as the person who wants to think about the pros and cons will be considered inefficient (as he will slow down the coding speed). So, generally people show fake confidence on the effectiveness of the proposed solution.

While it's certainly possible to end up with this scenario, I've also taken part in pairing sessions where we were able to think through a problem and come up with a design much more effectively than either of us would have been able to alone.

Something that I've noticed that I do too frequently is seeing a practice being executed in a sub optimal way and coming to the conclusion that there's a problem with the practice itself.

For example I wrote a post about a month ago outlining some of the problems that we'd been having with retrospectives on some of the projects that I've been working on and at one stage towards the beginning of the year I was wondering whether there was even a lot of value in having a retrospective.

What was pointed out in the comments of that post and subsequently on threads on our internal mailing list is that to keep people engaged we should vary the way we run the retrospective rather than running the same format every time.

I'm told Esther Derby and Diana Larsen's 'Agile Retrospectives' has a lot of ideas on how to run retrospectives more effectively but I haven't quite got around to reading it just yet.

Another practice which I've been doubting is the Iteration Kick Off meeting which often seems to be a session where we read through every single story that's coming up while the majority of the people in the room are completely disengaged. These meetings often dragged on for an hour or more.

Discussing this with a business analyst colleague last week he pointed out that he runs these meetings in a completely different way. His goal is to communicate what functionality is coming up so that any coding decisions can be made with that in mind.

That communication doesn't necessarily have to be in a meeting, it could just be a conversation had over lunch. If it is a meeting then he'd look to keep it short and to the point.

The underlying trend behind all of these is that we saw a practice being done in a sub optimal way and came to the conclusion that there must be a problem with the practice.

I'm coming to the conclusion that it would be more effective to look at the goal the practice is trying to achieve first and see if we can change the way we're executing the practice to achieve what we want.

If not then perhaps the practice is at fault and we need to look for another way to achieve our goal.

Ken Schwaber recently wrote a blog post where he compared the differences between the kanban, lean and scrum approaches to software development and although I haven't had the same experiences as he has with the first two, one interesting thing he implies is that with a scrum approach we have slack time built in.

God help us. People found ways to have slack in waterfall, to rest and be creative. With Lean and Kanban, those hiding places are removed. We now have a progressive death march without pause.

The project that I'm currently working on has switched emphasis from being in pure delivery mode into a combination of delivery and handover and it's been quite noticeable how much more slack we have in the system as a result.

I find it much more enjoyable when there's a bit of slack such that we're not churning out story after story.

It gives you the opportunity to explore the code base a bit more and try out any ideas that you have to see if they're likely to improve the productivity of the team.

An example of this on our project is that we've had the time to introduce a calculation descriptions DSL that my colleague Dermot had written in his own time.

This has helped reduce the number of tests required in certain areas of the code base as well as making the code more intuitive and therefore easy to understand.

It can be quite difficult to create this slack time when the team is under big deadline pressure and working on anything which isn't directly related to hitting that deadline isn't considered valuable.

I've noticed that the typical slack in the projects I've worked on tends to be towards the end of the day if we finish a story late on.

That tends to disappear if the team is working late and people start to become too tired to notice that there might be a better way to do things.

It seems to me that it would beneficial to try and work some slack time into projects to allow for the type of innovation that allows us to come up with ideas that allow us to be more productive.

I've previously written about the danger of using velocity as a goal but on almost every project I've worked on at some stage we do actually end up chasing a points total.

Something I find quite interesting towards the end of an iteration is that if there is a choice of two stories to pick up then the project manager will nearly always press for one which can be completed within the remaining time in order to get the points total for that iteration higher.

This might even mean that we pick something which is lower priority because we might not finish a higher priority but larger story in time.

This would mean that the points for that card would not be recognised until the next iteration which would mean that in the current iteration the points total would be lower than expected.

Most of the time this doesn't make a great amount of difference and if it helps take some pressure off and create an impression of 'success' then it seems a reasonable trade off to make.

It does still seem less than ideal to have that type of decision dictated by such a limited metric though.

Dermot pointed me to a blog post by Tim Ross titled 'Are burndowns evil?' where he discusses this in more detail and although I agree with the points Tim makes, it often seems that a product owner ends up with the impression that the project is 'failing' or that we are 'behind' if the velocity 'target' is not being met each iteration.

It seems to take product owners who are new to a more agile approach a bit of time to get used to the idea that achieving the points total isn't the most important thing to focus on and that it's more useful to focus on other things which actually give them value.

I've worked on projects where we've got to the stage where the points total is a side show but it takes quite a bit of time of consistently delivering before we can get that level of trust.

Grant Joung wrote a post a while ago about velocity goals and whether they're a good or bad idea, a topic which seems to come up from time to time on agile teams.

My colleague Danilo Sato previously wrote about the dangers of using velocity as a performance measure because it's something that's directly within our control and can therefore be gamed:

Value should be measured at the highest level possible, so that it doesn’t fall into one team’s (or individual’s) span of control. People tend to behave according to how they’re measured and if this metric is easy to game, it will be gamed.
…
Velocity doesn’t satisfy my criteria for a good performance measure. Quite the opposite, it’s a very easy metric to game

Danilo suggests that we should look to use metrics which are outside of our immediate control but which we can score high on if we focus on doing a good job. He cites the 'net promoter score' (that measures how much your custumer is willing to recommend you to a friend) as an example of this.

Dan North gave a really good presentation titled 'Our obsession with efficiency' where he covers similar ground and touches on the gaming of performance measures.

From my experience having velocity as a goal doesn't make any difference to the motivation of the team which is often cited as the reason for referring to it as a target.

In all the teams I've worked on people are giving their best effort anyway so they can only really have an impact on the velocity by doing one of the following:

1. Working longer hours
2. Cutting corners on quality (by less testing perhaps)
3. Finding a smarter way of working

With the 1st idea we now have an inaccurate representation of how much work we can actually complete in a given time period so our future planning is now made more difficult unless we insist that people work long hours all the time which is a recipe for disaster.

With the 2nd we will eventually suffer when there are more defects later on in our process and we have to come back and re-work those bits of the system.

The 3rd is good but then again I don't imagine that we would need to have a velocity goal in order to start doing that – we should be working smart by default.

I recently came across an interesting paper titled 'Goals gone wild' which suggests that goal setting can actually be detrimental and that we should be more careful about how we use them:

The use of goal setting can degrade employee performance, shift focus away from important but nonspecified goals, harm interpersonal relationships, corrode organizational culture, and motivate risky and unethical behaviors. We argue that, in many situations, the damaging effects of goal setting outweigh its benefits.

Setting velocity as a goal is a prime example of what the authors call a narrow goal:

With goals, people narrow their focus. This intense focus can blind peopleto important issues that appear unrelated to their goal

As Danilo points out what we really want to do is to get some features that our users want to use into production with as few defects as possible so that they actually work.

Our underlying goal might therefore be to make the lives of our users easier through their use of the website we're building.

This is much more difficult to measure which is perhaps why the number of points completed becomes the focus when in reality that's not what anyone cares about. It seems more to signify a lack of trust between the two parties.

In reality I haven't noticed that people on the teams I've worked on pay that much attention to whether velocity is considered a target or not. People just do their job and we pretty much always have the same velocity each week regardless.

My colleague J.K. has written an interesting blog post where he describes a slightly different approach that he's been taking to writing stories to help move the business value in a story towards the beginning of the description and avoid detailing a solution in the 'I want' section of the story.

To summarise, J.K.'s current approach involves moving from the traditional story format of:

As I...
I want.. 
So that...

To the following:

As I... 
I want..
By...

I quite like this idea and I've noticed that even without using this story format technical solutions are sometimes described as the business requirement and we need to look beyond the 'I want' section of the story card to find the real value and locate assumptions which have led to the story being written in that way.

To give a recent example, a colleague and I picked up the following story:

As the business
I want a HTTP module to be included on the old site
So that I can redirect a small percentage of traffic to the new site

We assumed that other options for redirecting traffic must have already been analysed and written off in order for this to be the suggested solution so we initially started looking at how to implement it.

After a bit of investigation it became clear that this was going to be quite an invasive solution to the problem and would involve re-testing of the whole old site (since we would be making a change there) before it could be put into production. That would take 2 weeks.

Speaking with Toni and Ashok about the problem it became clear that it should be possible to control whether traffic was going to the old or new site by changing the configuration in our load balancer, Netscaler.

Discussing this further we found out that this had been tried previously and hadn't quite worked out as expected which was why it hadn't been considered as an option.

We spent some time talking through using Netscaler with the network team and agreed to try it out on a performance environment and see whether it would balance traffic in the way that we wanted which it did.

We still need to make sure that it works as expected in production but it was an interesting example of how solutions can be excluded based on prior experience even though they might still be useful to us.

I'll certainly be more aware of noticing when a story details a solution and try and look for the actual requirement after this experience.

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!