Capers Jones & "How many teams are Agile?"

A while ago I tried to answer the question “How many software teams are using Agile?”. My best efforts put the answer at somewhere between 5% and 15%.

In the search for some other data I’ve recently been look through Capers Jones “Applied Software Measurement” (2008). It is packed full of interesting statistics and I really must buy a copy and read it in more detail. Anyway, Jones gives his hypothesis of project in this table:

Type of development	Number	%
End-user	2,500	2%
Agile	20,000	13%
Web	12,500	8%
Systems	8,750	6%
MIS	70,000	45%
Commercial	3,250	2%
Outsource - US	17,500	11%
Outsource - offshore	15,000	10%
Military	7,750	5%
Total	157,250	100%

(In case that table gets mangled, the first column is the type of development, the second the total Jones looked at and the third the percentage of the total.)

Jones puts the number of Agile projects at 13%, firmly inside the range I give. Of course there are two caveats here. Firstly, the ways Jones has sliced and diced the numbers leaves me wondering how he has counted military work running Agile, and outsourced work running Agile.

Second, how do we know if a piece of work is Agile or not? All the evidence I have tells me that an awful lot of teams are saying they are “Agile” and frankly aren’t. As Kevlin Henney suggested on re-twittered (from somewhere or other) recently a better question to ask is “How are you Agile?”

I’ll get Jones book and read it some more. One other thing he mentioned stood out: getting metric on software projects is hard. He says its like searching through debris, lots of rubbish then occasionally a nugget. Which sums up how I feel about software metrics now. Its quite like I imagine archaeology.

Les Hatton's site and the importance of letting failures fail

I recently stumbled across Les Hatton's site. I've owned one of Les' books for probably over decade (Safer C, a classic) but this was the first time I've looked at his website. I highly recommend a perusal of the site and reading some of his papers. Apart from anything else he's an even more interesting guy than I thought he was (and I already though he was interesting!).

One set of his papers looks at the power-law nature of software code. I'll admit I couldn't follow all of the academic speak and advanced maths terms - which might disqualify me from reading some papers but it
more a sign that I didn't take the time to work it out in depth. (Most of his papers are written in a very accessible style.) The key point I took away was that he extends James Noble's work to non-OO systems. Hopefully I’ll find time to go back and read more of these papers in depth and make sense of the bits I skimmed this time.

Another paper which stood out was “How to build successful complex systems: lessons from open source” with his suggestions for how to build the NHS IT system. Until I read this I was unaware that the Welsh
Health Service had taken a different route to the English one, had spent far less money and had actually produced a successful system.

Les, like many others, sings the praises of the Open Source movement. He’s right, there are some very successful Open Source products out there, but, as I’ve pointed out before, most Open Source
projects fail. And when I say MOST I mean tens of thousands fail for every success.

Fortunately Les’ suggestions allows for this; he suggests a Darwinian process with seeds 100+ development efforts and over a series of rounds reduces them to one winner.

Although Les suggests this in an Open Source context what he is actually suggestion is also a Venture Capital model. He proposes to give over 100 teams a little bit of money (seed money in effect) to create an initial system. Year on year winners are selected to continue development, these are given a bit more money. That sounds exactly like Angel funding, VC Round A, VC Round B, etc. etc. funding. OK, Les model is “open” because the winning teams get to pick over the remains of the loosing but even that exists in commercial activity: failing companies get bought by the winners who keep the best bits.

Either way the result is the same: rather than one “too big to fail” NHS IT project we have a number of small projects which compete and can fail. If we remove the ability to fail from the process then we have to
pay for failure.

Whether it be evolution, capitalism, IT projects or even banks, if failures are not removed from the system then change is inhibited because the winners cannot really win.

This is the important thing about failure. Forget that myth about learning from failures, the important thing is that it eliminates something that doesn’t work.

PROMS-G slides and other speaking engagements

I presented to the BCS PROMS-G group (Project Management Special Interest Group) last week. This was an expended version of my Jax London talk and formed part of their “Spring School” on Agile. The slides for “The Future of Agile 2010” are now online.

Originally this was going to be a repeat of the BCS Bristol Spring School talk on, The Future of Agile, you might like to compare the two presentations and how my thinking has developed.

