Inbound & Outbound marketing

Its nearly the end of the year, I’m about to close one Blog archive and start another - don’t worry, this means nothing for readers, its part of my admin. But it does mean that I put behind me all those half written blog posts, and single line ideas, that have been building up during the year.

Before I do so though, there are a couple of days to quickly get important backlogged entries out!

Two weeks I blogged, not for the first time, about Product Manager (Product Management an open secret, a differentiator). When I talk to people about Product Managers I often find myself in a conversation about marketing. Clued up people realise that good Product Management is, in part, a marketing function, others are surprised. They think marketing is about advertising and sales.

It is important, very important, to differentiate between the two sides of marketing: Inbound and outbound. So, for the record, I want to record it:

Outbound marketing: is the marketing most people think of when someone days “marketing.” This is about letting people know you, and your product, are here. Its advertising. Its public relations. It is generating sales leads. It is improving awareness. You get the picture?

It is called outbound because it is from you and your organisation to the wider world.

Inbound marketing: is from the wider world (customer, potential customer, competitors) to your company. It is about bringing that information inside and then acting on it. It is about building the products your customers want to buy. Get it right and sales should be like a knife through butter, people want your products.

In software companies, and other tech companies inbound is largely the role of Product Management. Product Marketing is about outbound. Although Product Manager is the usual job title some places call this role an Architect, others Programme Manager, and occasionally Project Manager. More often or not it is just absent.

Most companies realise, sooner or later, that outbound marketing is needed. Unfortunately, in all too many companies inbound marketing does not exist. Or inbound is “what the sales guy says the customer wants.”

As much as we love sales people (after all, they bring in the stuff that pays us) they are not the best people to decide what goes into a product. The reason why they are good at selling is that they get over customer objections and sell the product. This means the customer, the next customer, the next sale, is king. What the next customer wants isn’t what every customer wants.

Lets make this simple: if you are running a software product company and you don’t have a Product Manager then get one.

ACCU 2011 Conference registration open - beat the VAT rise

Just in time for Christmas, that special present for someone you love...

Buy them a place at the ACCU Conference in April.

If you live in the EU you have an very special reason to buy in the next few days: the UK is increasing the VAT rate so the price is going up on 1 January.

If you really want to save money, and you are not already an ACCU member then join the ACCU now, and immediately book the conference. It is cheaper, honest; no, its not an accident, it is meant to be like this.

I’ll be there, in fact I’m speaking, I have two sessions, one on requirements and one on patterns.

(Twitter tag for this is #accu2011)

Dialogue sheets, retrospectives and quotes (Send me your quotes)

Know any good quote about software development? Agile? Lean? Teams? Code? or anything else in this space?

I’m working on a little project and I need some though provoking quotes so please send them over - leave a comment here, e-mail me (allan at allankelly.net) or Twitter me (allankellynet).

Why?

Well, I’m working on a little project for retrospectives I’ve been dreaming of for a few year and I need some thought provoking quotes.

There are two problem I see with retrospectives - OK, there are other problems but there are two I think I can do something about. (And none of these problems undermine the reason for doing retrospectives or the value, just fly-in-the-ointment stuff.)

Firstly, retrospectives need a facilitator. That might not sound like a problem but ideally you want the facilitator to be a) experienced, b) impartial, c) available. Sometimes its not easy to find that person.

Second, I hear of teams who hold regular retrospectives but the retrospectives because boring, they go over the same ground again and again. To be effective, to get new insights they need jazzing up once in a while.

One way to resolve both problems is to use an outside facilitator once in a while but that needs organization and, most likely, money.

So, what if you could have a retrospective without a facilitator?

Over the last few years I’ve been experimenting with a technique called a Dialogue Sheet. Both in training and conference sessions I’ve used this to facilitate discussion. For more about dialogue sheets see my website with examples from XP Day, SPA and “Lean into Action” at the Agile Lean Exchange last month.

Now I’m working on a Retrospective Dialogue sheet. The idea is a team us this for a facilitator-less retrospective.

I hope to have the sheet ready by New Year and then I’ll be looking for some guinea pigs...

And the quotes: these get placed around the dialogue sheet to provoke thought and reflection.

When I’ve got this working I hope to allow you to download these sheets from my website or order printed versions directly.

Product Management an open secret, a differentiator

At the Skills Matter Agile Lean Kanban exchange the other week someone - sorry I missed you name - told me about a report from the BBC on Product Management. It turns out the report is from a branch of the BBC I didn’t know about, “BBC Academy” and it entitled “The State of Product Management 2010.” Its well worth reading if you have an interest in Product Management or the UK software development scene.

Although I’ve not blogged about it for a while Product Management is one of my passions.

Think of the development team as the beating heart of the work effort. Someone has to keep the blood flowing, someone has to keep the arteries clear and make sure the right requests for work can channelled to the development team.

This is a role. Someone needs to do this. Someone needs to understand customers and be in a position to prioritise. And someone needs to be able to have ongoing conversations with customers, developers and everyone else.

This is not a document, attempts to do this with a document makes things worse. Documents don’t have conversations. Documents are static.

One of the reason why Silicon Valley companies are so successful is that they understand this. In Silicon Valley there is a well developed role called the Product Manager. This is the person who looks at the customers, understands their problems and needs, looks at the market and a whole bunch of other stuff, and this person decides what is needed for a successful software product.

