allan kelly

Behind the scenes Kevlin Henney has been busy the last few month soliciting and editing contributions to a new O’Reilly web publication entitled 97 Things Every Programmer Should Know.

I’m proud to say a couple of my contributions have made it into the list:

• Check your code first before looking to blame others

and

• Two Wrongs Can Make a Right (and Are Difficult to Fix)

Other contributions are from names which will be familiar to ACCU’ers: Michael Feathers, “Uncle” Bob Martin, Pete Sommerlad, Pete Goodliffe, Klaus Marquardt, Giovanni Apsroni, Jon Jagger and of Kevlin himself. Plus there are are contributions from many others.

Just don’t ask me why it is 97 and not 98, 99 or 96 things. 97 it is.

Just in the nick of time I resolved my baby sitting dilemma and made it to Tom Gilb’s SPA London talk, only missing the first 10 minutes. Here are a few notes I took – I don’t think I missed anything radical in the first few minutes but if I did I’m sure someone will correct me.

Quantification
As always Tom was provocative and seeded a lively debate with the audience. As always Tom pushed for quantification and measurement of what software work is trying to achieve and how successful it is. And, as always, many in the audience pushed back on this.

Without going into too much detail: Tom says you can quantify just about anything, and for a software development you should. Many other people question whether you can quantify everything, whether it is necessary to quantify and if it is cost-effective to quantify.

I see both sides of the debate. I tend towards Tom’s point of view but I understand the reservations and share many of them. I also think there are some things it is extremely hard to quantify. Tom has this skill. Many others don’t and one of the results is a lot of bad quantification, bad metrics and consequently lots damage done.

Agile
Agile is not doomed the way the talk synopsis made out. Indeed the conclusion is much more that Tom’s methods – Evo and value management – are complementary t o Agile and specifically Scrum.

He didn’t address the “XP is already dead” quote until he was questioned at the end. This assertion seems to be based on the assumption that XP was mainly hype and now the hype has gone XP has gone.

Where Tom sees Agile methods going wrong is in the lack of understanding about what needs doing, for who it needs doing and a focus on “features” over “performance.” I agree with him here, I’ve blogged and written elsewhere about this problem myself (e.g. Requirements: the next challenge). I even gave a talk at the BBC a few years ago entitled “What’s wrong with Agile”.

Tom does believe teams need managing. Although he didn’t say as much that implicitly rejects one of the pillars of Scrum: the self organizing team. I don’t think Tom wants to see a return to command and control management – far from it – but he does see a need for active management. And that brings us to the next point.

Stakeholders and Product Owners
One of Tom’s key point is the role of stakeholders. That is, the need for all software development work to identify the stakeholders in the work and what they value from the work. Different stakeholders have different values and want different things, and these things change over time.

Tom asserted that stakeholder identification and management is not covered by Agile methods. Last night I thought “I’m sure it is in…” but now I look through my collection of Agile books I see its pretty thin on the ground. That said, there aren’t many references in Tom’s own Competitive Engineering book either.

As far as I am concerned, stakeholder identification, communication and management falls firmly within the Product Owner role. This is part of what Product Owners need to do when they are off the Agile stage and is part of the reason this role is so important.

At one point Tom stated that the Product Owner role dooms the project. I challenged him on this and it turns out we are in agreement. The doom occurs when the Product Owner is not managing the stakeholders.

Value over stories
Stakeholders have needs. Agile teams often interpret those needs as features. Tom suggests that User Stories feeds this assumption. I’ve blogged about this before: Requirements not functionality.

Tom proposes that by understand who the stakeholders are and what they value we can start to deliver value rather than features. Now I believe User Stories can be used to communicate this if they are written to communicate this. Tom’s own alternative to User Stories – Planguage – emphasizes the quantification, and thus value, more then User Stories. That said, Planguage is more difficult to pick up and use than User Stories.

Value driven planning
When Tom puts all this together you get Value Driven Planning. Here the idea is that critical stakeholders determine the value of software work.

Naturally there is conflict here as stakeholders argue about which work has the greatest value. The important thing is: conflict is natural. It is not resolving the conflict which is the problem. Once conflict is identified it can be resolved.

Potential v. Delivered value
Another key point to understand is the difference between potential value and delivered value. Too many projects have potential value which is not delivered because the software is not used, the users understand how to use it to the full or something else gets in the way.

It is not enough for the development team to measure the value they think they have delivered – e.g. functionality that can be used. They need to measure what value is created.

When there is a difference between these two numbers then it is time to act. If potential value is 1024 and actual delivered value is 500 then there is a lot of value being lost.

