Two and a half years ago I published a blog entry entitled “10 things to know about Kanban software development” which has consistently been the most read piece on this blog. At first I thought “Well there isn’t much published on Kanban relative to Scrum” but then David Anderson published Kanban and that wasn’t true any more.

Others have written about Kanban too over the last two years but still there is a hunger out there, people want to know about Kanban. I see this too when I deliver my Agile training courses, the moment Kanban is mentioned people want to know more.

Although Kanban is conceptually simple you really need a day or two to discuss it properly. Still, I regularly find myself squeezing an hour, or just 10 minutes, into a Agile training course because the audience want it. I say “I really need a day” but I can’t avoid it – they are paying for my time so they get what they want.

One of the reasons people give for buying an Agile (Scrum/XP style) course and wanting Kanban is, they say, “we don’t think Scrum will work for us so we might try Kanban.” Then when I return to coach teams I’ve given training to I’m regularly asked “Scrum doesn’t seem to work for us, should we try Kanban?”. I reserve judgement and enquire before I give my advice, and what I find is….

They haven’t really tried Scrum(XP).

Or rather, they have tried a Scrum(XP) type approach and they hit problems. Despite my telling them this would happen they think its Scrum. The thing is, Scrum fixes some problems “out of the box” but it doesn’t fix them all, in fact it exposes old problems and highlights difficulties which you then have to fix. Thats the way it works, that is the way it is meant to work.

Let me repeat that: Scrum and XP do, in and of themselves, right out of the box fix a lot of problems software development teams typically have. But Scrum and XP do not (despite what some people will tell you) fix all problems right off: you have to continue the work and fix them yourself. Sometimes Scrum, as officially described, will just not work, you have to modify it to your environment.

What worries me when teams say “Scrum doesn’t work, we want to try Kanban” is: if a team can’t make Scrum(XP) work because they cannot fix the impediments or make their own modifications then Kanban will never work. In fact, Kanban will probably be dead on arrival.

Some years ago Karl Scotland said “there is a subtle difference between kanban and typical agile processes such as Scrum. Scrum focuses on being agile which may (and should) lead to improving. Kanban focuses on improving, which may lead to being agile. However, being agile itself is not important – it just happens to be the best way we (or at least I) know at the moment.”

Thus: If you want to try Kanban because Scrum doesn’t seem to work for you then the chances are Kanban is only going to be a diversion. Set about fixing your problems.

Now there are reasons why Scrum doesn’t work, and there are reasons you should try Kanban, that should be a separate blog. One common case is because the development team has some support or maintenance responsibilities. In these cases my XP-Kanban hybrid Xanpan works quite well.

(I keep taking about Xanpan and a few people have asked me to write about it but a) I don’t think the world needs yet another Agile method, and b) until recently I wasn’t convinced there was enough difference between Xanpan and either Kanban or Scrum/XP to make it worth while. On the second point I’m changing my mind. If you want to know more about Xanpan let me know.)

Back to topic, although a team might not need to move from Scrum/XP to Kanban or Xanpan there might still be advantages to doing so. However moving because you can’t overcome your own obstacles is not a good reason for changing. If you can’t make Scrum work because you can’t fix your own issues switching to Kanban is not the answer.

Despite being a bit of a mouthful to say “Minimal Viable Product” and the even more difficult to say “Minimally Marketable Feature” (also known as a “Quantum of Value” or “Business Value Increment”) are very useful concepts. What makes gives them killer power is that they speak to a secret belief held by many people (not just managers) that teams gold-plate development and create products with more than is needed.

The trouble is, while we all agree the we should develop Minimally Marketable Features (MMF from here on) and delivery Minimal Viable Products (MVP) it is actually quite hard to do this. Nobody seems to want to sacrifice their favourite feature or the styling they have set their hearts on.

In Business Patterns I have a side box entitled “Strategy means saying No” in it I say “One of my personal rules of thumb is that strategy is about saying “No”. Strategy is not so much in what you decide to do – saying “Yes” is easy – but in the hard decisions about what you choose not to do.” The same applies to product development: saying Yes to a feature is easy, saying No is hard, but unless you say No a lot more than Yes you won’t have a MVP.