I point to Silicon Valley because certainly in Europe, and I suspect in much of the rest of the USA, this role isn’t so widely recognised.

This role doesn’t exist in corporate IT. Here the Product Manager’s cousin the Business Analyst fills a similar role but in a very different way. However, there is change afoot here, stay with me.

Here in the UK I find I have to explain this role to clients again and again. They make four common mistakes:

1. They assume the development team just know what is needed. Sometimes they do, sometimes they don’t. They may get luck once but can you rely on luck the second time? Third time?
2. They assume that the Project Manager knows. Again this is wrong, Project Manager training is about delivering a defined project to a date within constraints. It is not about understanding customers. (True there is overlap but Project Managers training is different.)
3. Experience IT Managers see the need and appoint a Business Analysts. This is the right thing to do when you are a corporate IT department, or if you are writing bespoke software for one customer but, if you are trying to create a product to sell to many customers it is the wrong choice.
4. Managers assume it is obvious, or that they, the “managers” know. If they are Product Managers or have been Product Manager they might be right. Even if they do know what the customers want someone has to explain it to developers and be on hand to answer their questions. Senior Managers just don’t have the time.

So its good to see the BBC highlighting this role. The description in this report is very media centric but it is recognisably the Silicon Valley Product Manager role. There are some good case studies in the report.

As I said, over in the corporate IT world this role doesn’t exist because customers are captive. One of the key aspects of the Product Manager role is understanding what customers (who have a choice) will pay for. In the corporate IT world this doesn’t exist: you get what you are given. So the BA role is similar but different. (There are other difference but they are for another day.)

(Interestingly several of the Product Managers quotes in the BBC report state they have Business Analysis backgrounds.)

The thing is: Business Analysts need to become more like Product Managers because more and more corporate IT departments are creating systems for external customers who do have a choice.

For example, 15 years ago just about all the IT created by travel companies was for their own use. Today travel companies have customer facing IT systems which can both win and loose the company sales. Online offerings are part of the buying experience, part of the customer experience and a potential product differentiator.

Even though the Product Manager role is not as well understood as it should be it is becoming more important. For those who get it Product Management is a potential differentiator.

Return to Requirements @ Skills Matter

I’m presenting a Skills Matter In the Brain Session this week, entitled “Return to Requirements.”

The key thing about this presentation is that it give a very very brief overview of the “Agile 10 Step” which is the model I use to discuss requirements in Agile work.

It is Tuesday 14 December, 6.30pm to be exact. Its free but you need to registration is required.

Salami Agile

More than one software development team has encountered the situation when the team want to be more “Agile”, the organization and management might even be asking them to be more “Agile” but, there are still many “requirements” in a big requirements document and the expectation is that all these will be “delivered.”

Ideally I would not set up and Agile development like this. Yes I’d set a few requirements to seed the first iteration but I would take a more goal directed approach. I’ve written about this elsewhere - see Time for Goal Directed Projects.

Basically Goal Directed means: the team have a goal, the team will determine what needs doing (requirements) and do it (implementation) as part of the same project. The team will be staffed with everyone they need to do both sides of the work (BAs, Developers, Testers, etc.) and will be judged by their success on reaching the goal. They will not be judged on how many features they implemented from some big initial set.

But, as I started by saying, some teams do have a shopping list of things they are expected to deliver and they will be judged on how many of those items are delivered and when.

So what do they do?

This is where Salami Agile comes along.

Think of the Big Requirements Document as an uncut piece of Salami. Someone on the team - preferably someone with Business Analysis skills but it could be a developer, project manager, or someone else - needs to slice the requirements into thin pieces of salami (story) for development.

There is no point in slicing the whole salami in one go. That would just turn a big requirements document into a big stack of development stories. The skill lies in determining which bits of the document are ready (ripe) for development, which bits are valuable, and which bits can be delivered independently.

Some slices of salami will need to be thicker than others but thats just the nature of the world. Over time, with more skill at slicing salami it will improve.

Ideally, the pieces of salami are delivered to the customer early, and over time they start to realise they don’t need some parts of the requirements document, some salami can be left unsliced and simply thrown away. Other pieces of salami will be cut and then thrown away. Thats not failure that’s reducing the work and is good.

And some requirements which were not though of can be easily incorporated. To stretch the analogy, you switch from German Salami to Danish Salami and back again if you so choose.

I imagine some readers will recognise this development approach, good. Now we have a name for it: Salami Agile.
(Picture from André Karwath on WikiCommons under Creative Commons Attribution-Share Alike 2.5 Generic license.)

Agile in Cornwall

As I’ve mentioned before, one of my current projects is to help companies in Cornwall adopt Agile software development. The programme is bring run under the Grow Cornwall umbrella by Oxford Innovation.

Next Thursday there are two open to everyone sessions to introduce Agile to companies in the Cornwall area and talk about the work we are doing.

If your interested you need to register at MeetUp - “Agile in Cornwall - Meet the Experts.”

Three plans for Agile (long version)

As noted in my last blog entry RQNG has published my description of Agile planning using Iteration plans, Release Plans and Roadmaps. I’ve added a little bit to this an produced a longer version of the same piece - it only adds about a page.

Three Plans for Agile (long version) is now available on my website.

Three Plans for Agile on RQNG

RQNG has published one of my articles entitled “Three Plans for Agile”. This looks at the role of iteration plans, release plans and roadmaps, and how the three fit together.

I have to say thanks to Jon Harley, we had an e-mail discussion months ago which was the seed of this article.