Unfortunately I’ve had to pull out of the ACCU Conference this month. I haven’t missed an ACCU conference since 2001 so as much as I regret missing it I think I can skip one. Unfortunately an family matters made it difficult to keep this commitment. The good news for anyone going to the conference is that my place is being taken by Rachel Davies.

So I get April off speaking in public but come May....

I’m speaking to the IIBA Nottingham meeting on 10 May. This will be a repeat of my talk to the IIBA BA conference last year about the BA role in Agile, “More important then ever, the BA role in Agile transition”.

Then I’m speaking to Sottware East in Cambridge on 20 May when I’ll be speaking about The Falling off a log theory and other observations on the software industry.

Unfortunately that means I’ll have to miss the May meeting of ACCU London, which is a shame because Kevlin Henney is the speaker and he is always entertaining.

PROMS-G slides and other speaking engagements

I presented to the BCS PROMS-G group (Project Management Special Interest Group) last week. This was an expended version of my Jax London talk and formed part of their “Spring School” on Agile. The slides for “The Future of Agile 2010” are now online.

Originally this was going to be a repeat of the BCS Bristol Spring School talk on, The Future of Agile, you might like to compare the two presentations and how my thinking has developed.

Unfortunately I’ve had to pull out of the ACCU Conference this month. I haven’t missed an ACCU conference since 2001 so as much as I regret missing it I think I can skip one. Unfortunately an family matters made it difficult to keep this commitment. The good news for anyone going to the conference is that my place is being taken by Rachel Davies.

So I get April off speaking in public but come May....

I’m speaking to the IIBA Nottingham meeting on 10 May. This will be a repeat of my talk to the IIBA BA conference last year about the BA role in Agile, “More important then ever, the BA role in Agile transition”.

Then I’m speaking to Sottware East in Cambridge on 20 May when I’ll be speaking about The Falling off a log theory and other observations on the software industry.

Unfortunately that means I’ll have to miss the May meeting of ACCU London, which is a shame because Kevlin Henney is the speaker and he is always entertaining.

EuroPLoP 2009 proceedings now online

As some of you will recall, I was one of the Chairs for the European Patterns conference in 2008 and 2009. One of my responsibilities for the 2009 conference was to produce the conference proceedings. Well I’ve done it!

2009 represents a change for EuroPLoP. Until now we have published our proceedings in a physical book, a large book I should mention. This cost the conference organisers money (because it sold almost no copies), the money pushed up fees, and the proceedings were almost completely inaccessible unless you actually went to the conference. While some authors (like myself) put their papers online not everybody did.

For 2009 this has all changed, we’ve gone electronic. Thanks to CEUR EuroPLoP 2009 proceedings are available for free to anyone who want them. You can download individual papers or everything as one 30Mb PDF file.

So roll up, roll up, get your EuroPLoP 2009 conference proceedings here!

Change models: Shook, Schein, Dreyfus and Constructivism

Continuing on from my opening comments in the last entry, “Why forecasts fail: simple ones are better ”...

The other article which was good in the latest MIT Sloan Management Review was John Shook’s piece on change. His change model complements my own ideas well.

Shook’s model is shown below. He sees change starting with specific practices, e.g. just-in-time inventory, and as teams improve their practices and deepen their understanding they move to more thinking for themselves.


I’ve written before about my Agile triangle (or maybe pyramid is a better term). In the last few months I’ve added another insight into this model. Team which start by just “doing Scrum” or “XP” and want to advance, improve their process and practices further, deepen their understanding and application, take the next step, call it what you will, well, they need to advance by moving down the triangle.


You might start doing XP but over time you want to look outside XP and see what else is out there in the Agile toolkit. Deeper still is going back to Lean and picking up the Lean tools (value stream mapping, A3s, focusing on flow, etc.) And deeper still is a learning organization, a team or unit that is continually learning and changing.

While this goes some way validating my ideas its not the end of the story. Shook goes further and suggests his model parallels Edgar Schein’s writing - Schein is an MIT Management professor who has written extensively on culture and organisations.

Schein argues that organisational culture cannot be changed directly, indeed, to start with a desire culture in mind is a mistake. Better to start with the issues in hand and set about changing the cultural artefacts. Shook gives the model below (similar but inverted to the one on Wikipedia.)