(After completing Business Patterns I discovered that both Michael Porter and Tony Blair have made the same argument, that No is more important than Yes.)

I have come to believe that one of the reasons teams find it difficult to create MVPs made up of MMFs is that the teams are just too big. I would like to suggest that if you want to create a MVP then you need a Minimally Viable Team. i.e. a team which is only just big enough to create the product.

Indeed, I will go further and suggest that your Minimally Viable Team (MVT) should be slightly smaller than you think you need.

Basically my logic is: if you have more people you will create more product. If you constrain the amount of effort that can go into a product then you will constrain the thing that is produced.

Way back I worked on Railtrack privatisation in the UK. When I joined the team is was 120 people (although only about 12 actual coders). The project was massive. Out of that came by belief that inside every large project is a small one struggling to get out. I sometimes call this Kelly’s First Law of project complexity: Project scope will always increase in proportion to resources.

A few years later I found myself working on a data feed project at Reuters. In retrospect the team was overstaffed. We didn’t need COM based system with interchangeable components. We made work for idle hands.

I know one team I’ve been visiting for over a year now, MMF and MVP frequently come up in discussion but I see the product backlog getting larger and larger and larger. The team is quite large by today’s standard – over 30 depending on how you count it. And ever since people started talking of enlarging the team the backlog has grown faster.

So much for the observations, lets try logic.

If you think about this the need for a MVT to create a MVP is a direct result of Conway’s Law: organisations will create systems that are copies of the organisation. (Seven years ago Lise Hvatum and myself investigated Conway’s Law in a conference focus group, the result was “What do we think of Conway’s Law now?”).

This can also be stated as the Homomorphic force: the structure-preserving relationship between two sets of things.

If you create a team which is too big it will produce a product which is too big. Once you have created a team which is too big it will find work for itself to do and it will be very very difficult to reduce the team size.

So start with a small team: actively try to break Conway’s Law, break the homomorphic force.

Staff the team with a fewer people than you think you will need, staff it with a range of skills but avoid making architecture assumptions in your staffing (if you include a DBA and you will have a database in the system.) As and when the team demands to grown then grow the team grow it.

Use Conway’s Law to your advantage: create a Minimally Viable Team to create a Minimally Viable Product.

How small is a MVT? I would say two people.

Really you need three people for it to be a team but in the belief that you should start smaller than you think I say two. One of these people should be focused on the business side of things – requirements, need, problem domain call it what you will; the other on the technology or solution domain. Let them work the problem for a while and see what happens.

Here is an observation which I’ve been been playing back to clients for a year or so now:

• There are two types of company in the world, those who talk about automated testing and those who do automated testing.
• Those who talk about automated testing buy tools like Quick Test Pro, WinRunner and Quality Centre and Rational Test Workbench, Rational Quality Manager, i.e. expensive products from the likes of HP and IBM.
• Those who do automated testing use tools like Selenium, Fit & Fitnesse, Cucumber (inc. Gerkin, RSpec, etc.) and other Open Source products they don’t need to buy

• There are a few, very few, companies which don’t talk about automated testing but on the whole everyone thinks it is a good idea and those who don’t do it would like to
• There are a some companies who talk about automated testing and have no tools; this is a better position to be in than talking and spending money

What I would really like to know is: has anyone else seen this? Or, can anyone give a counter example?

I think there is even a logic here. The IBM and HP products are expensive, so expensive you have to ask the price (actually IBM does give the price of Test Workbench at $5,500 for a single user license). Consequently they need to be sold, it also means that they need to be bought at a high level in the corporation. The people who are sold these products are very disconnected from the day-to-day work of developers and testers. This means the products might not be suitable and even if they are then developers and testers need to adopt them: they aren’t part of the change decision.

In addition: I just don’t think these tools are any good. To be fair, I’m no expert on testing tools but I’ve seen Quality Centre in action. Quality Centre (QC) isn’t an automated testing tool, its a very expensive test tracker. Testers write their test scripts in natural language, e.g. English, into the tool, the tool runs on the side and as they execute the tests they click Success or Fail. At the end QC gives a report.