After writing this I discovered (I’d like to say remembered but truly, I’d forgotten) that I actually blogged about this early last year as part of my Project Plans mini-series.

Reverse-Tolstoy continued - from Agile EE

In my last posting I suggested thatif Leo Tolstoy worked in a corporate IT department the opening lines of Anna Korenina might have read:

“Unhappy corporate IT departments are all alike in the same unhappy way; all happy departments are happy in their own way.”

I call it Reverse-Tolstoy (because he actually wrote the reverse, well kind of). I want to continue that rant with some other ways corporate IT departments repeatedly mess up.

Belief that process change is it
I wrote in my previous entry that corporate IT departments do not focus enough on the technical side of Agile, specifically they don’t think about code quality and technical practices. Part of this is caused by a belief that process change is the change they require. That is to say, that changing the process they use, whether that means “Agile” rather than “Waterfall”, or Scrum over ISO-9000, or Kanban over ad hoc, or what ever, well, thats the change they need.

Such a view ignores the technical side of change required. As I’ve said before, and I’ll say again, I don’t believe you can be Agile if you don’t address the quality issue. I also believe that the best place to start your Agile change is with the quality improvement (thats a TQM, ISO9000 or Six Sigma quality programme by the way).

No customer involvement
For these IT departments actual, paying, customers are a long long way away. This is changing a little but most of the customer they have are internal, i.e. other parts of the business. These customers have little involvement in the development of IT system. Indeed, you will frequently be told that they want minimal involvement.

The internal customers have an image that they can hand over and idea, sign a requirements document, and leave IT to get on with it. They might get involved in some acceptance testing but they don’t want to hear about it before then.

I think this view has been encouraged by corporate IT. I think IT as an industry has trained customer very well, customer now believe if they just write it down, hand it over then it will be. Kind of double-think really because most customers have also seen IT failure. However, they think its “IT failure”. The idea that they, the “customers”, might be part of the solution is strange to them.

Instead they cling to....

“Long” UAT cycles that are separate from development
UAT, User Acceptance Test, the thing that the “business side”, the people who want the software do to ensure you deliver what they originally asked for. Having thrown it over the wall, having waited, having complained the “customer” wants make sure you deliver what they asked for. So the have a user acceptance test cycle.

Unfortunately this normally comes too late in the day to make a real difference, and, real “users” don’t actually want to be involved. So you often find UAT is carried out by dedicated UAT testers who don’t actually do the customers job.

UAT ends up being just another test cycle. All too often it is where real testing takes place, by the time the software reaches UAT it is still buggy. Rather than being about seeing if the users like the software UAT is about finding bugs.

UAT is normally one of those “no go” areas when you start talking Agile. Frankly, the business doesn’t trust IT enough to believe they will deliver anything, let alone that it is of high enough quality or actually meet customer needs.

Personally, I think you can abolish UAT, but I don’t want to try until I’ve fixed the quality problems in the team and got the basics of Agile up and running. But during this time people keep waving big red UAT flags warning you not to mess with UAT.

This is another example of....

Adherence to existing processes and constraints
All the companies have existing processes in place. Many of them are simply “off limits.” You get looked at as if you are mad when you suggest they annual planning cycles aren’t Agile, or time tracking systems are pointless.

The trouble is, too many of these “off limits” areas and you end up with no change. One big off limits process is the time tracking system....

Time tracking systems - measuring inputs not outputs
Nether mind that time tracking is an act of fantasy on a par with Arthur Conan Doyle, or that it wastes a lot of people time and even more energy one thing that is never on the agenda for change is time tracking.

All these big companies seem addicted to measuring inputs rather than outputs. They know the cost of everything and the value of nothing. Or rather, they think they know costs but really the time tracking systems are so hopelessly inaccurate they don’t reflect what is actually happening.

Time tracking gets really dirty when resources are not visible, that is, when they are offshore. Manager worry that their teams aren’t working hard enough but my experience is the teams are working to hard and just not logging all the hours - the late nights, weekends. The offshore staff thing they are “doing whats needed.” Unfortunately when this short term fix gets ingrained into regular practice its a big problem. It is also a sign, and the cause of, a lack of trust.

SWAGs “High level estimates”
Large companies like to get early “high level” estimates, sometimes called “Seriously Wild Assed Guess”. The idea is to get a ball park number for initial planning and refine it later one.

Trouble is, they don’t. The SWAG is it. It is treated as commitment and people are expected to honour it. In the worst cases the SWAGs appear to work, but thats really because the time tracking system is such a fantasy-land.

Quick Test Pro and Quality Center
All these big messed up IT departments use Quick Test Pro and Quality Center. I’ve looked at these tools, albeit a little, and my conclusion: Emperor’s New Clothes. There is nothing there.

So why so many test groups are stuck on an old version I don’t know.

Message: Save money, throw them out, get FIT, Selenium, JUnit, etc. The best things in life are free.

I look forward to the day when writing a test script in a natural language like English is a criminal offence you can be sent to jail for. If you are going to write a test script then automate it. Precise English takes just as long to write as code. (Even then it isn’t so precise.)

Not really knowing why they are doing “Agile” - seems to be the fashion of the day
At the end of the day most of these corporate IT departments don’t actually know why they are trying to be Agile. I think if they were to really think hard the answer would be Fashion. Yes it sounds good but so did Business Process Re-egineering, ISO-9000 and offshore outsourcing.