Scaling
For me a lot of this debate comes down to scaling. In small teams, with few stakeholders and small(ish) budgets doing a lot of stakeholder analysis, quantification and measurement may well be more expensive then just doing it. As was pointed out by someone, the trial-and-error approach of iteration works well, and cheaply.

When there is a big team, many stakeholders and this a big budget then not only is it worth making these investments it is necessary to ensure the team is doing the right thing, that everyone agrees on what is being done and understands why, and that the budget is justified.

Perhaps that my biggest “take away” lesson from last night.

In the end…
As you might tell, and is often the case with Tom, he hits you with hundreds of ideas many of which are left hanging there for you to follow up or thing about later.

The conclusion to my previous blog entries this week (The Doom of Agile, Thursday and Tuesday. ) is: Tom doesn’t really disagree with Agile, he is highlighting a issue others have seen and wants to shift the focus.

If you are interested Tom’s slides can be downloaded (be warned, this is a big presentation, 23Mb in PPTX format). Mark Stringer at AgileLab has some comments on the presentation too.

A post script to my last blog entry (“SPA London, Tom Gilb and the doom of Agile”) generated some comments and a couple of private e-mails.

I think Mark is right when he commented: “they are ‘fads’, the hope is they will just become nameless best practices”. Many of the Agile practices were already best practices in places, but until they were named, publicized and, yes, hyped, few people knew of them.

Have a look at EPISODES from 1995, thats 4 years before “XP” and 6 years before “Agile”. Its documenting best practices. Or one of the earliest attempts to document Scrum, The Scrum Pattern Language in 1998.

Both of these are patterns, which means they document what is being done, not what is suggested. they are documented because people think these are good practices.

One day, the Agile “hype” will fall down and what we are left with is the practices. Thats what I was trying to say when I wrote “ If XP is dead then it died so Agile might live.” The hype around XP is less, much of XP has already become best practices – think of TDD, think of daily stand up meetings. Obsessing about XP is wrong but doing the XP things is right.

Thats why I also agree with Rob Bowley’s comment when he wrote: “XP is here to stay (as much as Agile is) because through time it has proven to be effective.”

We may dislike hype but its part of the way the world works. Object oriented programming, UML, ISO 9000 and CMM have all been hyped and left their mark. SOA is hyped today, it means a lot to some but technically its just a continuation of modularisation (first there were static libraries, then there were objects, then components and now services.) Without hype people wouldn’t get to hear of these things. That’s why Simula and many other technologies have fallen by the way.

We might argue over which Agile method is best: XP, Scrum, Kanban?
We might disagree over which practices are applicable: TDD, BDD, stand-ups?
Or how to implement these ideas in unusual environments: distributed teams?

But I don’t see anyone seriously arguing for a return to to “waterfall”.

I still hope to make it to Tom’s presentation on Wednesday but we seem to have a baby sitting clash so I might be grounded. Won’t know until the last minute unfortunately.

I’m planning on going to SPA London session next week, Tom Gilb is giving a talk entitled “Does real Software Practice Advancement need yet another ‘Manifesto’? ” He’s being quite provocative, look at this from the synopsis:

“AGILE HAS DOOMED ITSELF – TO BECOME YET ANOTHER FAD: XP IS ALREADY DEAD. What is Seriously Wrong with Agile practices and interpretations – why AGILE, AS CURRENTLY PRACTICED, is PROJECT-failure-prone as a culture.”

I think Tom is both right and wrong. He is right that projects need more of a value driven approach, he is right that Agile is a fad but he is wrong to say XP is dead or Agile is doomed. Personally I’ve been expecting an “Agile backlash” for at least two years now, and to some degree I think it deserves it.

I too have concerns about “Agile” both the marketing of it and what lies below. The term is very vague, covers a multitude of things and is often abused. Its fair to expect it to come down a peg. But, now I look too faced, and you may be asking “Why does Allan talk a lot about Agile?” the answer is simple. Its the best tag we have at the moment, its the best term for grouping all these ideas together.

Lets take the synopsis one part at a time.

“Agile has doomed itself”: perhaps, the term is poorly defined. As a result a lot of bad practice hides behind the Agile label and gives Agile a bad name. Still there is a lot of good in there.

“[Agile] is another Fad”: certainly there is a lot of hype, much undeserved and certainly this will blow over. As bits of Agile become mainstream some of that will go naturally. But some hype is necessary, its called “marketing” and its all around us. The Agile bubble will deflate, it might get pricked but thats not a reason to attack it alone.

