Why managers don't "get" Agile development

I hear it time and time again: “they don’t understand Agile” - “they don’t get it” - “they won’t let us do Agile” - “they” means managers. I get frustrated when I hear this because a) I’m now on management side of software development, b) I get Agile, c) To me “Agile management” is just the application of good management.

The problem was repeated on ACCU General last week when someone said:

“I often find there is little to no problem convincing the programmers. The problem is convincing people "higher" up the corporate ladder. The ones who control the purse strings”

Recognise the problem?

The poster suggested a reason:

“but typically they have only a shallow understanding of the nature of software development.”

I think the poster is right, typically this is the case but it is not the whole story, there are other factors.

Last week I was putting together my ideas for Øredev 2008 were I’m giving a talk entitled “Hitch Hikers Guide to Management.” In the session I want to talk about the role of managers in Agile development. It was then that it all came into focus...

Managers don’t get Agile because Agile appears anti-management. Not only is there no clear role for managers in Agile but many of the Agile methods set out to remove management.

Lets look at the evidence, and for once Scrum is the best example.

• Scrum does not define a “Project Manager” role - it does define a “Scrum Master” role (increasingly organisations are interpreting “Scrum Master” as a “Project Manager” which kind of defeats the objective)
  
• Scrum does not define a “Business Analyst” or “Product Manager” role, instead it defines a “Product Owner” role (and does a bad job in my view)
  
• Scrum strongly advocates self organising teams, i.e. no manager or leader
  

Just about all Agile methods are developer centric, they were created and pioneered by developers. XP does away with just about all roles except customer and developer. So at first sight Agile methods are a threat to managers.

Somewhere in the back of my mind I remembered Peter Block’s comment in Flawless Consulting:

“Maintaining control is the center of the value system of most organizations. There is a belief in control that goes beyond effectiveness or good organizational performance. Many managers believe in maintaining control even if keeping control results in poorer performance. There is case after case demonstrating that more participative forms of management are more productive, yet the practice of participative management is not too common. ... Control is the coin of the realm in organizations.”

Agile, as often presented, threatens control in an organization, it appears to say: “remove the managers and give control to the code monkeys software engineers. (i.e. the guys who don’t wash, the same guys managers don’t want speaking to the customers).”

Contrast this with something like PRINCE 2. As regular readers will know I qualified as a PRINCE 2 Practitioner earlier this year. I learned very little about project management on the five day course, and much of what I was taught flew in the face of my own experience. But what PRINCE 2 does present is a control mechanism, or rather lots of control mechanisms.

And there are many management roles: Project Manager, Project Executive, Chief Supplier, Chief Customers, etc. etc. PRINCE 2 will ensure the ritual and appearance of control even if a project is widely out of control. In other words: PRINCE 2 is not a threat to anyone in management.

In contrast Agile, and the organizational learning approach I advocate, do represent a threat to management. They don’t remove management from the picture but they do change the role. And so far Agile methods haven’t done a good job of explaining where management fits in.

So, is anyone still surprised that management don’t get Agile?

I have been convinced for a while now that the main problem in software development is not technology but poor management. Its why when I moved from development to management I went off and got a management degree. I am also convinced that Agile and modern, management practice are totally aligned - go read Changing Software Development if you don’t believe me.

Anyone for Agile Management ?

DisplayLink works well

A few months ago, at the ACCU conference in April to be exact, I was lucky enough to be given a Display Link adaptor. For those who don’t know this device, or the company, it is a little box of magic that plugs into a USB port at one end and a regular monitor at the other, all you have to do then is install a software driver and there you are: a monitor connected to your USB port.

Using this device you can have as many monitors attached to your machine as you have USB ports. No more two screen limit. For manufacturers this could eliminate another port on the machine and reducing cost. Some display manufacturers are already building these into their screens so the days of the video cable could be numbered.

I only got around to installing this on my Mac just before I left for EuroPLoP. I already have a perfectly good LCD display connected to my MacBook the usual way so I had no real need for the DisplayLink device but I wanted to try it all the same.

The install was absolutely painless, just downloaded the drivers from DisplayLink, installed them, plugged everything in and it just worked. Really, first time. 10 minutes, including the download, a reboot and unwrapping the cables.