Most of the staff inside the companies regard Agile as just the latest change programme. They know it will pass in time. Yes there are some very enthusiastic people in the company, and some highly paid consultants too but that was the case with BPR, ISO-9000, and every other change initiative.

The trick is: keep you head down, look like your going along with it and wait for the next fashion to replace this one. In other words: Don’t want to rock the boat too far.

Reverse-Tolstoy, or Tolstoy reconsidered

Rather famously Tolstoy started Anna Korenina with the words:

“Happy families are all alike; every unhappy family is unhappy in its own way.”

I like many others have repeated this quote, and even applied it to business and, in particular the act of creating software. I think, although I dread to check now, that I even open one of the chapters of Changing Software Development with the quote.

I dread because I have come to the conclusion that it it the wrong way around - at least for companies, and specifically the bits of corporations which produce software but which sell something else (i.e. Corporate IT departments) the quote should be:

“Unhappy companies are all alike; every happy company is happy in its own way.”

Blame (credit?) Jason Yip and his “Problems I know you have” blog post that sowed the seeds. But after a series of corporate clients in the last couple of years I’d like to offer my own list.

Here is a quick list of the mistakes I see big corporate IT departments making in the development of software. Actually, there are too many points here, there will have to be a part 2 to this post...

Too much Work in progress
Companies ask so much of their software development groups and these groups don’t say No. As a result they have far more projects in the pipe than they can ever hope to deliver in the supposed timeframe. Earlier this year I met a manager who had about 10 or 12 people reporting to him, he was trying to schedule them to about 17 projects. Any attempts to do anything other than run all 17 at once were an anathema to him and his managers.

This leads to....

Resource foobar
For “resources” read people. There are only so many people in the corporate IT department and in an effort to do work people are assigned to work on multiple projects. So #1 their productivity drops because they are now task switching, #2 quality drops because they are thinking of so many different things, #3 predictability falls because you don’t know when they’ll be working on which project, #4 arguments follow over who should be working on what.

At one client I analysed the (highly inaccurate) time tracking system and found some people worked on 14 projects in one week. Although about 54% of employees only worked on one project a week those who worked on more than one averaged 2.7 projects per week each.

Part of the problem is...

Resource (people) pools
People aren’t allowed to stay with the same piece of code for very long. Which means those who manage them must argue over what project they are assigned to and when. And when they aren’t assigned to a piece of work, but they are the only person who can fix a problem, then all hell breaks loose which destroys the predictability of the project they should be on.

Successful sports teams (think Manchester United) don’t break the team up at the end of the season. Could you imagine the manager saying: “Well the season is over, I don’t need you for a few months so I’ll assemble a new team then, goodbye.”

Unsuccessful sports teams (think Everton, I know I do) usually sell the best players at the end of the season and need to rebuild the team at the start of the next.

Sometime they are pulled off work because of....

Year long portfolio planning
Which means the company decides on some arbitrary date what it will work on for the next year. Which supposes #1 the company has perfect foresight, #2 nothing will change, #3 all projects will run as planned.

Question: How can you be Agile if you decide at the start of the year what you will be doing at the end?
Question: Did your company have a year long plan on Friday 12 September 2008? Was the plan still valid on Monday 15 September 2008?

One side effect of this is: demand for “architects”, “designers” and such is very high at the start of the year, while at the end nobody wants an “architect” but everyone wants Testers. So you create your own resource crush.

Too many Chiefs, not enough....
Big companies don’t like coding, its dirty “engineer” work. So that is all sent offshore or hidden somewhere. Which means they need people to manage it: Development Managers, Project Managers, Programme Managers, Work Package Managers, Test Managers, Development Leads, Test Leads, and their friends the: Architects, SMEs, Business Analysts, etc. etc.

Rule of thumb #1: if the number of coders and testers working on a project is less than than half you have a problem.
Rule of thumb #2: if you find yourself sitting in a room with other (none coders or testers) discussing the work of coders and testers with none of them present then you have a problem

Of course, that assume you have a room....

Too many meetings; too few rooms (projectors, teleconferences, etc.)
When you can’t have a meeting because you can’t get a room its a sign that either you have too many meetings, or.... no, its just a sign that you have too many meetings.

When a company saves money on projectors, teleconferences kit, video conference kit, etc. it saves money on the bottom line but people waste far more value faffing around with making do with inadequate resources.

No quality practices at the code face
And when you have too many chiefs you are likely to find that all talk about “Agile” is about Iterations, Stand-up meetings, User Stories and so on.

Wake up and smell the coffee: if you can’t get quality code done Agile isn’t going to save the day. Invest in TDD, CI, Refectoring, etc. etc. While some big companies do this many don’t - many small ones don’t either but they are not the subject of this post.

There are assumptions at work here: quality is expensive, quality isn’t achievable (all software has bugs doesn’t it?), quality is something developers do, or should do, either way, its something people with dirty under their finger nails are involved with. (I talked about this at the Agile Business Conference last month, Quality – How much quality can we afford?)

Even raising the quality question can lead to accusations that the questioner doesn’t “see the bigger picture.”

(Sometime when you dig into things developers are already moving in this direction but they are doing so without making a song and dance about it.)

Hierarchy
This deserve a blog entry on its own. Inherent in Agile as a whole, but not spelt out explicitly, there is an assumption of a equality. That we are all in this together, we all have a common goal, and we aren’t going to let job titles, length of service, age or other stuff get in the way.

