Agile

For the last few months I’ve been wading through Factory Physics. That might sound very negative but actually this book is highly recommended. The reason its difficult to read is nothing to do with the writing – which is actually quite easy going – but more down to the size and the maths. It is over 600 pages long and was originally written as a text book so can be a little tedious at times. Add in a bunch of mathematical proofs – essential – which even if you skim can be hard going and you get the picture.

That said its a great book to read with lots of important facts and implications. I have been reading it because I had some loose ends. The operations management module in my MBA all those years gave lots of suggestions and advice but left me wanting to know more. I finally found what I was looking for in Factory Physics. (Specifically queuing, variation and optimisation, but that will wait for another post.)

Now, to get back to the title of this blog post.

Every so often I come across managers who liken their software development teams to factories. They talk about the “software factory” or what happens “in the engine room.”

I think this analogy shows a fundamental misunderstanding of what goes on in software development groups. The idea that you can liken the development of software to a factory line process, with repeatable inputs, defined outputs, known processes, and repeatable activities just isn’t the case.

The difference shouldn’t need pointing but I will: as commonly understood the factory production line repeats again and again, it constructs one (or a limited number of) product(s) many times. There is little innovation or problem solving in the process (as commonly understood).

Whereas, software development constructs one product, for the first time ever; entailing a lot of innovation and problem solving in the first place; and never constructs it again. (After the first time a simply digital copy suffices.)

Now, having digested a lot of Factory Physics there is another reason I dislike this metaphor. Now I have a better understanding of the complications of making a factory efficient it is clear to me that making a factory effective is damn hard work.

Software managers who like to think of their development group as a “software factory” not only have no real understanding of the development process, neither do they have an understanding of how to organise and manage a real factory producing physical things.

In fact, one of the arguments in Factory Physics is that most factory managers don’t have such an understanding either. The authors argue, convincingly, that a lot of factory organisation and management is fashion, or fad driven and not based on a good understanding or science principles.

So I suppose in that way it is like managing software development.

Now before anyone rushes recommend, or attack, Fredrick Taylor and the ideas of Scientific Management the authors of Factory Physics are clear. Yes we should apply scientific thinking to management but, they point out, Fredrick Taylor was not scientific. His studies – from a scientific point of view – do not stand up. They are full of holes.

Just in case I’ve not been clear, lets repeat:

1. It is a mistake to think of software development as a factory line process.
2. Anyone who insists on using the metaphor should find out what is actually involved in running a factory.
3. There are insights from running a factory – to be found in Factory Physics – which apply to software development and many people will benefit from learning them. That doesn’t mean you should run your software development process like a factory though.

In the software development world there are, broadly speaking, two groups of people: those who create the software (coders, testers, etc.) and those who manage the process (project managers, development managers, etc.). When discussing “Agile” I find that both sides think the problem is with the other.

To put it another way, if I’m talking to developers they think its managers who are the block to adopting more Agile techniques. But when I’m talking to managers they say its the developers who resist Agile.

This always reminds me of the old Philip Crosby quote:

“Quality has much in common with sex. Everyone is for it. (Under certain conditions of, course.) Everyone feels they understand it. (Even though they wouldn’t want to explain it.) Everyone thinks execution is only a matter of following natural inclinations. (After all, we do get along somehow.) And, of course, most people feel that all problems in these areas are caused by other people.”

(OK, so this blog just got filtered out of lots of feeds and stopped by lots of firewalls but lets continue.)

Lets bring it up to date and make it Agile specific, substitute the work ‘Agile’ for ‘Quality’:

“Agile has much in common with sex. Everyone is for it. (Under certain conditions of, course.) Everyone feels they understand it. (Even though they wouldn’t want to explain it.) Everyone thinks execution is only a matter of following natural inclinations. (After all, we do get along somehow.) And, of course, most people feel that all problems in these areas are caused by other people.”

OK, this isn’t news, this study came out a couple of years ago and was covered by many people then. But, I find myself regularly referring to it trying to find the link. So I’m going to blog about it then I’ll always be able to find the link.

The study is by Nagappan, Maximilien, Bhat and Williams and is entitled: Realizing quality improvement through test driven

development: results and experiences of four industrial

teams and is freely downloadable from Microsoft.

This is the key findings are summarised in this table:

Team / Metric	IBM drivers	Microsoft Windows	MS MSN	MS Visual Studio
Defect density of comparable team not using TDD	W	X	Y	Z
Defect density of team using TDD	0.61W	0.38X	0.24Y	0.09Z
Increase in time taken because of TDD	15-20%	25-25%	15%	25-20%