It hadn’t dawned on me before, although heaven knows I once read plenty of Schein, that this isn’t far from my model. XP and Scrum, and other Agile methods, really start by changing the culture artefacts of an organisation.

Out go Gantt charts, in come burn-down charts.
Out go status meetings, in come stand-up meetings.
Out go moving deadlines, in come fixed iterations.
And so on.

Only later, are teams expected to reflect and modify their models - moving down the triangle/pyramid, moving from XP to Agile, to Lean, to a Learning Organization.

This also fits well with the Dreyfus model of skill acquisition which is so well liked by many in the Agile community. In this model a Master teach the pupils, when the pupils have mastered the skills they are allowed to think for themselves.

I’ve always disliked the Dreyfus model, and I believe it has failure built in. This is because the learner spends a long time looking to the teacher for the answers, they are not encouraged to find their own, indeed they are discouraged from trying anything different to accepted norm. Consequently someone may have mastered the skill they set out to, but they are no better at learning or problem solving. Faced with a new problem, or a need to deepen their understanding, and without a Master teach and ready made answer they are lost.

Maybe I over worry about this danger, as usual the truth is probably somewhere in between the two extremes. Rather than the Dreyfus model I look to the Constructivism model of learning. Under this understanding it is peoples understanding, derived from their experience which constitute learning. The teacher is not there to teach so much as to help individuals experience something different, the individuals sense making process then takes over.

Still, as I’ve said before: my interpretation Agile comes from Lean and the underlying idea of organisational learning. (Indeed, I think I wrote a book about that!)

As a result when I’m trying to make teams more Agile, I’m really trying to make them better learners, and make the organisation as a whole a better learner. While publicly we might be working down the Agile pyramid secretly I’m trying to work up.

Why forecasts fail: simple ones are better

As regular readers may recall (one of my favourite expressions!)... I regularly ponder my subscription to the MIT Sloan Management Review. After a few dull issues - which leave me wondering if it is worth the money - it has once again come up with an issue with a couple of articles which justify the price for the whole year.

One of these is “Why Forecasts fail. What to do instead.”

The insights I find illuminating here are:

• Sophisticated, complex, models are good at fitting past data (“forecasting wit hindsight”) but they only not very accurate in predicting what will happen in the future (they tend to extrapolate)
• Simple models are not so good at explaining past data but are better at forecasting the future
• Human judgement is worse than statistical models at predicting the future
• Experts don’t predict any better than the average person
• Averaging the predictions of several independent individuals is more accurate

The article cites research to back up these assertions.

This fits in well with what I tell teams when I’m coaching and training in Agile methods. The simple estimation and velocity measures I advocate are better than the complex models which are too often preferred.

And it is no use asking a system expert (architect, senior developer, what-ever) how long it will take, their estimate is no better than anyone else. But, getting several different estimates (e.g. using planning poker or similar) is.

One technique suggested by the article is something I’ve tried in “future-spectives.” You say to the team, or individual, “Imagine we are at the end of the project, we have finished on time, in budget, everyone is very happy, what did we do right?” and the opposite: “Another failed project, what did we do wrong?” Imagining yourself in that situation can produce useful insights.

The Scrum Hegemony & the Kanban Insurrection

One of the ideas I talked about in my Jax London presentation is something I call the Scrum hegemony and it deserves a few notes.

In the early days of Agile there was a tendency to equate Agile with XP, that changed a few years ago and Agile become (almost) synonymous with Scrum. I’m not saying Agile was XP or Agile is Scrum, just that to the uninitiated it can seem that way. (I blogged about this nearly 2 years ago now, see “Scrum is the new XP”.)

In many ways the Scrum people did a fantastic job of making Agile acceptable to the corporation. They had data and Harvard Business Review articles to cite, they didn’t ask the corporation to get into technical details (like TDD) and they had a friendly (English) name which avoided the word EXTREME! And most of all they had Certifications. O, don’t forget a pretty good marketing machine.

All this had the effect of making Agile acceptable to suited corporate types who didn’t know the first thing about software development but knew projects were always late. Ironically Scrum isn’t much more than XP, indeed, it is less than XP.