Unfortunately most of the corporate IT groups I’ve seen in the last few years have various people who do stand on hierarchy.

Functional silos
Why, o why, do companies organise themselves as: Test group, Development Group, Analysis Group, and so on?
No one group can deliver a product on its own.

Once you have silos you have people (managers) who need to justify and protect their silo. Solutions which mean people are more integrated worry them.

Lack of knowledge / Knowledgeable people
Another reoccurring bottleneck is the lack of people who actually understand the systems and code base. This is sometime made worse by earlier redundancy programmes.

Kelly’s Knowledge Law #1: It takes time for people to become expert on a software code base and system
Kelly’s Knowledge Law #2: Knowledge transfer programmes don’t fix this any time soon
Kelly’s Knowledge Law #3: You are where you are because of earlier decisions not to recruit more people, not to train more people and to fire people

Don’t believe me? Check out Brook’s Law

And to make things worse....

Knowledge doesn’t accrue in offshore partners
The likes of Wipro, TCS, InfoSys and so on rotate their people every few years. So just as Sid is getting to be proficient in your code base he is moved to another client.

That is, of course, assuming Sid stayed with your supplier long enough to get knowledge of your systems.
Assuming he did: remember he works for your supplier not you

Which leads to....

Hollowing out your knowledge pool
In the early days of outsourcing some really stupid companies gave their staff to the new supplier. When they tried to take IT back they found the people and knowledge stayed with the supplier.

So today most (clever) companies keep the key people - people with experience, “architects” and the like. But, these people are growing older, and sometimes they leave of their own accord. Which begs the question: Are you creating the next generation?

How does someone get to be an Architect? (i.e. a developer who might code)
Or an Subject Matter Expert? (e.g. a system analyst who doesn’t code)

Answer: they get to know this stuff because they once cut code.
These people became Architect and exports because you decided their knowledge was too valuable to have leave the company or do dirty things like coding.

So what are you going to do when they move on? Or retire?

Remember: the thing that makes them valuable is a) they work for you, b) they worked for you for so long they know how it works.
Outsource the doing today and you loose you knowledge tomorrow.

I see these issues repeated over an over again. Now I’ve told you it isn’t rocket science so why do companies do to themselves?

As Tolstoy might have said: “Unhappy companies are all alike; every happy company is happy in its own way.”

I’ll continue this rant in another blog posting soon.

Agile elevator pitch

My (our) entry in the Agile elevator pitch competition:

“[Agile] Provides philosophy, techniques and tools to alleviate the pain of traditional development and make teams more effective thus increase your profit.

Companies such as the BBC, GE Energy, Yahoo, the Financial Times, The Guardian and others have already adopted the approached.”

As some people know, I’ve been doing a lot of work in Cornwall recently. This involves working with a variety of companies all involved in software development - from online e-commerce website builders to companies creating embedded software for medical devices.

My partner in this endeavour, Michael Barritt of Oxford Innovation and Grow Cornwall, suggested we really need an elevator pitch statement for what all this Agile is about. The above is our result.

Of course this is context specific. Too many senior managers this is irrelevant because they don’t know anything about software development. At that kind of level Agile itself becomes meaningless because it is a solution to a problem which they know nothing about. And actually, they don’t want to know about.

There is always a danger with Agile elevator pitches, or any other type of elevator pitch, that it just becomes “Will increase your return on investment.” At some point such pitches become meaningless, you don’t know if the product will fix your software development issues, cure cancer or make you tea in the morning.

So what do you think?
Good?
Bad?
Indifferent?
Got a better one?

Red, Green, Kaizen

Back at the beginning of September Kevin Rutherford tweeted:

‘Anyone know the Japanese for "red, green, refactor” ?’

Now as it happens I know a Japanese speaker very well. Red was easy “akai”. Green was a little tricky because the Japanese actually have two words for Green, “aoi” and “midori.” We went with midori.

Refactor was a little bit tricky. After all, there was no such word in the English language until Martin Fowler published Refactoring. Indeed, “refactor” still haven’t made it into my English dictionary.

My translator suggested the Japanese would probably stick with the English term so we got “akai, midori, Refactor.”

At which point Kevin asked: “akai, midori, kaizen?”

Its taken me a few weeks to have an in-depth conversation about this with my translator but it seems Kevlin is right.

Kaizen is actually two Japanese words:
Kai: change
Zen: good

So the net effect is: “to change [improve] for the good”

Which seems to sum up refactoring perfectly.

Now, any other Japanese speakers out there like to refactor?

And just a gentle reminder that Changing Software Development is now available in Japanese. My personal Japanese translator didn’t do this translation, it was handled by the Japanese publisher.

An Agile Reader - buy it now!

When I deliver training courses I like to give participants something to take away to read, something that is more readable than PowerPoint slides. Sometimes participants get a copy of my book, Changing Software Development, but that is expensive to me and not always appropriate. (These days I tend to tell people CSD (as I call it in private) is an advanced Agile text, not an introductory one.)

A few months ago I decided to put together “An Agile Reader.” This is a mini-book, its a collection of articles which are interesting for someone new to Agile and decidedly shorter to read than Changing Software Development.

Anyone who’s been on a course with me in the last couple of months will probably have seen a copy of this. The feedback on the mini-book has been good and at recent conferences I’ve given away some spare copies.

So I’ve decided to make it public.