The way to read this is: the researches looked at two Microsoft MSN teams, one team did not use TDD and had a defect density of Y. The second MSN team had a defect density less than a quarter of Y but took 15% longer.

To my mind that proves that which was to be proven, i.e. TDD reduced bugs. But, I’m also aware that other writers have disputed this and I’ve heard of studies which disprove it. (Anyone got a link? Thanks)

Most people who I’ve met, and who have practices, or understand TDD agree it is effective. However there are those who don’t believe it. It reminds me of the episode of Black Adder where Rowan Atkinson’s Black Adder hires a ship Captained by Tom Baker. When there is a problem it plays out like this:

Black Adder: “Someone in the crew will know… you do have a crew don’t you?”

Captain: “Arh, opinion is divided on the subject… all the other captains say you need a crew, and I say You Don’t”

At the end of the day Confirmation Bias will probably decide which set of results you choose to believe.

Once in a while I run across individuals, or even teams, who still think Agile is about just getting on and doing it. Well it is, good for them, but, that doesn’t mean there isn’t a reason for doing it.

There seems to be a myth in some circles that work done using Agile techniques doesn’t require a business case. Lets get this clear: Agile does not excuse you from having a business case for your work.

Of course there are instances were a business case might not exist. Some companies, for better or worse, work without them; those companies aiming at innovation may allow work to proceed to a more advanced stage before asking for some rationale; and products which are in a steady state may just tick over without too much attention to a business case.

But in each one of these cases the lack of a business case has nothing to do with Agile. (Actually, each of the cases does have a business case, its either a tacit business case or a part of a much bigger business case.)

Many development efforts which lack a visible business case can benefit from demanding a business case. If you are not sure why your company is doing some piece of work then maybe the company needs to be clearer about the reasoning.

However, a business case might look a little different on a Agile project. It may well be shorter than a traditional business case, it may lack some of the detail traditionally found in a business case, and it may describe much more a trial-and-error approach.

What Agile projects don’t need are in-depth business plans. Here its a question of detail, a strategic business plan makes plenty of sense. But a business plan which lists many many features to be build and a detailed schedule of when they will be built is little more than an illusion. Such plans give the appearance of certainty but certainly don’t provide it. Indeed, too many plans can actively hinder a project – plans are not benign, they are dangerous. (See An alternative view of design (and planning) for more discussion here.)

That said, there is a very good case for writing a business plan – indeed most forms of plans actually: they are rehearsal time for the real thing. They help you explore and learn about the thing you want to build.

Still, sometime you might skip the business plan. Maybe there isn’t time for a rehearsal, and sometimes learning can be maximised but just getting stuck in .

But, if you do write one, then once that exercise is over, once you start doing it for real, don’t try and hold yourself to a plan. Put the plan in the draw and don’t look at it. The value of planning is not the plan you produce at the end of planning; the value it is the knowledge you acquire in your head.

For that reason you want to maximise the number of people involved in the planning rehearsal so you can maximise the learning.

I’m sitting on a train from York so it seems a good time to share my train-leaving-the-station metaphor with the world. In truth, if you’ve worked with me in the last few years, or heard me speak at a conference I may already have shared it with you. But for the rest of the world, and with full embellishments….

Traditional software projects are like a train leaving the station. There is a big train sitting at Platform 9, we know its due to leave soon, but, well, you know what big long distance trains are like, it may well leave a little bit late. Still, to get a seat we need to be early so we are all rushing to the train.

Since we don’t know when the next train to this destination will go – actually, it is far from certain there will ever be another train – we want to be sure everything we need is on board. So we make sure we put everything we might need on the train. (Think of our requirements document.)

Eventually the train lumbers out of the station, overloaded. Quite possibly it leaves late because we were so busy loading the train, maybe one or two people even argued with the guard to delay departure a little bit so we could get more people and things on the train.

The train – our project – is like one of those trains you see in pictures of the Indian rail network with people crowded on and hanging out of the doors.

We all know the train is overloaded, we all know its going to arrive late, we even think it might miss the destination and arrive someplace else. But nobody wants to admit this.

(Particularly true if you have American management and British engineers because the Yanks view the Brits as being overly negative.)

At some point, beyond the half way mark it can no longer be denied that the train will arrive late. So action is taken. Things are thrown off the train to make it go faster.

