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.

As I mentioned last time, I recently delivered a course on Lean software development in Oslo. One of the exercises I set people was to produce an A3 report.

A3 reports, for those unfamiliar with them are a mechanism used at Toyota to analyse issues and suggest solutions, or rather “counter measures” . The term “counter measures” is preferred over solution because no “solution” is ever the end of the story. One day there will be a better solution, er, I mean better counter measure.

Put it another way, as Peter Senge says in The FIfth Discipline, “tomorrows problems come from todays solutions.”

Anyway, the purpose of writing about this is to share my A3 report templates with anyone who is interested. There are actually two templates:

• A3 training: An important part of A3 writing is to “go and see” the actual work happening, and talk to the actual people who do it. In a classroom you can’t actually go and see the issue, you can’t talk to the people performing the task or check the company data. Therefore I allowed students to make assumptions as long as they noted them on the report. Afterwards we could talk about how the assumptions could be validated to prove, or disprove them.
• A3 report: this is the same report template without the extra space for assumptions and notes. This is the template to use for real outside the classroom.

Strictly speaking there isn’t a specified A3 format. This confused me when I first started digging into the A3 method: I was looking for templates. It turns out that you can just start with an blank sheet of A3 paper, but it also seems there are some standard elements and structures people use when writing an A3. My templates are what I think are the key elements.

But the actual A3 report, the thing you can see is only half the story. The A3 report is not just a thing, it is a process. The process of creating the report, the observation, investigation and mentoring, is probably more important than the end result.

If you want to know more about A3 reports John Shook’s book “Managing to Learn” is good, although you have to order it from the Lean Enterprise Institute, its not at your local online bookshop. For a shorter version check out Shook’s article in the MIT Sloan Management review, “Toyota’s Secret: The A3 report”.

One thing that struct me while reading Shook’s description of A3 is their similarity to patterns: both involve a context, a problem, the things that make the problem hard (forces or analysis), both propose a better way (solution or counter measures), both value brevity and both allow the authors to change the format to suit the problem.

More importantly, a key element of A3 reports is the mentoring of A3 writers that occurs during the creation process. This sounds just like the shepherding process that any pattern paper being present at a conference goes through. Having shepherded many pattern papers – and won a couple of awards for it, I might say – the A3 mentoring process seems exactly the same.

Back in the Oslo classroom I learned: allow plenty of time for the A3 report writing. Its not something to be rushed.

I recently experimented with A3 formats on a coaching assignment with a client. I asked several manager to complete one. Most of the time, if you are going to ask someone to do an A3 you need some position of respect, or at least authority. They look odd to manager schooled in long report and PowerPoint reports, they require a depth of thinking they are not accustomed to and they look funny.

If anyone tries using these reports please let me know what you think and what your results are. And if anyone wants to do an A3 with me, I will be running the Lean course again in Oslo in November. This course was two days, I’m planning to increase it to three days next time so allow more time for this and other exercises.

This link has been in my blog backlog for a couple of months, waiting to work its way into a blog post. But I’m fed up waiting so here it is raw.

What Is Software Design? by Jack W. Reeves on Developer Dot Star

Originally published in 1992, before Java, before C#, before Agile, when Lean was just breaking out of Toyota and before the web (almost) this is a classic piece about software design.

Reeves argues that all coding is design. His specifics might refer to C++ but this could be any language.

Just in case you are in any doubt: I completely agree.

I was helping a team set up their board (white board, Kanban board, Scrum board, call it what you will) for Agile working the other day and it dawned on me I use a whole bunch of heuristics I’ve never seen written down. So here goes:

• I like magnetic white boards best myself but I’ve seen teams use walls, cupboards and flip charts too. The important points are: big, visible things you can stick other-things on it.
• I prefer to use index cards but many teams use Post-It type stickies. If you use index cards you need a means of sticking them to the board which is where the magnets come in.
• You can divide the columns: classically this is To do, In Progress and Done. Of course Kanban teams use many more columns.
• At first I used the same dry market pens to mark the columns as to make notes on the board. The trouble is these lines tend to disappear. This is a particular problem with Kanban teams who have more columns and so more movements to make. So now I use coloured electrical insulation tape to mark the columns. This is much easier to see and lasts a lot longer.
• Leave space on the board to include Team or Project name and the end date of the iteration. You might also find space to keep a burn-down/up or cumulative flow diagram.
• You don’t need a very big board: I normally use 120cm x 90cm, again Kanban teams tend to need bigger boards because they have more columns.
• You can buy a suitable board from most stationary suppliers for less than £100. If your company can’t afford this (or won’t pay) you have problems which Agile isn’t going to fix.
• Remember to buy magnets, dry wipe pens and something to remove the permanent market someone is going to put on there eventually.
• Coloured magnets are fun but so far I’ve not found using the colour of a magnet to convey information hasn’t been worth the extra effort
• Boards are usually mounted on the wall or a stand but, I prefer them to be free standing because you can carry them around. If you have a meeting in another room you just pick the board up and carry it there. And its a team exercise to move it.
• We had an accident with a board once: it was hit from behind at the start of the planning meeting and everything came off. But that turned out to be good, we looked at everything in more detail. Sometimes I now remove everything at the start or during the course of the planning meeting and only replace it if I need to.
• Don’t put designed on your board: there isn’t enough space. By all means have another board for designs.

One of the important, but often overlooked, roles in any software development is the “needs” guy. I put it that way to be as general as possible. Its the role which decided what the customer/end-user actually needs (sometimes wants but doesn’t need).

I’ve blogged before (many times, The Product Owner role (August 2009), Requirements: The next challenge for Agile (February 2009), Books for Product Managers (December 2008) among others) about the Product Manager role. However, Product Managers, or to give them their full title, Technical Product Managers, only really exist in genuine software product companies (including software as a service models). In corporate IT departments and software service companies (i.e. ones that write bespoke software for a specific customer) the role doesn’t exist.

In these companies the “needs” role is usually (or should) be filled by a Business Analyst. I blogged about these when I blogged about System Analysts earlier this year.

Both Product Managers and Business Analysts (BA) are concerned with the “what” of the software product, but how they decide this is different. Basically:

• Product Managers find the need by looking outside the company, at a market of multiple potential customers
• Business Analysts look inside the company at a single customer, with potentially many stakeholders involved

I’ll probably blog about this more in future.

However, he BA role is much misunderstood. As a title I think it ranks second only the “Project Manager” in abuse. In some places BAs are really System Analysts, in others they are Project Managers, in others they just gather the requirements. The definition I like best is “Internal Consultant.”

Thats one of the reasons I really like the Business Analysis Maturity Model.

You can view this model as model for individual career development, but I prefer to view it as a model for corporate advancement. At the “low end” BA just rather up everything “users” think they want, at the high-end the BA is responsible for discovering what the business needs to improve.

When you do this the BA role looks a lot more like a Product Manager role: its about deciding what will advance the company and product in both cases.

And its important from an Agile perspective. When the Product Owner/BA role is played as a “requirements gatherer” then there is little scope for the BA to add value and, more importantly, there is little flexibility in what is delivered. The BA becomes just the guy who communicates the need to the people who write the code.

When the BA role is played as an consultant, working with customers/users and the development team to fill a business need then the conversation changes. Rather than discussing which, and in what order, features will be developed from a given shopping list then conversation can centre on how best to satisfy a business need and maximise value.

In short, the BA Maturity Model is a critical, and until now missing, piece in understanding the BA role in Agile teams and Agile development.