If you’d like a copy you can buy a physical copy here, or download the complete PDF. Price is £4.99 for the physical copy, currently discounted to £3.99 or £1 for the electronic.

I don’t see this as a new book, I prefer to call it a mini-book. Its a collection of essays, most of which you can get for free from my website or this blog. Its self-published using Lulu, its not been professionally copy edited and its not got an ISBN number.

Let me know what you think.

Cranfield study Supporting the alignment trap

I’ve blogged before about “The Alignment Trap” (Originally in December 2007 and after my piece in The Agile Journal in February 2009). This is the counter-intuitive evidence that sometimes doing things right is more beneficial than doing the right think. I often discuss this in my presentations and there are two standard reactions: for some this research rings true while others question it.

Those who question it often ask: is there any other evidence?

Well, there just might be.

Delivering Value from Information Systems and Technology Investments: Learning from success is a survey report from Cranfield School of Management in the UK. I only heard about this report a few months ago and its is now four years old but I see little reason to suspect things have changed since 2006.

The researchers define four levels of maturity in organisations developing systems. The first level is project delivery with the focus on the supply side. In order to reach the higher levels organisations must first be able to successfully deliver the IT projects they undertake.

In other words: doing things right is a prerequisite to success.

(I should point out that this report has nothing to do with Agile, Waterfall or any other method. Its about the ability to realise benefits from IS/IT projects whatever the approach.)

The second level of maturity concerns realising the expected benefits from projects. Here attention expands from the supply side to look more at the demand side and whether the business cases proposed are realistic. It is here that “doing the right thing” starts to be the issue.

Levels 3 and 4 concern realising benefits consistently across the whole portfolio.

The report contains some other nuggets of information which are with reporting:

• 73% of survey respondents said significant improvements were needed to get satisfactory value from IS/IT. (This 73% is curiously close to the 71% of companies in the “Maintenance zone” in the Alignment trap report.)
• 38% of businesses openly admit benefits are overstates in business cases in order to obtain project funding
• 80% report that review of work against the original objectives is inadequate

Finally, the other statement is worth analysing from this report is:

“The data also indicates that organisations have undue faith in business cases and that the deployment of formal methodologies gives managers a false sense of security, perhaps an excuse for not becoming sufficiently involved.”

If we take that statement apart it supports the Agile approach:

• “Undue faith in business cases”: Implies more tools are needed to tackle value. Agile would suggest a try, experiment, fail-fast, fail-cheap approach


• “Formal methodologies ... false sense of security”: That could be PRINCE2, Scrum or something else. The methodology doesn’t have the answers. You need to be pro-active and think for yourself.


• “Not becoming sufficiently involved”: Yet again we hear that lack of customer/user/manager involvement is a cause for failure. We have a few tools for working around these problems but nothing beats having actual involvement.

Cambridge edition of Objective Agility now online

Slides from my Agile Cambridge 2010 Objective Agility: What does it take to be an Agile company? online now.

Reuse Myth - can you afford reusable code?

In my Agile Business Conference present (“How much quality can we afford?”) I talked about the Reuse Myth, this is something always touch on when I deliver a training course but I’ve never taken time to write it down. Until now.

Lets take as our starting point Kevlin Henney’s observation that “there is no such thing as reusable code, only code that is reused.” Kevlin (given the opportunity!) goes on to examine what constitutes “reuse” over simple “use.” A good discussion itself but right now the I want to suggest that an awful lot of code which is “designed for reuse” is never actually re-used.

In effect that design effort is over engineering, waste in other words. One of the reasons developers want to “design for reuse” is not so much because the code will be reused but rather because they desire a set of properties (modularity, high cohesion, low coupling, etc.) which are desirable engineering properties but sound a bit abstract.

In other words, striving for “re-usability” is a developers way of striving for well engineered code. Unfortunately in striving for re-usability we loose focus which brings us to the second consideration.... cost of re-usability.

In Mythical Man Month (1974) Fred Brooks suggests that re-usable code costs three times as much to develop as single use code. I haven’t seen any better estimates so I tend to go with this one. (If anyone has any better estimates please send them over.)

Think about this. This means that you have to use your “reusable” code three times before you break even. And it means you only see a profit (saving) on the fourth reuse.

How much code which is built for reuse is reused four times?

I would suggest the answer to this question is: very little.

Consequently development teams which write a lot of reusable code are costing their organisations a lot of time and money. Waste.

Reusable code is not the solution to any of our IT problems. It is a supply side only solution and not a very good one at that. While it may reduce the amount of code that is written it reduces it by artificially constructing supply rather.

Thus, reuse, as a solution to software supply problems, is a myth.

This leave two questions we need to answer.

First: how are we to get those desirably engineering properties if we can’t/don’t push reuse?

The good news here is that Test Driven Development, i.e. writing code that can be automatically tested with other code we write, also has the effect of promoting modularity, high cohesion, low coupling, etc. Thus the answer to this question is: Make your code testable.

This approach will retain focus and deliver worthwhile benefits.

The second question: How should we manage reuse? After all, there are some genuine situations were reuse is the right answer.

Here there are two answers, a micro and a macro answer.

The micro answer, when your working in a development team is: look for emergent reuse.

Don’t plan for reuse but look for opportunities to reuse something that has gone before. When you see the opportunity take the previous work and enhance it just enough to reuse it in your case. This way you only pay the price for what you actually need when you need it.

If you later find the same code is useful again then repeat the process. Improve it just enough to use it a third time.