Only two small problems: first the USB connector has to plug into my Mac, not the USB hub I have all the other USB devices plugged into. A shame but not the end of the world. Second the display update is a little slower than the dedicated cable. You only notice the slowness when a lot changes on the screen, for word processing and such it is fine.

At the moment the Mac drivers are beta and the release notes say you might notice a speed issue so by the time they are released fully the problem might have gone away. For all I know the full release version might fix the hub problem. (PC versions already have full release drivers so speed might not be an issue there.)

For the moment I’ve switched back to the video cable. If I have to plug the USB cable into the MacBook I might as well plug in the video cable and have full speed. That said, I think its only a matter of time before we are all using these things.

What’s really nice about this story is: this is a company that gets things right. The product is useful and it is well done. I know people who work at the company and they seem well balanced and happy in their work. Too often I hear stories about messed up development teams and companies that can’t make sensible decisions so its nice to have a positive example that reminds you things can work out.

EuroPLoP 2008

I’m back and recovering from EuroPLoP 2008. As usual I am physically exhausted and mentally energised. Physically its a very healthy conference for me (lots of outdoor swimming, sauna and good food) - except for the large quantities of beer and small amounts of sleep which occur when you spend all night in the bar talking the finer points of software management, design and practice.

My paper was another instalment in my growing collection of business strategy design patterns. It was well received and as soon as I’ve made the suggested changes I’ll post it online. I think I’ve finally accepted that one day these patterns will be collected into a book. A lot of people have been suggesting that to me for a while but I’ve been reluctant, now I’ve spoken to a publisher about the idea but we agreed it won’t be for at least another year.

In the meantime sales of Changing Software Development are going well and I signed the copies people bought at the conference.

This time however the conference was special for me: I was the Conference Chair. This means I’ve been doing a lot of work over the last few months to get everything ready for the conference and I was busy with, well, the duties of a chair, at the conference.

Next year I’m going to be Programme Chair of the conference - more work, more stress!

The up side is when you are chair you get to organise the conference the way you like - well more or less. So this year the conference contained a number of changes and innovations, I think on the whole they were well received.

And for my next conference I’m off to Malmo in Sweden for Oredev 2008, but that’s not till November.

Moody's bug rumbles on

The Financial Times has reported more about fallout from the Moody’s credit rating bug in the last couple of days: Moody's to investigate staff over rating bug (page 1) and Moody's to check on accuracy.

I blogged about this a few weeks ago and had a very interesting comment pointing out that despite the bug Standard & Poor’s gave the same instruments a similar rating, that is worrying.

According to the FT:
"We have no reason to believe that our record [with computer bugs] is unusual," Mr Cantor [of Moddy’s] said, noting that bugs often appear in software development throughout the computing world.

Indeed, that a bug existed is not unusual, that it took over a year to fix is not unusual. That is may have lost companies lots and lots of money probably isn’t even unusual.

I don’t know what’s worse, that fact that this situation is regard as “usual” in the industry or that Moody’s are using everyone else’s failings to excuse their own.

We - well some of us at least - know the solutions, we can fix this, but if Moody’s and the rest of the industry accept this as “normal” what’s the point?

Pattern season is here again

Apologies to readers for the mass of blog entries this week. I normally aim for about one post a week, or perhaps two short ones if they are very different ideas. Having been at Tom Gilb’s seminar last week I had a whole bunch of ideas and thoughts I wanted to record - and share - before its too late.

“Too late” means: EuroPLoP is coming. This always means a mass of conversations, ideas and insights, and these too lead to a mass of blog postings. This year I’m Conference Chair so I’m finding a lot of my time right now taken up with conference trivia.

This year’s EuroPLoP is shaping up to be excellent - the papers I’ve been reading for the conference are very good - and a little different. As well as making some changes to the conference itself we are being joined by quite a few people from the Complex Event Processing community. We’re lending them a venue for some of their work. Should make for an interesting conference.

And much to my surprise I found patterns at Tom’s seminar last week. I met Matthew Leitch who is something of an expert on risk. In fact he’s written a book, Intelligent Internal Control and Risk Management, on the subject - and excellent it looks too!