“XP is already dead”: I’m sorry to see Tom adopting this view. XP’ers were the storm troopers of the Agile movement. The very word “Extreme” meant it would repulse some people. But XP got people listening, got people excited and now XP takes a back seat.

Look at what XP has left us with: Test Driven Development, Continuous Integration, Refactoring, simplicity in design – the technical practices which underpin Agile development.

XP’s project management side was always a bit weak but it isn’t that different to Scrum. Scrum finesses it a bit, makes it more acceptable to management, adds in some bits that were missing and tightens it up but the two are the same. If XP’s project management is deeply flawed then so too is Scrum.

So XP is still with us, it just split in two. If XP is dead then it died so Agile might live.

Hopefully the talk will explain the rest of the synopsis.

Now why Agile is a success and is here to stay. There are three parts to this, one especially for Tom.

First, as I’ve argued again and again, Agile software development is a branch of Lean thinking, in particular Lean product development. Lean has been around for a long time and for about 20 years has been documented, studied and been something of a “fad” itself. As such I don’t think Agile is going away, but I think we will see more use of the word Lean.

Second is the name factor. “Agile” is a solution, it is a solution to slow software projects, it is a solution to poorly run software projects, it is a solution to poor quality software, it improves team performance and customer satisfaction. Yes “Agile” is a vague term but it is a label for all those things.

Go searching on Google for any of those things. You’ll find what you want, eventually. You will need to dig through lots of stuff first. Yes “Agile” is something of a marketing term but it is a marketing term that labels a whole set of desirable outcomes and ways of achieving them. As such it is short hand for finding ways to make software work better.

Finally, there are lots of different pieces make up the “Agile” toolkit. Scrum brings Project Management. XP brought better quality software – a crown inherited now by the Software Craftsmanship movement. Crystal (remember that one?) and Lean bring continual improvement. Elsewhere I’ve written about Agile governance, and so the list goes.

Tom and Tom’s Evo method brings important tools to that toolkit. Evo pinoneered short iterations. Evo emphasizes value delivery. Which leads us to better requirements understanding and governance. Evo emphasizes measurement. Planguage gives us another way of documenting requirements. And so the list goes on. If you are not familiar with Toms work then its well worth a look, lots of good ideas.

But, Tom’s ideas aren’t the whole toolkit. XP, Scrum, Lean, Kanban, etc. all bring something to the party, its up to you to decide which guests you want.

On the one hand I find it ironic that Tom appears to be attacking Agile. For me Evo is an Agile method. Evo shares common roots with Agile, namely the work of Edwards Deming. On the other hand, I enjoy Tom’s ideas, he’s thought provoking and I always learn something. Maybe he’s just getting some of the Agile hype for himself.

I have been preparing some training material for a company which wants to know more about how Agile projects fail. Fortunately I’ve made a habit of recording Agile failure modes in this blog so I have much of the material to hand. (Use the search box above and search on “Agile failure modes.”)

But, I’ve not got exclusive rights to this topic and others have done the same thing, often with catchier names. So, for completeness:

• Wagile from Jason Gorman
• ScrummerFall from Mitch Lacey
• ScrumBut from Eric Gunnerson
• WaterScrum from Scrum Community

As far as I can tell these are the original sources of these terms but I may be wrong. Others have also used the term and some have Wikipedia entries so I could be wrong.

The Agile Journal this month has an article from me this month entitled Dissecting the Product Owner role.

This complements my pieces on the Business Analyst and Product Manager roles which appeared in ACCU Overload earlier this year.

I’ve finally, about 6 months after everyone else, got around to reading the Software Engineering Institutes report on CMMI and Agile. Entitled “CMMI or Agile: Why Not Embrace Both!” the report argues that CMMI and Agile are not only compatible but complement one another. Actually, you can guess at what the report says from the fact that the title ends in a exclamation mark (“!”) rather than the question mark (“?”) you might expect.

The report argues that the two are compatible and complementary. They make a strong case and I for one am glad. CMM initiatives have too often made the words “process improvement” dirty words. They shouldn’t be, it is what we should be doing.

The report argues that CMMI, and its predecessor CMM, have been misunderstood and misused by the industry. Firstly CMM(I) was taken to be a methodology when it was a model. CMM(I) doesn’t tell you what to do, it allows you to evaluate your capabilities.

The second mistake compounds the first by imposing CMM(I) on organizations. Rather that improving an existing process and organization CMM(I) initiatives have replaced what already exists with something else – and in the process destroyed the good that existed. This is the scenario I wrote about a few weeks ago in “A true story about CMM”.

There are a few points were I could take issue with the report.