To my mind QC is a fancy version of Microsoft Word. English language test scripts, if they are any good, are so detailed that they take almost as long to create as automatic scripts but they are expensive to execute because they are manual.

QTP and similar products are often linked to the OS or browser. They result in fragile tests which break easily when a box moves a few pixels or the browser changes.

HP also follow a razor blades model, I’m told: once you’ve bought QTP you need to buy a plugin for every browser to OS you want to use it with. Every time a new version of the browser comes out you need to buy a new plugin – or so I am told, tell me if I’m wrong.

The net result is: these tools are high maintenance and easily fall into disuse if they are ever used.

On the contrary: Open Source tools are adopted by people who do the work because they see the benefit they bring and they don’t need budget or signatures to get the tools. People get them because they want to use them not because a Salesman comes around and convinces the boss that you need a tool.

And because many of the Open Source tools require developers to create glue code to interface the tool to the application they lead to a more collaborative style of working.

(Perhaps some companies who just talk about automated testing have downloaded some of the Open Source tools but never use them tool. Since they are free nobody notices.)

So there is my theory. Anyone else seen this? Anyone else explain it? Anyone got a counter example?

Last week I made the London to Cornwall train journey for the first time in a few months. I made the journey many times during the course of the Agile Cornwall programme. This time however I was on my way to the Agile on the Beach 2012 conference. The conference itself is a product of the Agile Programme and looks set to run again in 2013 (although the final decision has yet to be taken.)

With the release of a report last week which claimed the Agile Cornwall programme created 50 jobs I felt Agile on the Beach is something of a celebration. I’ve now had a chance to read the report in full and while the report is not available for public download I would like to share a few comments from it.

First I should say that the report itself was conducted by a third party company commissioned by Oxford Innovation. Oxford Innovation runs the Grow Cornwall programme on behalf of public bodies and it was as part of this programme that Agile Cornwall was bored.