By throwing things off the train we hope the train will arrive closer to the scheduled arrival time and the intended destination. However, in so much as there was rationale for putting all the things on the train there is less rationale applied to removing them. Things are thrown off the moving train because we can. (Somethings we can’t throw off because they are too connected to other things.)

In the extreme, those who put things on the train, and really know what is needed for the destination (BAs, Product Managers, etc.) never actually got on the train. Once they put the bits on the train they handed over responsibility to Project Managers to get it delivered. These guys are primarily concerned with dates and since they charged with delivering everything they don’t want to throw anything off.

Eventually, the train lumbers into the final stop – which may, or may not, be the intended destinations – with some random collection of things on board. Everyone gets off and breaths a big sigh of relief. Thank God that is over.

Then the news comes: there will be another train. We begin again.

This time though, we have all been burnt. We are going to make sure we have everything we need on the train, plus all the things we threw off the last train, and some more besides because we now understand the need for bargaining and we need levers.

Thats the traditional view. Now for the Agile view.

Instead of big trains we have a metro system – think of London tube, or better still Glasgow’s Clockwork Orange.

I leave the office at 6pm, go to the tube station and wait for a train. The sign tells me there will be one in 2 minutes, and another 2 minutes after that, and so on.

The train arrives and it is full. I have an option: Do I get on the packed, sweaty train and have an uncomfortable journey? Or do I wait 2 minutes for the next one?

I choose to wait. And while I’m waiting my phone rings. Some friends are in a pub nearby and ask if I would like a drink. I have an option: do I go and have a nice beer (valuable) with friends? Or do I value getting home more?

I go for the beer, something I would never do if there was only one train today. But knowing there will be another train, and another train, and another, means that I can go to the pub safe in the knowledge that I will still get home.

Need I say is? We need software development to be like the metro/tube system and not like the big occasional train.

There is a piece by me on todaysInfoQ – The Limits of Agile.

I’m interested to here your comments.

By way of wrapping up my velocity mini-series (Two ways to fill and iteration, Filling an iteration too well, and Velocity Targeting and Velocity Inflation) I’m going to end with some advice on how to improve a team’s velocity.

Bad news first: there are no silver bullets, there are no easy answers, there is no quick way of doing this.

There is no big fix, there are many, many, thousands, of little fixes which cumulatively add up. Each little fix improve your productivity (velocity) a little bit. Over time these add up to big improvements.

To use economic logic: this is about improving the supply-side. The supply-side argument (largely monetarist) suggests the way to solve unemployment is not to increase demand (Keynes style) but to loosen and liberalise the labour market. There is no single action which can do this, instead there are many small changes that need to be made to make the labour market more flexible.

But back to software…. how might you improve you velocity?

Well, Things to do to improve code quality is a good list to start with. Improving code quality makes teams more productive because they spend less time wading through swamp and scratching their heads.

Of these the thing that comes closed to a silver bullet is: Test Driven Development. TDD is something of a silver bullet, it does improve things BUT (big BUT) it takes time to learn to do it properly. Expect to take time, don’t expect it to happen over night, spend the time and money on training, coaching, setting up a continuous integration server and such. It will pay back, sooner than you think.

How on the heals of TDD is refactoring. In fact the two go together.

Adopting TDD and pursuing refactoring may throw up another problem which people would rather keep quiet about: developer skills levels. Some developers just don’t have the mastery of their tools required. A friend of mine who does TDD coaching tells me it usually ends up as OO coaching more than TDD coaching. So, invest in developer training, buy them books, send them on courses, bring in coaches, set up book study groups and other exchanges were developers can learn to do things better.

I would avoid adding more people to a team. We know, from Brooks Law, that at least the short run that will slow things down. But you can give existing people more time to actually do work. Try reducing the number of meetings you hold. If you have a regular planning meeting and daily stand-up meetings there shouldn’t be a lot of other meetings you need. Certainly there should be very few “all team” meetings.

And if your stand-up meetings are taking more than 15 minutes a day then look to shorten them. Any size team should be able to complete a meeting in 15 minutes if you approach it in the right way – see Three Ways to Run a Stand-Up meeting.

I often meet teams who feel that two weeks is too short a time to do anything useful, and they often question that frequency takes up too much meeting time. Rather than length an iteration it is better to shorten iterations. Teams get to review work in progress and take corrective action more often. There is less time for changes to disrupt planned work. It is good practice at both fitting work in short periods and at making planning meeting more effective.