My first issue is that the report does not define what it means by ”Agile.” I agree this is a problem, and one I’ve been thinking about addressing in this blog. But, CMM and CMMI are very well defined while Agile is not. How can one critique a method without defining what is mean by the term?

Second, the report seems determined to identify an “Agile Institute” to mirror the Software Engineering Institute. It seems to spend a lot of time talking about the authors of the Agile manifesto and founders of the Agile Project Leadership Network. Neither of these groups owns the term “Agile” or speaks for the whole Agile community. There is much under the Agile umbrella which, rightly or wrongly, falls outside these two groups.

Comparing Agile and CMMI is an asymmetrical comparison. One is clearly defined, with a well funded champion to issue standards, revisions and issue certificates. The other is the ill-defined product of an ill-defined community which owes as much to the punk ideal as anything else.

A bigger issue with the report concerns why you might want to bring CMM(I) and Agile together. The report spends several pages early on explaining that the CMM grew out of one type of environment with one set of problems. Namely large projects, often military in nature, often with life at risk, and with a low-trust relationship between supplier and client.

Conversely, Agile came from a different environment: mainly corporate IT groups, small projects (no more than a dozen or two people), with high-trust within the team. Failure to understand these origins and contexts has led to much misunderstanding between advocates of the two.

Given that these two environments still exist, and that Agile has demonstrated success in its native environment and CMM(I) has demonstrated success in its native environment, then why would people in either environment want to adopt elements of the other?

I don’t think this question is really answered. This is a shame because the authors have spent a lot of time setting up a story to explain why we got where we are today but don’t explain how that story ends.

To my mind the story only tells part of the truth. Both CMM(I) and Agile have been sold into many organizations outside their native environments. There are many people who want the respectability of CMMI, and there are others who want the fashion of Agile. Nor am I aware of anyone in the Agile or CMMI camps saying “Don’t do that sort of project with our model.”

I’ll defend Agile here because I believe Agile has, and is, a journey of exploration. The underlying principles are universally applicable but that doesn’t mean all the details are worked out in any given field yet. So if you ask me “Can I do Agile on an X type project?” my answer is “Yes but I may don’t know how immediately.”

However the SEI folks who wrote this report claim CMM(I) has been misapplied. So I ask: which of them was saying “Don’t use CMMI on an X type project” ?

My final niggle is one of clarity. The report has five authors. Several of those authors are quoted and referenced throughout the text to support the arguments made. Yet nowhere in the report, when one of the authors is quoted is there a disclaimer. That is, the report does not say “Smith, one the authors of this report showed the CMMI is effective (Smith 2003).”

The names of the authors aren’t hidden, there is no subterfuge but its not clear and I wish they had been.

On the more positive side there are several quotes in the report worth calling out. About Agile and CMMI:

• “In today’s increasingly dynamic world, CMMI-based organizational process improvement approaches cannot rely exclusively on traditional project management approaches, waterfall-based project lifecycles, and heavyweight analysis methods.”
• “CMMI and Agile can complement each other by creating synergies that benefit the organization using them. Agile methods provide software development how-to’s that are missing from CMMI best practices that work well”

And about CMM(I) and the approach companies have taken in the past:

• “Too often, CMMI has been applied rather than implemented”
• “SCAMPI appraisals are not audits or tests”
• “the complexities of large-scale projects require a more involved infrastructure, this fact is not a license to create unnecessary bureaucracies and unbalanced production at the expense of productivity”
• “Using process experts to create and deploy process improvement activities is not unusual, and often has the advantage of allowing these experts (and the project teams) to focus on their respective tasks. But what makes this approach risky is that project personnel are frequently left out of process design activities and are disinclined or openly skeptical toward the adoption of process improvement activities. This situation is typical of some Six Sigma style approaches to process improvement as well. Quality process teams are created and given the responsibility for quality. As a result, developers abdicate their responsibility for improvement (or worse, for quality).”

Interestingly I also noticed that the SEI’s own Team Software Process (TSP) is now listed as an Agile method. I’ll have to look into this some more.

I am also please that the report highlights the role of organizational learning in software development. Regular readers know this is something I’m very keen on (heck, I wrote a book on the subject!) so I’m pleased to see it explicitly considered.

Even with my reservations I welcome the report. I believe it is a roundabout endorsement of Agile (in its various forms) by the Software Engineering Institute. It is also a very big sign saying “Agile and CMM(I) are compatible.”

At the end of last year, or was it the start of this year, I wrote a blog entry which got a lot of attention: Leave your laptops out of meetings. I was talking specifically about laptops but I could have easily included Blackberries, iPhones and other portable devices.