It turns out that like everyone in the Hillside Patterns community Matthew has also read Christopher Alexanders pattern languages and decided to apply patters to his domain - namely risk management. So Intelligent Internal Control and Risk Management is actually A Pattern Language of Risk Management.

I don’t think Matthew was aware of Hillside or the work done by the Patterns Community - and if he was he probably thought we were all about computer software - so this work has been done outside the community, he’s a lost sheep if you like. Still, its another example of how pattern ideas and thinking can be applied far and wide.

How do you measure Agility?

Here’s a suggestion: Agility is a measure of the time it takes between an organization deciding something and action being taken.

Ideally you would also measure the time it takes from an event to the organization recognising the event, realising a decision was needed, making it and then acting. But some events aren’t events, they are gradual build ups, at some point they pass the “tipping point” and action is required. How do you know when you should recognise the event?

Moving on slightly.

Some people have suggested that organizations should be modular. (John Seely Browns argument in The Only Sustainable Edge touched on this.) If a unit isn’t working swap it out and up in a better one, or a more high performing one. Business design is taking on aspects of software design. The modular corporation can swap its call centre in Aberdeen for one in Mumbai.

People who advocate this also suggest that the corporation becomes more more Agile as a result. If you need more call centre operators just power up another centre somewhere in the world. If you need more sales people just hire a sales force module. But I’m not sure.

I can see how this would allow you to flex capacity, and for a stable organization it may allow them to respond more quickly. However, in a rapidly evolving environment, one were you don’t know what’s happening its going to take time to identify the module you want, sign the contracts and switch them on. And that’s assuming you can buy in the business module you want and you have compatible interfaces. If you can’t you might have to build an adaptor.

In an innovative environment that is changing fast, or just one that is poorly defined, bringing in a third party is going to complicate things. Someone else to talk to, another organization, what are their standards? Do they understand the domain? Are the property rights clear? And so on.

In some environments I think Agility is enhanced by having everything done in house. Learning and change should be a lot faster when everyone works for the same corporation, have the same objectives, and don’t have to keep secrets.

When you add organizational boundaries it slows down recognition of events, decisions and action.

Confirmation bias

Couple more thoughts I picked up last week...

I finally found out the name of something I’ve know about for a while: Confirmation bias.

This is the brain’s tendency to seek out information that supports are existing beliefs, and to put more faith in evidence that supports out current beliefs; rather than take a purely balanced view. Confirmation bias means that we human’s aren’t a rational and neutral as we like to think we are.

Several of the presentations a Tom’s seminar last week demonstrated techniques that can be used to expose our assumptions. Assumptions are a bad thing, they blind us to things we need to know. However they are useful, they serve as short cuts which enable us to process information faster.

I had a lecturer as an undergraduate who told us to “Always document your assumptions” which I tried to do. Then he would knock marks off for not documenting assumptions. Trouble is, I didn’t know I was making them. Assumptions can be difficult things to recognise.

Especially when you take in confirmation bias.

Scrum is the new XP

Another insight I had last week: Scrum is the new Extreme Programming. Or rather Scrum is the new Agile Software Development.

Before there was Agile Software Development there was Extreme Programming - or just XP. XP got all the attention and coverage. Then the term Agile was adopted by Kent Beck, Jim Highsmith, Martin Fowler and others as an umbrella term for XP, Scrum, FDD, Crystal, etc. etc.

But, for a long time many people - outside the inner sanctum of the Agile community - equated Agile with XP, the two terms were inter-changable.

That period came to and end about two years ago, XP stopped getting all the fuss and Agile was something in its own right. (Still all the terms XP, Agile, Scrum, Lean, etc. still confuse the uninitiated.)

But now Scrum is supreme. Scrum is everywhere. Scrum certification seems essential for ones career. Now it seems the terms Scrum and Agile are inter-changable. Scrum is Agile and Agile is Scrum.

Either this means Scrum has won - the Scrum Alliance has done an excellent job of marketing Scrum and it now has the respectability that “extreme” anything could never had.

Or is the start of the end of Scrum.

I expect the Scrum is Agile and Agile is Scrum trend to grow for the next year or two. It will be at least that long before Agile is again a free term. (All the more reason then to adopt Agile Engineering as the new banner.)