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?