Remember: you have the tests from the earlier answer to make it safe to do this. Without the tests things get difficult.

Now you’ve reused your code three times, you’ve pay the price a bit every time, and you have the tests to show it still works. By now the code is going to be getting pretty close to generically reusable.

Still, maybe you go round this look a third or fourth time. It doesn’t matter is making one piece of code reusable costs more in the long run than it would have done if you did it the first time because... You haven’t spent money making a lot more code reusable that never needed it.

Telling the future is hard. It is difficult to know whether code will be reused or not, so default to Not and save the money. Occasionally you will be wrong and it will cost more, but overall you will be right and you will save money.

The macro answer: if this code really is widely reusable by many people then, go into business. Market this as a library, a plug in, an application what ever. Let the market decide the economics of reusability.

Agile Eastern Europe slides online

My conference overdose continues with Agile Eastern Europe in Kiev this week. This was going to be a simple repeat of my Business Analyst in Agile talk which I’ve given a few times before.

But somewhere over Germany I started playing with the slides. I pulled in a bit of “Objective Agility”, took a bit out, changed other bits. So the slides are different: The BA role in Agile Development (Kiev edition.)

If I’m being honest, I don’t feel this presentation worked as well as I’d like. Maybe because I changed it, maybe because I’ve delivered it too many times before, maybe because it was 3pm.

Time for reflection. Sorry Kiev, will try harder next time.

Quality - How much can we afford?

My presentation from the Agile Business Conference (ABC) 2010 is now online: Quality - How much can we afford?

Goal driven projects

With great timing (coinciding with my presentation to the BA conference and Jax London) the RQNG (Requirements Network Group) newsletter has published a little piece by me entitled:

Time for Goal Driven Projects.

Jax and BA conference presentations

Two new presentations from the two conferences I’ve been to this week.

From Jax London, Return to Requirements, this includes my “Agile 10 Step” requirements model. This is something I’m increasingly using and I’ll be writing (and presenting) more about in the near future.

And from the IIBA Business Analysis conference: Objective Agility - what does it take to be an Agile company?

Let me know what you think.

Moving pictures (of me!)

The next few weeks contains more conference for me than is healthy. While most of these are in London (Jax and IIBA BA conferences next week and Agile Business Conference the week after), or just up the road (Agile Cambridge), the interesting one is Agile Eastern Europe in Kiev the week after next.

Alexey and the other cunning minds in Kiev have decided to put the speakers on video. He’s my bit, explaining why you should come to my talk on the role of the Business Analyst.

This is going to be fun, while I’ve been to Russia and Moscow a few times, this will be the first time I’ve been to Ukraine and Kiev. Should be interesting. Interestna, as they say.

Unfortunately, in this blaze of conferences I’m not going to get to go to LESS 2010 (Lean Enterprise Software and Systems) in Helsinki. Which is a shame, not just because it promises to be an interesting conference but because I quite like Helsinki.

Now, can someone explain why there are so many conferences in the late-September early-October period?

For a bonus point, please explain why this period is also extremely busy with work for me: Agile coaching in Cornwall this week, several training days between the conferences and then back to Cornwall to give more coaching before the month ends?

Factory Physics and software factories

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Japanese translation of Changing Software Development out now

The Japanese translation of “Changing Software Development: Learning to be Agile” is now out and you can buy it from Amazon Japan right now.

And just in case you don’t believe me here is the cover:

Agile is like...

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

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

This always reminds me of the old Philip Crosby quote:

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

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

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

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

Study on benefits of TDD

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

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

development: results and experiences of four industrial

teams and is freely downloadable from Microsoft.

This is the key findings are summarised in this table:

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

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

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

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

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

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

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

Ed Yourdon on Agile

Ed Yourdon seems to have fallen off my radar so far this century. Last century I read a lot of his stuff and came to respect him as a man who knows what he’s talking about when it comes to IT and software development.

(If you haven’t heard of him, or don’t believe me just look at the list of books he’s written.)

I recently discovered that he has a blog, and from there that he has recently been to the Agile 2010 conference. In fact it appears that the whole Agile thing has, to a large part, passed him by.

The really interesting thing are some of his comments on Agile from this blog posting:

• ‘My overall impression is that “agile” (and its variations, such as scrum and XP) are now entering the “mainstream” of computer systems development’
• ‘there’s still a lot of hype and exaggeration, along with a non-trivial amount of myth and folklore and general silliness. But when you strip away all of this, there is a very solid, and extremely well-documented, core of practical system development guidelines, concepts, strategies, and hard-won lessons that every practitioner in our field needs to know about.’

I’m happy to find myself agreeing with Ed, and even happier that the voice more experience sees it the same way I do!

Objective Agility - what does it take to be an Agile company?

Modern Analyst has published my latest piece about Agile at the company level: Objective Agility - what does it take to be an Agile company?

This is actually a bit of a taster for a presentation of with the same title I’ll be doing at the IIBA Business Analysis conference in a few weeks.

And talking of businesses analysis... I am running an ‘Essential Agile for Business Analysts’ at Skills Matter in a few weeks. Many of these themes come up in that course. I believe there is still space available.

And if you miss all that, I’ll be sticking with this theme for the Agile Cambridge conference in October.

The No Business Case Myth

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

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

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

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

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

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

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

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

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

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

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

Off topic moan - Price Promise that isn't