In time, when you are good at iteration planning I might lengthen them, but it is rare I would let iteration last more than two weeks.

Next get serious about removing impediments. Too many teams live with impediment, accept them as a fact of life, something they can’t do anything about. Each impediment (or block if you prefer that name) reduces velocity a bit. If you want a higher velocity fix your impediments.

I don’t need to say it but I will: retrospectives. Do them, and action the ideas that come out of them.

Finally, just: Concentrate on doing a better job and the velocity, productivity and points will follow. The numbers are there to provide feedback, show you are going in the right direction. Don’t worry about the actual numbers, just keep improving.

Continuing my mini-series on filling an iteration, velocity and all that I want to flag up a big big mistake: Velocity Targeting. Which leads to Velocity Inflation.

Velocity targeting happens when someone says: “We did 15 points last iteration, lets aim for 20 this iteration”. And when the team fails to meet 20 they say something like: “What happened? We didn’t meet our target?” – or perhaps they start assuming that because the target is 20 the can adjust the plans and message to stakeholders accordingly.

We can all fall into this trap: its called Hope. We hope for a better world. When it gets dangerous is when the person issuing such statements is in some position of authority, e.g. the word “manager” or “leader” is in their title, and they start issuing communications with the target as reality.

Given a few iterations the team will meet the target. However the means they use to meet the target may not be what is expected. And these may well create problems later on.

For example, the team might skip on testing or skip on refactoring. This results in a short term speed up which sacrifices long term maintainability and flexibility. You might actually choose to do this, with the agreement of the authority person, but this should be a conscious decision and you accept the long term slow down.

A more subtle but systematic problem is Velocity Inflation. In this case the team start giving larger estimates, so when work is done the amount done is greater, so velocity rises. The same amount of work is done but the point value is higher. (This can be a conscious or sub-conscious thing, I expect it is more often sub-conscious.)

In some ways this too is natural. Team members want to appear more successful, they want to achieve more, they want to please people – especially those who are in authority and set targets. But, and this is the real danger of Velocity Inflation, it undermines your ability to predict the future work capacity of the team because yesterday’s values can’t be compared to tomorrows.

Velocity inflation is just like financial inflation rational expectations and the Lucas critique need to be considered. It should come as no surprise that I’m going to quote Goodhart’s Law again:

• “Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.”

Targets are good when they help people to stretch and reach goals but in setting them you need to be aware of the side-effects. Simply to advocate targets is violation of Deming’s eleventh principle of management:

• “11 a. Eliminate work standards (quotas) on the factory floor. Substitute leadership.
• 11 b. Eliminate management by objective. Eliminate management by numbers, numerical goals. Substitute leadership.”

The solution is simple: don’t do it.

If you (quite naturally) want velocity to rise you have look elsewhere. That will be the subject of my next blog entry.

I want to stick with the theme of “how do I fill an iteration?” for a couple more entries. There are a lot of little nuances here, and what works for one team at one time might not be the best thing for another team, or even the same team at a different time.

I appreciated Ed’s comments on my last entry, I think they go to show how small variations work well for individual teams. However, sometimes variations hold problems.

Sometimes you come across a team that completes exactly the amount of work (measured in abstract points) during an iteration as they forecast they would at the start. For example: a team says it will do 10 points of work in the next iteration, and two weeks later they count up and they did 10 points of work.

Occasionally this happens, thats not unusual. Over time I’d expect it to happen more often but I don’t expect it to happen every iteration. When it does then something is probably wrong.

Statistically this is just very unlikely to happen. Yes a team will do roughly the same amount of work but exactly No. They are not doing the same work, the same tasks, the same events will not occur, the same people won’t work on the same things – and if they did we would expect them to get more done.

So when a team regularly scores the same points, week after week, as they expect to (and by implication the same number they did the previous iteration) then some force is making it happen. The real number should be higher or lower.

If the real number should be lower it means the team is busting a gut to do the work. Maybe they are working long hours, or maybe they are cutting on quality. Either way the work pace is unsustainable and problems are being stored up.

If the real number should be higher it means the team is satisficing. That is, they have the capacity to do more work but they are not taking it on so there is spare capacity. Sustainable yes, but not as productive as they could be.

I recently worked with a team led by a manager who would not allow the team to take on more work than they could guarantee doing. He did this because he didn’t want to explain to the project manager running the project that the team hadn’t done as much as they had scheduled.