Consider XP: you can basically divide it in two. The bits about engineering (continuos integration, test driven development, refactoring, etc.) and the bits about managing the work (iterations, stand-ups, stories, etc.). Scrum, as documented concerns itself with the management side.

Granted Scrum expands on roles, Scrum adds some concepts like self-organising teams, adds some terms like backlogs and renames others (iterations to sprints) and adds burn-down charts but the management side of XP is basically Scrum, and Scrum is XP.

Purists might like to argue about which stole from which but the point remains: they are the same.

Scrum is devoid of the engineering practices, but as I’ve noted before in this blog: Scrum without the engineering practices is heading for trouble.

XP’s success, and the even bigger success of Scrum had the unfortunate side effect killing off most of the other Agile methods: FDD, ASD, Crystal, etc. Pockets still exists (especially with DSDM) but that is all they are, pockets. That was good for understanding but bad for experimentation and learning.

That’s now changing. The Scrum hegemony is now ending. Kanban, and perhaps other methods, are now offering alternatives. David Anderson’s Kanban insurrection is again offering an alternative. Kanban is again allowing the experimentation and variation in process that the Scrum hegemony has been stifling.

Don’t get me wrong, I don’t think for one moment Scrum is going to roll over and disappear, or that Kanban will dominate. Scrum will continue to be the Agile method of choice for corporations, it will be the 800 pound gorilla to use a phrase. But it will no longer be the only show in town.

Kanban is on the rise and drawing more attention to Lean, Software Craftmanship is on the rise and Tom Gilb’s work is being re-examined. There has long been a divide in Scrum between those who believe in “one and only one Scrum” and those who see “Scrum A, B and C” (I was going to post a link here to Jeff Sutherland’s blog but it appears he’s removed the post). Now there is a schism in Scrum: there are two bodies awarding Scrum certification, Scrum Alliance who’ve been around for a while and a Scrum.org backed by Microsoft and Ken Schwaber.

One of the good things about Scrum was that it was clear about what it was and was not - unlike Agile. This increasingly looks in doubt. As Scrum has grown more popular variations have set in, differences in certification and types of Scrum only add to those differences. The danger for Scrum is that it goes the way of the word Agile and becomes all things to all men.

That risk is echoed in the wider Agile family now. I welcome the rise of Kanban, not just because I think its a good system but because I think it is offering opportunities to think again about how we do things. But the end of the Scrum hegemony could leave the Agile as a whole fractured and incoherent, and decidedly not the type of thing corporations should be involved with.

Worst of all, it could see a new methodology war. There would be no winners here, only looses. Scrum and Kanban, and all the other methods, shouldn’t be rivals just alternatives. Unfortunately between the method zealots and in the commercial market I fear that message will be lost.

Jax slides

The slides from my Future of Agile presentation to this weeks Jax conference in London are now online. Although this talk started as a revision of last year’s Future of Agile (at ACCU and BCS Bristol) it ended up as a rewrite. The essential message is largely the same (key message: The future is lean) it brings out some new themes (e.g. software craftsmanship).

Later this month I’m presenting longer version of this talk to the BCS PROMS-G group in London as part of their Agile spring school, itself a repeat of the Bristol BCS Spring School last year. The longer version will include more on how to go about changing from where you are today to where you want to be.

Last words on architects

Time to bring this mini series to an end. I’ve talked about

• Segmenting Architects
• Architects who aren't
• Architecture or Design?

As a quick rule of thumb consider:

• The Product Owner (Produce Manager/BA): is concerned with the What
• The Project Manager: is concerned with the When
• The (your type of) Architect: is concerned with the How

And some closing advice:

• When you have a software system to design or fix, look to an architecture team not an individual. The team can share the vision in creating and exploitation.


• Never, ever, give someone the title Architect: give them the role yes, but never the title. Once you give them the title it is difficult to remove. And since you don’t know how their ego will respond you risk creating an problem. Architect is a role, not a title. Give people architect responsibilities but make sure they are still defined as a Software Engineer or whatever term you use were you work.


• The moment an “Architect” asks for an expensive tool to draw UML in then its time to let them go. UML can have a role but it isn’t worth spending money on. Expensive tools allow people to hide, architects shouldn’t hide. A cheap tool might be acceptable but don’t let them hide behind it.