The report surveyed the companies who participated in the Agile programme to find out about their opinions of the programme and the changes which had resulted. They spoke to multiple people in most of the companies so it was pretty well grounded although it probably wouldn’t stand up to rigorous academic analysis. (If any academic out there would like to do a rigorous study then please get in touch.

Here are some highlights from the report:

• The Agile programme has met expectations for all companies who participated in the review. (I suspect one which was disappointed did not participate.)
• Businesses are finding they are more flexible and responsive to customers
• Money and customers
  • None of the business reported a decrease in turnover, profitability or customers since adopting Agile.
  • 7 companies reported increased turnover or revenue; 3 reporting the increase was significant
  • 6 reported increased profitability, 3 saying the increase was “significant”
  • 6 reported an increase in customer and/or business opportunities with 3 of the six saying the increase was significant

• One company reported that it was now more difficult to hire because they could not find people with Agile skills.
• Small companies said it was difficult to find the time to get started on Agile

There are also some very positive comments on the quality of the consultants used in the project, as I reported in my last blog it wasn’t all me. But, if I may be permitted to blow my own trumpet, I was there a lot, I worked with more companies more of the time than any other consultant. So I’ll be giving myself a pat on the back!

The report has, unfortunately, not been made public – although a summary version was given to attendees at Agile on the Beach. So if you would like to see the full report I suggest you go and knock on the door at Grown Cornwall / Oxford Innovation.

Regular readers will now that over the last two years I’ve done a lot of work in Cornwall, I jokingly refer to “the Cornish Software Mines” (A case study and Light Touch Coaching to name two blog entries.) To date the most visible result of this work was the Agile on the Beach conference which is running again next week.

There is now a report out which has looked at the programme overall and concluded that the Agile Cornwall Programme created 50 jobs. That might not be a big deal for London but in Cornwall that is a big deal. Particularly since half the jobs were high paying.

So far I haven’t actually seen the report so I just have this report on the report to go on. I’m trying to get a copy as we speak.

I can’t take all the credit, I had help. The thanks need to go to:

• Oxford Innovation for creating and running the programme
• Michael Barritt who was the driving force while of Oxford Innovation and has since moved to Sullivan Cuff Software (one of the programme’s success stories)
• Jon Jagger who provided most of the technical coaching
• Benjamin Mitchell who coached several of the clients when I was fully stretched and gave intensive help to one of the more difficult clients
• Plus Kevllin Henney and Sebastian Bergmann who provided additional training, and Nancy Van Schooenderwoert who provided specialist embedded consulting

There is still time to book tickets for Agile on the Beach if you want to meet all these people and some of the people who benefitted.

“The second is the most dangerous system a man ever designs” Fred Brooks, 1975 & 1995

Brooks was talking about software designers, architects, but I think the statement holds true not only for all software developers but for the business people who commission replacement systems.

From time to time I come across a team who want to rewrite their system. Usually this is the technology team who are saying “The code is too complex, the thing was written by a jerk, She cannae take it Captain”.

Sometimes is the business side realising that their system looks out of date – Visual Basic 6 controls on Windows Vista, or turn of the century web style.

Either way there is a “Stop the world I want to rewrite” mentality. Sometimes the powers that be buy the argument, sometimes they bless a rewrite or, as one team called it a “Technical Improvement Programme” – TIP for short.

Lets me come to the point: this is always and everywhere a mistake. You should never, ever, rewrite a system just because the technology is old.

This is a mistake because customers don’t want to change. The may think that VB6 controls look odd but they know how to use it. Even if change would benefit them they are scared of it. Plus, they have their own business to run – or life to live – and changing systems is only going to get in the way.

Second, this is an utter waste. Statistics regularly show that as much as 80% of features in a typical software system are not used. So why implement five times more functionality than you need?

One company I worked with commission an cheap Indian company to rewrite an old PowerBuilder application in Java. They were told to make it identical. So they did, they spent a lot of time making Java look like PowerBuilder. They copy every feature, even the ones not used. It was buggy as hell and the users didn’t want it.

Third: the “just a rewrite” mentality leads people to under estimate the complexity involved and to overlook the opportunities for improvement. Why produce a second system which is identical to the first?

Finally, and worst of all: the world doesn’t stop, you can’t afford to stop and rewrite, nor can you afford to waste the opportunity to produce a really good system, one that is better than competitors.

Yes, I agree your current system might be at the end of its life and you might need to throw it away but the solution is not a rewrite. When this happens you have two options.

The first won’t satisfy every problem but is the least risk: refactor your way out of the problem.

Actively encourage programmers to refactor code, of course you need to embraced Test Driven Development at both the development and testing level first of all and start putting tests in. Thats not to say you cover it in tests first and then refactor, rather you start putting the tests in as you go. This is a bit of high-wire act without a safety net at first so I strongly recommend you get some help if you’ve not done it before.

This is real engineering, this is changing the engine oil while the engine is running.

That is the easy answer but it won’t work every time. Sometimes the changes are too much, say from VB6 to C#.

The second answer to develop a new product, a competitor product. One for which your current system/product is the competition. This development effort needs to be market lead and focus on what customers/users want the the current system doesn’t provide.

I’ll say it again: Market led. The marketing department, the product managers and/or business analysts should decide what goes in. Not the developers.

When companies rewrite they jump to the assumption: “The developers know what the current system does so they just need to copy it.” That is the biggest mistake.

Next, get into the market fast, release early release often. Test what you are building in the market, show your company real, usable progress. Remember, your competitor is the current system, if you can’t do better than it you want to know fast.

The objective is to build a system that your current customers want to use, one for which they are prepared to give up the system they have at the moment. Consider this a variation on Same Customer, Different Product pattern (available online or in the Business Patterns book).

Emphasis the things the new system does that the old one doesn’t. Don’t worry about all the features the old one has that you think you need to launch. You might need them in the end but nobody is going to buy your software because it does the same thing. Add them as you need them, you’ll find you need to bring across far fewer than you initially think.

Now I apologise to all the developers out there who are begging their managers to let them rewrite the system. Your code base may be terrible, the technology may be out of date but a development led rewrite is not the answer. Few companies can survive such a thing.

The last two blog entries (“Scopeless contracts: the problem” and “Scopeless contracts: the solution”) have been working up to this one. Actually this is the blog entry I set out to write a few weeks ago but felt I had to explain why.

Even if you accept that leaving scope out of a contract for work is the right thing to do you still need to sell it to your customers. This is, perhaps, the real problem. However this is not always the case. Some clients will immediately recognise the problem, or might not wish to sign a big up front deal.

So, faced with a customer who wants to know “How much will it cost to do X ?” what should you say? Or rather, what can you emphasis to persuade them that you have a better idea?

(Note, on anything other than a trivial piece of work X will not be one thing but many, call them X1, X2, X3, … Xn.)

1. Flexibility: scope less contracts build in flexibility, if the client wants Y instead of, or in addition to X then thats OK. No need to scrap this contract and start again.
2. Work can go away: Suppose X3 become pointless, then it can just go away without any trouble. As opposed to the UK Government Connecting for Health project [[link]] were actually cancelling the project is more expensive than letting it finish.
3. Room for innovation: if you sign a big contract and later think of a bright idea then something has to give. Scopeless contracts allow for this because feature negotiation is ongoing.
4. Bounded by money: Rather than being bounded by scope contracts are bounded by the money available, or sometimes the time available. This forces the creators to work within a very real boundary rather than poorly defined scope and time estimates.
5. Governance control: bounding the contract in money provides for real governance rather than the governance by proxy that scope, features and line items provide. When the money runs out the work stops. (This of course assumes the team are making regular deliverables, if they aren’t you have even bigger problems.)
6. Inventive to reduce work: putting 2, 4 and 5 together you get an incentive to reduce the work to be done rather than inflate. In traditional work scope is problem because removing it creates contract problems and loss of face, but more importantly: there is little incentive to remove work until difficulties hit.
7. Reduce delay & waste, keep options open: All the time spent writing and negotiating scope delays the time when you actually start delivering something. If things change, and the longer you spend writing the scope the more likely things will change, then the more of that work which will be wasted. And the more you think you know what you want the more you constrain the options for producing the optimal solution. Selling without scope reduces this work because scope is derived as you go within the process and only enough is produced as is needed.

1. Traditional work relies on a scope myth “scope won’t change”. It does but we pretend it was because something was wrong. The result is we spend time and money managing the myth: managers need to revise contracts, staff change boards, write complex governance reports, etc. etc. In other words: because managing scope is doomed to failure the thing we call “scope” is a chimera which we waste time and money on “managing”.

In my last blog entry, “Scopeless contracts: the problem” I rehashed all the reasons why including scope in a contract for delivery is a bad idea. So having rubbished the most common way of working I had better explain what I suggest you do….

You have two choices.

Option 1: Set up a ‘Business as Usual’ contact.

The client nominates work to be done and the development team do it. Simple. This is the way most organisations work “business as usual” but once the idea of a project enters the scene people expect the project to have an end date, in order to have an end date they imagine that some amount of work needs to be done.

You can still have an end date but instead of measuring progress against “work to be done” (he scope, the backlog) measure progress against the value added.

After all, software is never finished. If you ever run out of requests for a software product it means nobody is using it. However it might not make sense to do all the work that is requested.

How do you size the team? You don’t, you start small. You start with just the money you can afford to loose. After a while, say three months you review what is bring done and decide whether you wish to go faster (expand) or slower (contract), or perhaps stop altogether.

(Another reason to start small is to reduce the effect of Conway’s Law: if you start big you will get a big programme of work, if you start small you might just come up with a small solution.)

Option 2: Set a Goal, work to the goal

If option 1 isn’t governed enough for you then set an overarching goal. Every three months (or what ever time you decide) ask yourself: are we making progress towards the goal?

You might even want some people on the team measure progress towards the goal (these would normally be Business Analysts). All the work you do should be tested against the question “Does this move us towards our goal?”

If you want more structure use my 10 Step Requirements model.

Yes, it really is that simple.

Drop the backlog. Set a goal. Work business as usual. 1, 2, 3.

The thing is, when you contract with someone to build you software its not like asking them to build you a house. You are buying a service not a thing. If you could buy a thing you probably would have done already. Once you make that mindset shift it all makes sense.

The only complication is, well there are two really: first you have to accept the project model is broken so you need to make more strategic decisions. If you need to keep projects for accounting purposes but projects should have nothing to do with development.

Second you need to do this on a rolling basis, review it every three months.

For most organisations the biggest problem is that they have come to believe the project myth, and they believe it all the way up the hierarchy. Until the people at the top really understand that IT doesn’t fit into the project model its difficult to change.

I’ve discussed Agile contract models before and I’ve agued against points based contracts (‘Points based contracts? Just say No’) but the more I think about client-supplier software development contracts the more I think including any scope in the contract is asking for trouble.

Before I explain let me say: Yes I know this isn’t going to be possible either with your clients or your own sales folk, I’ll follow up this blog entry with another setting out what you should sell instead.

Now I’m using the word scope, although I hate the word it is the word most people recognise. I mean: “the work which will be done.” Call it a requirements document, a PRD, a product backlog or anything else. Its a shopping list of things you think you want.

Right now, here is why I think fixing scope inside a contract is a bad idea:

Scope is always unknown: you may think you know it but you don’t because things change, learning occurs (on all sides), when someone see something they change their mind about what it is they want, or what they ask for, or what they want next.

I’ve been over this ground again and again, first in Why Do Requirements Change (2004), again in Changing Software Development (2008) and more recently in Dear Customer (2012).

And the bigger your project is the more your requirements will change and grow. Capers Jones gives the industry average as 2% per calendar month for large projects. If you’ve got a project/programme that is up and running you can go and measure it yourself. One team I know saw their product backlog increase by 50% between January and July.

Someone said to me recently: “Surely the team has got better at this now, they’ve learnt.” Well yes, they will have got better, that might take the edge off, might rule out some human factors but the world hasn’t stopped.

The World is Changing: lets suppose for a moment you are running a big project, say its been running 2 years and you think it has another 2 years to run. Cast your mind back 2 years, what was the world like in July 2010 ?

First some context: David Cameron has been British Prime Minister for 2 months, Osama bin Laden was alive and well, few people outside Japan had heard of Fukushima, Deepwater Horizon had just been capped and oil was under $50 a barrel.

• The first generation iPad had been on sale for 3 months, it was far from obvious that Apps were about to take over the world
• Nokia were still pushing Symbian phones and were still the biggest mobile phone seller and Android was in version 2.2 (Froyo)
• JP Morgan was fined £33m for failing to protect client money
• Greek debt was downgraded to junk in April
• Barclays were fixing Libor

Did any of those events effect your business?

Did any of those events, or countless others I haven’t mentioned effect what your business wanted?

Now ask yourself: what could happen in the next two years, to 2014, that would change what your business, your customers want?

President Romney? Grexit? Finexit?

Scope should reduce as well as increase: when you fix scope you also make it difficult for scope to reduce. Requirements should be reducing as much as increasing.

Marty Cagan recently blogged about “The Opportunity Backlog”. Your backlog is not a list of things that will be done, it is a list of things which could be done, and you should do as little of it as possible (its expensive), instead focus on the opportunities which deliver the most.

You human, you make mistakes: well maybe not you personally but the people who work for you.

There are mistakes in what you ask for, mistakes in what you build and mistakes in how people use it. Sometimes fixing a mistake is more important than doing something new.

Second system effect: there is a blog entry waiting to be written about version 2 projects, for now lets stick with what Fred Brooks said in 1975: “The second is the most dangerous system a man ever designs. … The general tendency is to over-design the second system, using all the ideas and frills that were cautiously side-tracked on the first one.”

Whether you are designing from a technical, user or business perspective you suffer from second system effect.

OK, am making my point?

Since requirements can and will change there is not point in writing them into a contract.

This point is doubly dangerous if you attached estimates and timelines to the contract because you will be wrong again. Human’s Can’t Estimate.

This is bad for the supplier who will sooner or later have to explain what is going on to the customer and its bad for customers who don’t get systems that work.