Although I try to keep this blog within its very loose boundary of software and business there are times when you want to say something that doesn’t fit.

I could try and justify the following story on the basis that it concerns my upcoming trip to Agile Eastern Europe. Or I could justify it as an example of poor system thinking, but I think it is really a moan.

It also shows how I was fooled. I’m not as bright as I like to think I am, for once I believed what the corporation told me despite my natural cynicism.

It all began when I set out to book my flights to Agile Eastern Europe in October. As usual I did a quick check on Opodo to see what the market fare was and who had flight. Turns out British Airways had a direct flight, was fairly competitive and since they are my usual airline I decided to book with them.

As usual I then went to the BA website to see if it was any cheaper. It wasn’t indeed it was more expensive, but since I was now logged into the BA system and all my details were on file I decided to finish the booking there.

However, BA was more expensive. That’s OK I thought, BA make a big thing of their “Price Promise.” I’ll just keep a record of what Opodo offer and they’ll give me the money back, about £25.

Wrong.

British Airways won’t pay up. Despite sending them the PDF I took of the Opodo offer they say its a different itineracy. Erh? Same flight out, same slight back. But it seems, Opodo was offering me two single tickets and BA were offering a return ticket.

Wonderful. British Airways are hiding behind word play. I want a flight to Kiev and a flight back. Do I care about the niceties of ticketing? No. The difference is lost on me.

So there you have it. BA have made an extra £25 out of me. Clever, pat yourself on the back guys.

Except, I’ll never book with BA.com direct again. That means 20%-30% of all the ticket revenue will go to Opodo in future.

I’ve been avoiding BA for much of this year because of the strikes. This means I’ve rediscovered Heathrow Terminal 1 and flying with BMI and Lufthansa. Looks like I’ll be using them more.

Advice to companies: if you are going to make these kind of price or quality promises don’t hide behind word play when people try to claim. It annoys them even more.

I have only myself to blame, a quick bit of Googling shows other people with similar complaints - here and here.

Sorry to my regular readers for a well off topic piece.

I'm a BA get me out of here! - the BA role on an Agile Team

In the last couple of years I’ve given my “BA role in Agile” (PDF of the Nottingham version, or Slideshare of the Skills Matter version) talk a number of times at a number of different venues. A couple of months ago I got around to writing up the talk and it has now been published in ACCU Overload.

If you’d like to read this you can read it in Overload 98, or take the PDF from my website, “The BA role on Agile teams”.

Shorter versions of this piece have, and probably will be again, published elsewhere. The Overload piece is the full version. Thats the nice thing about Overload, it has the space to explore a topic more fully.

I’m just now putting the finishing touches to the 3-day training course that grew out of this talk and which will be running in September at Skills Matter.

Conferences, Conferences, Training - a busy autumn

I’m speaking at a bunch of conferences this autumn so if any reader out there would like to hear me speak, or ask a questions you might get yourself a ticket to one of these:

• Jax London / DevCon, 27-29 September, London: Return to Requirements, 27 September
• IRM IIBA Business Analysis Conference, 27-29 September, London: Objective Agility, what does it take to be an Agile Company?, 28 September
• Agile Business Conference, 5-6 October, London: “Quality – How much quality can we afford?”, 6 October
• Agile Eastern Europe, 8-9 October, Kiev, “The role of the BA in Agile teams”, 9 October
• Agile Cambridge, 14-15 October, Cambridge: “What does it take to be an Agile company?”, 14 October

In between times, I’m also delivering several public training courses - not to mention private ones but there is no point in me telling you about those.

What’s particularly interesting here is the new “Agile for BAs” courses that I’ve put together with Chris Matts. The first of these ran last week in association with BA Solutions and was well received. A different, longer, version of this, is running in association with Skills Matter twice this autumn:

• 13-15 September, Skills Matter, Essential Agile for Business Analysis, London
• 18-20 October, DevelopMentor, Foundations of Agile Development using Scrum Training and User Stories, London
• 1-3 November, ProgramUtVikling, Applying Lean Thinking for Software Development, Oslo
• 24-26 November, Skills Matter, Essential Agile for Business Analysis, London

The train metaphor of software development

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

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

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

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

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

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

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

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

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

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

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

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

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

Thats the traditional view. Now for the Agile view.

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

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

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

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

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

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

Slides from Skills Matter - BA Role in Agile Software Development

I presented my “BA Role in Agile Software Development” talk at Skills Matter last night. There was a good turnout and the folks who came to the pub afterwards were all very positive about the talk.

The talk had a few small updates from its previous deliveries so if you’ve heard or seen it before there won’t be anything new for you.

Slides are now online on SlideShare and Skills Matter have a video of the event online too.

The Limits of Agile on InfoQ

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

I’m interested to here your comments.

The Business Analysts role @ Skills Matter

I was down at Heathrow earlier this week, not taking a plane but giving my “The Role of Business Analysts in Agile Teams” talk again. It gets another outing in a couple of weeks time (22 July) at Skills Matter.

So, if you’ve not seen the talk, or know someone (a BA perhaps?) who would like it register on the Skills Matter website for “The Role of the BA in Agile Teams” talk. (Its in the evening and lasts a little over an hour, time well spent.)

http://skillsmatter.com/event/agile-scrum/the-business-analysts-role-on-agile-projects/rl-311

How to improve a team's velocity?

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.

Velocity targeting and velocity inflation

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.

Filling an iteration too well

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.

Two ways to fill an iterations

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.