The project managers in this company wanted predictability. If that is important to you then that’s a reasonable thing to do. But this company was trying to “go faster”. The managers were making a trade off: less work for more consistency week-on-week.

My preferred method is to always schedule slightly more work than the team expects to do. This way there is more work to do if the team find things go well. And if they don’t go well, or if they go badly, then nobody should have been expecting everything to get done anyway.

The fixed length iteration is a key part of most Agile methods. But the question is: how do you know what (i.e. how much) to put in the iteration?

There are two ways to determine how much is enough but what might be less obvious is that they are alternatives. It is easy to outline both and pretend they work together but really they don’t fit together.

The first way, lets call it the Scrum way, is to set a Goal. The team then commit to making this Goal. The objective is to find a Goal which is both achievable and challenging, and useful but small enough to fit in an iteration.

In this model the Product Owner comes along with some idea of what they want, the team talk about it with the Product Owner and, through conversation, come to an agreement on what can be achieved. The team then go for it.

The team “do what it takes” – if they need to work long hours they do; if they need to bang-heads together, they do; if they need to spend their own money, they do. Given this, one would assume that in those iterations where the team don’t have to move heaven-and-earth they could take things easy. If one iteration they work 14 hour days a reasonable quid-pro-quo seems that in those when they can finish a day early they do.

If at some point the team decide they can’t make the Goal, or the Product Owner says the Goal is compromised – things have changed and it is no longer wanted – then the team declare an Abnormal Termination of Sprint and everything starts over.

The problem with this way of doing things is around sizing the Goal. According to the Scrum literature, by aiming for a Goal the team rally round and choose to stretch themselves. The danger is that the development team start satisficing, that is: they promise enough to keep people happy but not so much that they are ever in danger of failing to meet the Goal.

Those who worry about satisficing probably also worry about what happens if the team meet the Goal early. This isn’t really explained in the Scrum literature I’ve looked at but I’m told that there should be a quick, mini-planning meeting with the Product Owner and some new work accepted. At which point I wonder: what happened to fixed iterations?

Conversely, looked at form the opposite point of view: what is to stop the business side putting on the developers and exploiting the situation to set difficult, time consuming, Goals?

There are plenty of developers in the world who have been bullied by their business partners into giving estimates which meet the business desire but have no real relation to the amount of time and effort it will really take.

Either way, the fundamental problem remains: how do you know how big to make the Goal?

Unless both sides change their mindset then the Goal driven model doesn’t really change anything. And changing mindset on both sides is a big task. One which doesn’t fit well with a gradual adoption approach.

Actually, I don’t think many people use the Goal driven approach to filling an iteration. If they did then I would expect to here about teams having spare time more often, and I would expect to hear about more Abnormal Termination of Sprints. I don’t hear of either so I don’t think this technique is used very often.

The second way of deciding how much to put in an iteration is to use an empirical measurement, i.e. velocity, lets call this the XP way.

In the model the Product Owner proposes some work as before. The development team do some quick estimates on how much effort is involved, the work is prioritised and work begins. The first time you do this you don’t know how much work to put in the iteration – how could you? You’ve not done this before. But the second time you can count how much work you did before and use this as a guide.

Iteration on iteration this count becomes more accurate and its what we call velocity. The technique of using the previous velocity to project the amount of work in the next iteration is called yesterday’s weather.

I prefer to use this technique and when I do I always slightly overload the team in the next iteration. That is, I schedule slightly more work than I expect them to do and everyone knows there is slightly more work than is expected to get done. In other words we expect something not to be done.

There is no point in scheduling even more work because the team isn’t expected to do it. There is no point in scheduling less work because it might be that the team has spare capacity.

If we get luck all the work we scheduled gets done, and if it doesn’t… well nobody should be expecting to get everything done, its just a question of how much.

I don’t update the estimates with actuals because that would be mixing apples and oranges. Estimate counts go in, estimates counts come out.

There are several problems with this technique. You cant be sure what will get done and what won’t, for some people that’s a big issue. Secondly, people like to relate the estimated effort levels to hours or days. When that happens the estimates become less accurate.

More importantly, the Goal driven method aims to stretch the team by challenging them to do something bold. Using velocity and yesterdays weather approach doesn’t even start to do this. The team are immediately satisficing.

Both these techniques have been advocated and used but what isn’t pointed out very often is that they are alternatives. If you use them together you definitely are satisficing to meet a Goal. Using commitment to stretch the team goes out the window. Unless of course you set stretch goals, in which case you are ignoring velocity.