In todays Financial Times two professors from Toronto Rotman School of Management make the same call: Why e-mail must disappear from the boardroom. Their piece specifically addresses e-mail and boardrooms but its the same argument I was making.

Professors Beaty and Weber wonder what how directors can concentrate on discussions when they are doing something else. And the question what will happen when someone decides to sue a company for decisions taken by directors who are not concentrating.

So there are three good reasons to leave your laptop out of the meeting, switch off your Blackberrry and ignore your SMS messages:

1. You cannot do your job properly is you trying to do two things at once
2. You are opening your company to negligence claims
3. It is rude; you are insulting the people who are in the room asking for your attention

For the record I very really take a laptop to a meeting, only really if I have something on it I want to share. I don’t own a Blackberry, iPhone or other portable e-mail device. And I set my mobile phone to silent when I arrive at an office.

I am guilty of occasionally viewing an SMS during a meeting, and even more occasionally sending an SMS during a meeting. I apologize to everyone in a meeting where I have ever done so.

I fully support Beaty and Weber’s call: think of the message and example it would send if a company board stated that Blackberries and laptops were not to be used in meetings.

I recently came across the expression “The Scrum Wall”, as in the expression “Hitting the Scrum Wall”. Its akin to “the pain barrier”, or “feel the burn” in aerobics workouts of old.

Once I heard it I knew what it was, I’ve talked about this before, now I know it has a name.

The Scrum Wall is the thing Bob Martin described at the ACCU conference. And it is probably why Jeff Sutherland endorses Test Driven Development and other technical practices from XP.

You hit the Scrum wall when you adopt Scrum and everything goes well, then, after a few Sprints things don’t work any more – to use an English expression, they go pear shaped. You can’t keep your commitments, you can’t release software, your customers get annoyed and angry, it looks like Scrum is broken.

This is what happens when you adopt Scrum without technical practices such as Test Driven Development, continuous integration and refectoring. When teams adopt the Scrum process, they go faster, show progress, things look good… and then the quality becomes a problem. Now the team are fighting through quick sand.

The code quality is poor and developers are expected to continue to make progress. Maybe the Scrum Master/Project Manager reverts to past behavior and demands overtime and weekend working. Maybe the team start busting a gut to keep their commitments. Either way the team is heading for burn-out.

That’s the wall.

About a decade ago I worked for a major supplier of financial information in London. The company decided it wanted to improve its software development process and the answer to this problem was to adopt CMM – the Capability Maturity Model. Initially the become level 2 and then move on the level 3.

The little group I worked in interfaced to financial trading institutions in the City of London. My project in particular had to respond quickly to changes at the institutions.

The CMM roll-out was a akin to a neutron bomb in reverse. The people were left in place, but their processes and practices were replaced en-mass. Developers attended CMM training and instructed in how to develop software according to the new process.

The effect was devastating. One manager likened it to pouring quick setting concrete on the railway tracks of progress.

I went out and I bought myself a book on CMM so I could understand it. What I learned was that CMM was a way of measuring maturity. It was a meter, imaging it as a ruler. It was a way of assessing your organization. You could measure yourself as 1 CMM, or 2 CMM, up to 5 CMM. It was not a method of working.

The CMM body of knowledge also contained recommendations, “best practices” and examples of good practices but it was not itself a process. It was a meter for measuring your maturity.

From the book I learned that Watts Hymphrey advised companies to: focus on improving their processes first and let the CMM measures improve by themselves.

What I observed in practice was the destruction of working practices an processes. I never observed any attempt to involve those doing the work in process improvement. The consultants knew best. Opposition was to be overcome. Process improvement was something that was done to others.

This wasn’t the company for me and I left. The company was eventually certified as CMM Level 2 and was expected to move to level 3 in time. Time went by and I don’t think the company ever made level 3. I heard that internally CMM was recognised as a mistake and the work was quietly allowed to die. The company also announced major moves to offshore development.

Fast forward to 2009. I recently met someone who was an outside consultant to the company and advised them on CMM adoption. He told me that he, and the other consultants, had advised the company to build on the practices they had and improve them. They specifically advised them not to write new processes and impose them on people.

He also told me that when the company did its own retrospective on the CMM project it was seen as a mistake to have written and imposed new processes on developers. A far better way would have been to improve what was in place with the people who did the work.

So the moral of the story:
• There is a lot of good in CMM – and the more recent CMMI.
• CMM itself is not a process, it is a meter, it is a means of measuring yourself.
• The key is process improvement, focus on improving and the levels will come.
• Don’t replace, improve, evolve. Involve your own people.