Leave your laptops out of meetings

The new year is just here! And can I suggest a new year’s resolution?

Normally I bite my tongue and don’t mention this. I’ve not blogged about it before because what ever client(s) I’m working with at the time I blog about it will automatically assume I’m talking about them. (Yes, I know people at client sites find and read my blog so I try to self-censor.)

But, I’ve just finished up a major engagement (coaching 4 development teams in the same company) and new stuff kicks off in the new year, so I can say this for once.

Please, don’t take your laptops to meetings. And if you do leave them powered down.

If you go to a meeting it deserves your full attention. If you don’t want to give it, or can’t give it, than make your apologies and say: Sorry I can’t make it, go on without me.

If you do go then give the meeting your attention. OK, occasionally we all need to take a phone call but it is far less often than we think. I remember breaking my own rule a few years ago to take a phone call, but then I was waiting for my farther to die.

Phone calls are different to laptops. A phone call is an interrupt. It says “Someone wants you.” By definition if someone has sent an e-mail it is less important, or at least less urgent. So as much as I dislike meeting interrupted by phone calls I can accept them - personally, I switch my phone to silent and reject calls that come during meetings.

If you are so important you carry a Blackberry (or similar) and urgent (meeting interrupting work) arrives via e-mail it may be a sign that your organization can’t prioritise. But at least a Blackberry is small.

The problem with a laptop in a meeting is it creates a barrier between the user and the other people in the meeting. Every time someone lifts their screen I see a sign that they don’t want to be here, don’t want to hear what is said, and don’t want to be part of the team.

That screen is big. Its a big barrier. Its a sign. It says “I don’t need to interact with you people.”

And what do people do with these laptops?

I tell myself they are answering e-mail, important requests that cannot wait. But... well... I heard about a case recently where the senior manager in the meeting was booker herself a flight on EasyJet. I once went to a meeting which was so packed I had to stand at the back, from where I could see a manager (director level) surfing Amazon.

And people who are typing? Are they really replying to an urgent e-mail or having an Instant Messenger conversation with their significant other?

I once took an IM from a colleague in the New York office. Later in the day I saw him in the London office. He’d landed that morning and spent the first few hours in the London office in meetings. So when I IM’ed with him he was in a meeting on a totally different subject and he could have asked me face-to-face an hour later.

Please, stop taking your laptops to meetings. I’d rather you make your apologies and not turn up at all.

A future for software development in the west?

To read the papers one would sometimes wonder if there is a future for software development, indeed IT in general, in Western Europe and North America. Sometimes it seems there is an continual flow of work to India, China and other low cost centres. Personally I think there is a future but only if development groups fix themselves.

First lets be clear: I’m talking about corporate IT here, not independent software developers or other companies who develop software to sell. That is another story, another arguement, lets still to corporates today. Corporate IT departments support business operations by providing them with custom software.

Second there is another force at work: the commoditisation of business processes and the IT that support them. Lets leave that to one side for the moment.

So, I’m specifically talking about IT groups within businesses that need custom software to support some business activity.

Unfortunately such corporate IT departments do not have a good track record. Something like 87% of all such departments are ineffective and do not give the business what they need. (I’ve taken the figure from The Alignment Trap reports which I’ve blogged about before.) In such circumstances IT represents a cost not a benefit. Such companies might be better off not doing IT at all.

If you are doing it, and you are not seeing the benefit, and you are paying the cost then its sensible to look at reducing that cost. Outsourcing and/or offshoring is a valid option.

It might not be nice to hear but if you work in such a group it makes sense to send the work elsewhere. Sending it elsewhere might not fix the original problem but at least it will be cheaper.

So what’s the solution? How do you save your job?

Instead of looking at the cost look at the benefits. Some IT groups have forgotten how to do this simply because their delivery record is so bad. When you only consider the cost side western corporate IT cannot compete, give up now. In order to compete you have to look at the benefit side to.

When things are going well, when an IT group can deliver and can deliver benefits then it is less likely that management will want to change things. When things work, and work well, then any change is a risk. When things don’t work the risk is lower.

Next you need to maximise the benefits. That means looking at how you can add more benefit. And specifically add benefit in ways that offshore low cost centres can’t: quicker turn around, reduced documentation, more interaction with the business.

There is a price to pay in moving work to a low cost centre. Such centres have disadvantages: language differences, cultural differences, distance, time zones, lack of domain knowledge. Sure they can offset these differences but that involves costs. Plus they are getting more expensive (particularly as the pound and dollar fall).

Corporate IT departments can demonstrate their value by responding to business needs more quickly, and by reducing the cost of servicing those needs. When work goes offshore the turn around rate slows because work must be communicated. That means it needs to be more closely defined - this is especially true if the work goes to a third party. Opportunities to change’s ones mind are reduced and the potential for differences increased.

Yes offshore centres can offset these differences but at a cost. Each time the cost goes up the advantage is reduced.

So if you fear your work may go offshore heres what to do:

• Demonstrate the benefit of your work - move the conversations from costs to benefits
• Concentrate on co-operating with your business customers
• Turn work around more quickly
• Reduce the cost of requests and changes of mind - reduce the paperwork
• Work more flexibly
• Understand the business and find ways to innovate

XP Day 2008

I spent Thursday and Friday last week at XP Day 2008. The conference changed its format from last year. Rather than being a conference aimed at people wanting to do Agile Development it focused on people who do Agile development. This meant the sessions changed rather than being introductory or “how to” material they became Open Space discussions. Instead of being lecturers session leaders were facilitators.

Very few sessions were arranged in advance but one that was was Designing the Agile Company led by Giovanni Asproni and myself. This session used a dialogue sheet technique to promote discussion.

XP Day also had space for Lightening Talks. These were unscheduled talks lasting no more than 5 minutes - so very focused. I briefly outlined the Requirements Trap - or rather the Alignment Trap which I blogged about last year. This short talk got a lot of interest and a lot of people asked for the references so here they are:

• Original Alignment Trap article in the MIT Sloan Management Review
• An abridged version from the Bain Consulting website
• My blog entry on the Alignment Trap and Agile software development

I enjoyed XP Day a lot and learned a bunch of stuff - mainly by having to think about it. Yet I found the conference lacking because I found myself speaking to the same people; I already known most of these people, I read their blogs, I talk to them at XTC and a bump into them at other conferences. One of the nice things about Oredev last month was new faces. I guess you can’t have everything.

Oredev

I have been at the XP Day conference for the last two days but before I blog anything about that conference I want to record a few notes about Oredev last month.

The first thing to note about Oredev is that it is big. About 900 people. While the topics cover, and type of attendee make it look a bit like ACCU Conference but it is more than twice the size of ACCU (usually about 300-350) and it felt it. While quantity has a quality all of its own I missed the intimacy of ACCU.

My own session was well received. Hard to tell how many people attended the session, I would guess 50 to 100, but in a room that could hold 1,000 it felt empty.

Still I met a bunch of nice people and heard some good talks. Bob Martin was on form, his keynote talk took more prisoners - “Professionalism is spelt TDD” and programmers should me more like the Boy Scouts of America. The Boy Scout have a rule: When you camp somewhere, always leave the campsite tidier than when you arrive. Bob suggests programmers should apply this rule to working on code.

While I enjoyed several of the other talks (Gabrielle Benefield, Diana Larsen, Dag Krogdahl stick in my mind) it was Luke Hohmann’s that explained something to me. Luke’s talk was about product management - and regular readers know this is one of my hobby horses - but in passing it answered a question I’ve had for years.

What is Enterprise Software? - or more to the point What is Not Enterprise Software? Luke gave 4 attributes of enterprise software:
1. Enterprise software is expensive: you don’t buy it for the home, only corporations buy it
2. Enterprise software is tended by people: system administrators, etc.
3. The software is critical to some aspect of the companies business
4. Enterprise software is more valuable when it is integrated with other enterprise software

Gemba - Lean tour

Jason Yip works for ThoughtWorks in Australia. He is currently (or maybe was) on a Lean study tour in Japan - I’m jealous, where do I book mine? - and he’s blogging about his findings. Well worth reading, so far several points have stood out for me:

• Andon cords are being pulled all the time: a Toyota factory isn’t the perfect place some of us (myself included) imagine sometimes. Faults happen, things need to be fixed and improvements made - all the time.
• Toyota do pay bonuses: for ideas that lead to process improvement
• Hansei is the Japanese word for serious reflection. In the Agile world Retrospectives are Hansei. As regular readers know I always suggest keeping your own personal journal for reflection, more Hansei.
• Pika Pika is a Japanese term translating to “spic and span”: workers keep their work area clean and tidy. Obvious really, how else can you see the problems? (I’m always shy of people taking cards of the board and putting them on their desks after one engineer I knew lost several this way. We tidied his desk and found work.)
• “The Toyota Production System (TPS) is not a system; it's a religion” - to all those who have critised Lean and Agile for being too religious, you were right.

If that isn’t enough, Jason also has a nice set of hand drawn sketches to illustrate Agile and Lean!

Books for Product Managers

Turns out books about Product Management are a little likes buses: None then 3 turn up at once!

I’ve been looking for a good book on Product Management for a while so I was interested to see Tuned In by Craig Stull, Phil Myers and David Meerman Scott published. I’ve not had a chance to read it yet (so don’t take this as a recommendation) but I intend to.

Then, at Oredev I met Luke Holmann and had the pleasure to hear him speak. Turns out Luke has a book in the product management space too, its been out for a couple of years but somehow I’ve missed it. Again I’ve not had the chance to read it yet but I intend to, it is Beyond Software Architecture.

Finally, one of the Product Managers I’m working with just now leant me a copy of another book, Expert Product Management by Brian Lawley. This is small book and as such doesn’t cover the role of the Product Manager in full. It simply covers several aspects of product: Road mapping, Beta programmes, Reviews and Product Launch. There is good information here and as its small you can read it quickly. Still, I’m hoping on of the other books will turn out to be the Product Management book I’ve been looking for.

Public training

Speaking of speaking - as I was in my last post... I regularly get e-mails from people asking when I’m running a public training course. Truth is, public training adds lots of additional hoops to jump through to be successful, e.g. getting a good venue. Consequently I usually confine myself to in-house training for organizations.

I’ve now teamed up with the folks at Skills Matter to offer public training, specifically Agile Project Management. These sessions are running throughout 2009 in London and Aarhus, Denmark. More details on the Skills Matter web site.

Software East in January

I’ve been invited to join a panel debate in Cambridge on Thursday 22 January. This is quite exciting because the topic is “Building a Software Business” - something close to my heart as anyone who has read my business strategy patterns will know.

The organisers are Software East, a new initiative from Mark Delgarno and others to help the Silicon Fen software business community. Also on the panel is one of Cambridge’s local hero’s Neil Davidson, a founder of Red Gate software and one of the people behind the Business of Software community.

This will be the fourth time in less than 18 months I’ve been up to Cambridge for one speaking event or another. While I’ve been to other places in the country to speak 4 in 18 months is quite a record and I think it just goes to show how vibrant the Cambridge technology scene is.

The FT and Me

Regular readers of this blog have probably twigged that I read The Financial Times. What isn’t so well known is that I am, very occasionally, in The Financial Times.

Citibank (current advertising slogan “The Citi that never sleeps”) inspired my entry to today’s letters page.

Deciding that this penmanship deserved a mention in this blog I went to the FT site and did a vanity search to find the link above. What I wasn’t expecting was to find myself in another article from a few months ago.

Back in June the FT IT editor wondered out loud if there was anything the IT department could do to save costs. I must have had too much time on my hands that day because I shot off a note saying: Agile development can help cut costs, and here's how.

I missed publication of that piece at that time so I’ll have to be more attentive in future.

Now if only I could get them to link to blog....

Limits of self organizing teams

I’ve been thinking a lot about Scrum in the last few weeks. Scrums done a fantastic marketing job for itself, so much so that Scrum is now the poster child for Agile.

However there are aspects of Scrum I find troubling. One of these is the self-organizing team. Its not that I have anything against a self-organizing teams, in fact I’m all for them. And although I don’t talk about them in Changing Software Development much of what is written there implicitly advocates teams taking on organization for themselves.

No, what troubles me is the system within which self-organizing teams are expected to exist.

My first worry is that such teams are culturally incompatible with many organizations. Many (perhaps most) organizations are set up as command-and-control structures. As much as I’d love to have a revolution and change the whole organization I do not expect this to happen overnight. Self-organizing teams will often need to exist within command-and-contol organizations.

Some organizations will be open the occasional self-organizing team and will tolerate them. The team itself needs to recognise the boundaries of its self-organization and while it might seek to spread the idea it shouldn’t expect the whole organization to understand, the team needs to learn to interface to a hierarchical structure.

And in other companies the organizational immune system will actively try to ejects the self-organization team as counter-cultural.

A while ago I heard about a French bank in London which tried Agile development - it may have been Scrum I don’t know. Things went well to start with then the Business Analysts in the organization rebelled. They didn’t like the way the team was working and told management so. The experiment was closed down.

My second worry is that we might be asking too much of self-organizing teams within a hierarchical environment. Specifically, teams can (and do) change what is within their control but they exist within a system and they have limited power to change the system.

As W Edward Deming would point out: we should not blame the worker, or look for the worker, to fix a problem which is actually part of the system. The system needs to create the environment in which workers can do their best work. When the system stops the best possible work then it is they system that is at fault.

This is the thinking behind Deming’s point 10:

“Eliminate slogans, exhortations, and targets for the work force asking for zero defects and new levels of productivity. Such exhortations only create adversarial relationships, as the bulk of the causes of low quality and low productivity belong to the system and thus lie beyond the power of the work force.”

So, if we place a self-organizing team (or even a semi-self-organizing team) in a system which creates problems we cannot expect the team to fix the problems. There are limits to what the team can do. It is management’s job to create the environment.

I have been a vocal advocate of people trying to fix these kind of problems in their organizations. Indeed I actively urge people to try and address these problems. Until you try and fix a problem you don’t know if you can fix it or not.

Those of us who help organizations improve the way they work - including the adoption of Agile methods - need to recognise when a team can change the way they work and when they system the team exists in needs to be changed. And when the system needs changing we need to decide how far we go in changing that system.

BCS SPA London - this Wednesday

Just time to book your self a place at BCS SPA London on Wednesday (5th) if you want to hear me talk about Reflections of an Agile Advocate - 6.30pm, Covent Garden. (Yes I’ve done a lot of talks this year but I do have a book to plug! - most un-English).

Managing requirements in Agile development

I make no apologies for blogging again about Product Management because it is important and because, on the whole. As I said in my previous entry, Agile methods have a very simplistic view of determining what needs doing.

In the short run the Alignment Trap tells us that it is better to focus on doing things right, but in the long run Lean thinking tells us we have to do the right thing - remember 80% of features aren’t used. So Product Management is a long run play.

That is one of two reasons why Agile methods tend to underplay requirements and “Product Ownership” - because you get a lot of benefits by ignoring them to start with. The other is that Agile methods largely originated with developers who generally tend to underplay the role of requirements. (The exception to the rule may be EVO which is quite keen to understand exactly what people want.)

The trouble with Product Management is that everyone has a view on what needs doing, thus, in the absence of a Product Manager (or BA if your that type of company) other people will fill the void -

• Developers sometimes try and fill the void but developers have empathy with the code and find it hard to untangle their feelings about the code from what the customer wants.
• Architects claim to fill the void because they have the “bigger view” but architects are - almost by definition - uber-developers so have the same problem as developers. But architects are also tasked with looking at technology therefore any requirements they come up with are likely to be technology not market based.
• Project Managers often try and fill the void but their training and inclination is very different. They have a tendency to view things through the prism of dates rather than business value.

In the UK confusion between Project and Product management is rampant. It is slowly getting better but many companies can’t tell the two apart. This is really sad but also really dangerous.

Project Management can always expand to fill more time: you can always redraw a PERT chart, or level it again, you can always add another risk to the risk log (“An asteroid may hit Earth and delay the project”) or you can always go and ask a developer “Are we there yet?”

Product Management on the other hand can always be shrunk to squeeze in. After all we all have views on what the product should do so stick a finger in the air and guess. (And the more senior the person doing the guessing the more likely their guess will be taken as truth.) It takes time to visit customers, talk about their needs, time to go to trade shows, investigate competitors, time to calculate ROI and so on. Far quicker to stick a finger in the air.

My personal rule is: one Product Manager to every three to seven developers. If your product is stable, changing little and in a quiet market then one Product Manager may be enough for seven developers. But if you product is developing, the technology is innovative and the market changing fast you need one Product Manager for every three developers.

Its a false economy to skimp on Product Managers, you may save money but you may well create the wrong thing. Far better to go a little slower and create the right thing.

Given how much work a Product Manager has to do its natural to look for ways to split the role up. The first split is to hive off outbound marketing to Product Marketing. In a small company or team a Product Manager may do both inbound and outbound marketing but once it grows you should split the two roles.

Another division is between Tactical and Strategic, and with this split the role fits well with the Agile/Scrum idea of Product Owner. The Tactical Product Manager takes on the Product Owner role.

I hadn’t thought much about this until a friend of mine brought some blogs from Eigen Partners to my attention. These guys explain it well themselves so I’ll leave you to read Agile/Scrum Software Development and Product Management part 1, part 2, part 3 and part 4.

Requirements, Agile and Scrum

Ryan Shriver - aka The Agile Engineer - has some interesting comments on the requirements in Scrum projects - and Agile more generally. I tend agree with Ryan’s comments for a couple of reasons. Firstly I don’t think Scrum (or other Agile methods) really understand them. Secondly there is a lot more to requirements than is commonly realised.

Because Agile largely comes from the developer view we tend to neglect the bit that comes before but actually that is even more important in the long run. In the short run it is not important, in the long run it is vital. Agile methods have too simplistic a view of requirements, its all “user stories”. As Ryan says, there is more to it than that.

Learning and Distributed teams

Andrés Taylor has some nice things to say about my book on his blog this week. Most of his blog is expressing concern about distributed teams and the discussion that follows is quite interesting too - Keith Briathwaite has continued on his blog. In my view distributed teams are generally a sub-optimal way of arranging your development process. However you may choose to organise in this way for several reasons. The main ones are:

1. You have no choice, for example: you need an expert in, say, database transaction processing on embedded systems and there are three guys in the world none of whom want to move to you Halifax Nova Scotia office.
2. You need your development team close to your customers and your customers are in different places.
3. Somebody somewhere has done a calculation that says the lost productivity is acceptable because the savings elsewhere. For example: having two developers in London and two in Bangalore is so much cheaper than having four in London that the 10% productivity loss is acceptable.

A few years ago we ran a focus group at EuroPLoP on Conways Law (What do we think of Conways Law now?) One of the insights I got from the focus group was:

• When ever you remove an informal communication channel create a formal one.

So.... Whatever the reason the important thing is to compensate for the distance. If you are saving so much money by spreading people out spend some of the money on flying people around to meet one another. Spend some of it on teleconferencing and video conference kit. Open the firewall to IM and Skype traffic.

Consequently companies that decide to spread their developers around should not then complain about travel budgets. If you are saving with the left hand you need to spend with the right so budget for it.

Learning to be Agile

Andrés Taylor comments remind me to confess to something. The title of the book is wrong.

The book, as published by Wiley is entitled: Changing Software Development: Learning to become Agile.

The title I thought agreed to was: Changing Software Development: Learning to be Agile. I’m not upset with Wiley or my editor, I only noticed this myself a few weeks ago (about a year too late). I’m sure if you look back through my blog entries you’ll see the mistake for yourself. I assume the small change was to improve the grammar (not my strong point.)

But, for me it changes the title quite significantly. Learning to Become Agile implies you learn then you are Agile. End of story. Learning to Be Agile - in my mind at least - can be read two ways. The first is as I just said, you learn then you are Agile.

The second is more subtle, and I’m not sure if I can express it. This is the “to be, or not to be” version. The implication goes both ways: true Agile implies you learn, learning implies you are Agile, think of it as “I learn therefore I am Agile” - in order to be Agile you must learn.

Maybe this second version is a bit of a stretch - does anyone else get it? - but for me its actually more important than the other reading and in many ways this is the true title of the work. Shame I never noticed the subtle change.

Credit crunch #2: Old banks for new

This might be a little off-topic for this blog but a) its a damn big story, b) says a lot about business and c) a lot of software developers are connected with banks. That’s my excuse so....

There are a couple of aspects of the bank rescue plans that trouble me.

First one: Now is the ideal time to open a bank. Does anyone have a few million to invest?

I say this in all seriousness because at the moment banks won’t lend to one another because they don’t know if the other bank is holding any “toxic” assets. The public is nervous about investing with banks because there have been several failures. Yet plenty of people still want to lend from banks.

Thus, my New Bank Ltd. will have no toxic assets because it has no assets to start with. We will ensure it takes on no toxic assets. Therefore, the public will save with us, other banks will lend to us and we can make loans (i.e. acquire assets) which other banks can only dream of just now.

Rather than prop up failing banks Governments should be encouraging new banks to set up.

Next: Banks which are too big to fail. So what do the we do? Merge them with other (bigger) banks, e.g. BNP buys part of Fortis, Lloyds TSB buys HBOS, etc. As a result we have one bank which is much bigger than the bank which just failed. So, if this bank gets into trouble...

See what I mean? If a bank is “too big to fail” and we put it with another big bank we have a potentially bigger problem.

Put these two ideas together and I think it makes sense to re-create the lost smaller banks. All the big banks are home to banking brands which are still remembered by the British public and I think the same is true elsewhere.

Royal Bank of Scotland could devolve Natwest - or even go further and recreate the National and the Westminster bank. Barclays could return Martins bank and the Woolwich, HBOS could spin off Halifax (as a mutal?) and Lloyds TSB could split back to Lloyds and TSB.

The parent bank would be left as a “Bad Banks” holding toxic debt and owned by their current shareholders. They would exist to manage what is left and salvage what they can. The reborn Natwest and TSB would be clean banks. And all these banks would be small enough to fail without bring down the whole system.

Reflections of an Agile Advocate

I am speaking at the BCS SPA London group next month. It only seems like 5-minutes ago I was at the BCS building talking to the BCS PROMS-G group but this is a different group, a different audience and a different topic.

Actually, its getting hard to find big new things to say about “Agile” so I’ve entitled my talk Reflections of An Agile Advocate. I intend to look at the state of the “Agile”, identify some trends and suggest were we are heading next.

If you want to come along it is free but you will need to register.

Are you really doing Scrum?

I’ve spent some time recently looking more closely at Scrum. One of the things that has come across is that Scrum is quite tightly defined. In particular it is tightly defined around its basic rules and the concept of a self-organizing team. And there are those who would argue that if you move away from some of the Scrum rules, or compromise on the self-organizing team then “you aren’t doing Scrum.”

Personally I don’t care if I’m not doing Scrum, what I care about is whether what I am doing is effective, whether it is improving and whether the customer is being served. That is why I documented Blue-White-Red or BWR for short. BWR is not Scrum, parts of it look like Scrum and it could be seen as a step towards Scrum but it is not Scrum.

As I’ve said before Scrum is where most of the attention is at the moment. A lot of organizations are looking at Agile and saying “Lets try it” and then deciding “Lets try Scrum flavoured Agile.” Therefore, it looks like a lot of teams are trying Scrum.

Using the strict definition of Scrum most of these companies are not doing Scrum. They think they are doing “Scrum”, they may even say they are doing Scrum, and the Scrum alliance may be happy to count then as “doing Scrum” but using the strict definition of Scrum they aren’t.

For example, a friend of mine specialises in Agile in Banks. In the summer he was hired to help a Big UK/International bank adopt Scrum. But, I don’t think the bank are removing their project managers, nor are they embracing self-organizing teams they way Scrum mandates. But if you ask them they will probably say “We are doing Scrum.” My guess is they are doing something closer to BWR.

I have nothing against Scrum, in fact I like it. I believe self-organizaing teams are the best way to organise work. I’m happy for the Scrum alliance to have its definition, I’m happy to help people adopt Scrum. If Scrum “succeeds” then Agile is growing and I’m happy.

But strict-Scrum isn’t a good cultural fit for many organizations. Leave aside which is the better way to manage a team and look at what organizations do. Most organization use some form of command-and-control, they have layers of managers telling people what to do. For such organizations to claim they do Scrum is wrong.

Perhaps one of the reasons why it appears Scrum is the most popular Agile method is simply the number of job adverts for Scrum Masters and Scrum Product Owners. Look this example pulled from JobServe recently:

“Media Project Manager - Scrum Master: ... looking for a Project Manager (Scrum Master) to work for one of their leading media/publishing clients in London. ... You will have a proven record in the delivery of content focussed online/development projects and have Prince II Practitioner accreditation.”

Firstly, on the strict-Scrum definition there is no Project Manager. So if you have a project manager you aren’t doing Scrum. Conversely, if you are following Scrum then you have self-organizing teams so you are not doing Prince II.

I have no way of knowing whether this organization thinks it is doing Scrum or Prince II but it sounds like they are doing neither. Yet to the casual viewer it looks like someone else is doing Scrum (and Prince II). I suspect this organization is doing some form of Agile and is simply looking to set filters on the CVs that come in. Looking for Scrum Master certification is like looking for Prince II certification, it doesn’t mean much.

The new challenge in Agile adoption

I have another piece in this months Agile Journal entitled “The new challenge in Agile adoption”.

What is Agile? and Who owns "Agile"?

When I talk to people about Agile I’m always keen to try and define “what is Agile”. I have two standard answers.

The first is to say “Agile” has come to mean “better” - as in “we cannot get software out the door”, “our software development is a mess” or “our senior management are fed up with us” and something has to change.

These people want to do “better.” Some of these people and companies would have considered ISO-9000, CMM(I), or similar a few years ago, and they may look for answers in technical products: UML, Ruby on Rails, ClearCase or something.

Since Agile is the current buzz, and since Agile has a lower barrier to entry than ISO-9000 or CMM then these groups look at Agile to solve their problems and to make them “better.” Some of these people don’t really know what Agile “is” and really it doesn’t matter.

The second way I define Agile is with two, sometimes three, tests:

1. Agile teams are listening and responding to their customers: they are delivering (software) which adds value to the business and responding to changing needs (whether from an individual user or a large market)

2. Agile teams are learning and improving

Notice I don’t talk about practices, values or routines. If you are learning and improving I don’t care what you do because I believe you will get their eventually. And since their is no reason why any existing Agile method is right for your company you are free to create your own, one that fits with your organization and your culture. Provide that is you meet the first test and serve your customers.

For the record, the third test which doesn’t always apply to my customers but which I need to keep in mind is:

3. When all the consultants, coaches, trainers and other who helped you get Agile leave you do not fall back to your old ways.

The reason for saying this now is to point out that Nobody Owns “Agile”. There is an Agile manifesto, there are Agile values and Agile principles, there are lots of books on Agile but there is no one single definition.

This is a strength and a weakness. It allows opinions to vary and new ideas to appear but it also means that you get different versions of “what is Agile” and they don’t always agree. For example, in the UK I am often at conferences with people like Steve Freeman, Keith Braithwaite, Kevlin Henney and Duncan Pierce, we agree on almost everything. We each emphasis different aspects of Agile, we each have different concerns, we approach engagements differently and we see the future differently. Dig deep enough and you will find differences.

If someone owned “Agile” - like RUP and PRINCE2 are owned - there would be things which would be ruled out. There would be someone who would come up to me and say “What you say about X is wrong.” Agile isn’t like that, its a broad umbrella, you have to decide for yourself who and what is best for you.

Agile is a story, it is a story that changes in the telling. It is post-modern, by which I mean, there are multiple versions which are all, simultaneously “true” - there is no absolute for truth.

There are a few people who I have more serious disagreements with, and I really wish they wouldn’t call themselves “Agile” but that is the price you pay of this freedom.

Look again at my second test: Learning and improving. This applies to your own understanding and definition of Agile too. Our understanding evolve.

This has to be your own understanding, belief and principles. Look at my third test: you can’t rely on others for ever.

And this divergence of views, competition in some instances, and new knowledge should ensure we are all aiming to do better. Back to where we started, and I think if you talk to any of the people I mentioned above they will agree: doing Agile isn’t important, its the end goal that is important and that means being better.

The only thing that remains constant is that second test: serving the customer.

Markets might be a little out of fashion at the moment but nobody is seriously suggesting a return to an Agro-economy or Communism Mark 2. The free market economy - or something that looks a lot like it - is here to stay and that means customers are here to stay.

Interesting piece on Kanban

I’ve written about Kanban Agile before, and got some useful comments so I was glad to come across this piece, Scrum-ban by Corey Ladas and Bernie Thompson. Worth reading to better understand what is going on in Kanban teams.

ACCU Conference keynote

I’m pleased to announce I’ve been asked to deliver a keynote at the 2009 ACCU Conference in Oxford.

Really this is quite an honour, when I look at who the other keynotes are they a serious names: Robert “Uncle Bob” Martin, my old friend Frank Buschmann and Baroness Susan Greenfield - yes a member of the House of Lords talking to the ACCU!

I think this keynote line up is very strong and shows the ACCU at its best. The line up shows three ACCU keynote traditions: internationally renown speakers from software development, someone from slightly outside the field who will make us think more widely and an ACCU member.

Right now I’m not sure what the title will be, I’m thinking about “7 Pillars of Agile Management”. Any suggestions out there?

Requirements led projects (not really a book review)

I’ve been trying to read Requirements Led Projects by Suzzanne and James Robinson for a few months and I think I’m about to give up. I’m about 150 pages into a 300 page book but I’ve been stalled for a while now and my attempts to re-start have not got far. This is a shame because I do like the book, and I don’t want to give it a bad review but if I can’t make it to the end then it has something lacking.

I bought this book because for the last year or so I’ve been very concerned about requirements on development efforts. OK, I’ve been concerned about this for a while but my level of concern has increased in the last year. So, I decided I should look into this subject some more.

Perhaps I read the wrong book. Write at the start to authors suggest their book Mastering the Requirements Process is the one to read if you want to know about writing requirements.

I briefly met Suzanne at SPA a few years ago and was impressed with her knowledge. I have no doubt that the two authors know there stuff and many people will find this book useful. But...

Firstly I haven’t been getting any real insights from this book. Its a problem I’ve found a lot recently, when you’ve been involved with as many development efforts as I have, and when you’ve read widely, it can be hard to find something really new and insightful.

Second, I think the authors have a bit of a mixed up view on who writes requirements. This is partly due to the book subject (projects and requirements) and partly due to the industry. To name the elephant:

Project Managers should not be writing or inventing project requirements.

Project Managers manage projects, they should be concerned with the when and who-else questions on the project. Those attracted to Project Management don’t (usually) have the analytical, inquisitive nature, or the training that makes a good requirements writer. The person who creates the requirements should be a Business Analyst or Product Manager. Project Managers need to be focused on near term deliverables. Requirements creation requires a long term (and possibly strategic) view.

However you wouldn’t know this from many job ads which confuse the roles of deciding what needs delivering with actually delivering it. I guess this book is written for project managers who find themselves in this situation.

On a small project the two roles could be merged provided you can find the right person. And there are a few people can do both roles. But these cases are the exceptions.

This book does set out to discuss requirements led projects so one might expect it to blur the Project Manager / Business Analyst divide but the authors blur the divide without acknowledging it. Sometimes they talk of the project manager gathering requirements and sometimes the BA.

It seems to me the authors are much more familiar with the Business Analyst as requirements writer and not Product Managers. As someone who champions Product Management I found their chapter on “Inventing requirements” to be quite naive. Product Managers are not mentioned and their is no sign that the authors know their techniques. The idea that nobody asked for a mobile phone so it was invented is very simplistic suggestion.

So, if your fairly new to requirements writing this could be the book for you. Unfortunately its not the book for me.

I’m reading some more about Business Analysts at the moment, and I’ve been sent some good links on product management so I’ll return to this subject soon.

Øredev

The nice people organizing Øredev in November have made me a postcard:


Allan Kelly at Øredev

Flights are booked and presentation prepared (just a little bit of PowerPoint, must try harder). I’m speaking on the Thursday, The Hitch Hikers Guide to Management.

Slides from Agile talk to BCS Project Management Group

Last week I did a talk to the British Computer Society (BCS) Project Management group - PROMS-G. They were a good audience, enught questions and points to keep it interactive but not so many that I didn’t get to the end of my talk!

I’ve now put the slides online - How and Why to Become Agile, as you might expect I tried to say something about the role of the project manager in Agile projects.

Someone (who has remained anonymous) has written a blog entry on the talk The role of Project Managers in Agile Projects.

Debunking some myths about Agile

I think I get quite a few comments on this blog and I publish most of them. Almost all of the ones I reject are spam/graffiti type, people looking to put a link to their site on my blog. Sometime I reply to a comment but not always, it depends on whats on my mind and how much time I have.

Last week a comment arrived on my Failures in Agile process entry from April 2007. Its worth pointing out that the comment has very little to do with what I wrote in the entry. Except for the fact that both my entry and the poster are concerned with “Agile failure” the content of the post seems to have little connection with what I wrote.

What’s interesting is that this post exists. Its a reminder that many people out there still believe a lot of myths about Agile development. The poster is right about some stuff but then just lists a bunch of myths with no supporting evidence or examples.

So lets take the post and dissect the myths:

• “Considering the reasons for failure you named someone may conclude there is no difference between Agile project failure and RUP project failure. In other words the software development approach obviously does not make difference.“

True: indeed I concluded this myself when I wrote: ”Failure of an Agile project looks a lot like the failure of a Waterfall or RUP project.“

The RUP folks increasingly claim that ”RUP is Agile”. There is long post on that subject but not today. If the RUP folks are right then you would expect RUP to fail like an Agile method because it is an Agile method.

There is a stream of thought that say that method doesn’t make much difference. Check out “Amethodical systems development: the deferred meaning of systems development methods” by Truex, Baskerville, and Travis if you want the full details.

It is widely felt that people, not process or method, are the key ingredient for successful software development. So how do you get good people? I think you need to grow them, develop your own developers. And I think the way you do this is through a learning culture. And I argue that Agile development has its roots in Organizational Learning so is better suited than RUP, SSADM, Waterfall, etc. to do this.

For my full argument: Buy the book, Changing Software Development.

• “The main bottleneck I came across is the failure to define good system requirements. In other words: garbage in - garbage out, principle applies here.”

True: Not sure it is always the main bottleneck but I think can be and it is always significant. This is one of the reasons I’ve devoted a lot of blog entried (and the odd conference presentation) to Product Management.

Although most Agile methods say little about requirements I think they do help. By improving deliver they free up management time and energy to think about that they actually want.

• “Agile wins more attention of management becacuse they discovered the way to shift the responsibility and blame for project failure to programmers...”

Not in my experience. I think managers have always blamed developers and developers have always blamed management.

But blame is not a very useful concept.

• “Downsides of agile:”

To the myths...

• “agile may only be used on small projects”
• “maximum 5 developers on project“

False: this myth started because the early writers on Agile hadn’t applied it to large projects when the wrote the first books.

I’m working with a large .com at the moment to introduce Agile to a large (50+) development team. Jutta Eckstein wrote about large Agile projects four years ago.

Software development always goes better with small teams. Since when did RUP, Waterfall, etc. etc. guarantee success? At the very least Agile is no worse than the next best methodology.

One of my personal mantras is: ”Inside every big project is a small project struggling to get out“. To find this project you need to a) be able to deliver, b) actually deliver business value.

• ”all developers must be higly skilled (no learning moments are allowed)”

First part: Highly skilled developers help any project go better. Agile is no different. (With the possible excpetion of Mongolian Hordes I’m not aware of any development technique that claims to do better with less skilled developers.)

Second part: False, Agile is all about learning, there are lots of learning moments. Again, buy the book, Changing Software Development - I’m not going to repeat myself.

• “developers must be in the same physical room with the project owner.“

False: there is a lot of experience with distributed development teams using Agile.
And once again, any development method goes better when teams are in the same room.

Frankly, distributing your development teams is always going to hinder your efforts. Putting them in one room is the most effective way. However sometimes you just can’t do it. And sometimes companies are prepared to take the productivity hit because the cost savings compensate for it.

This came up in the work I did on Conway’s Law.

• ”project owner must be available 24/7 since good programmers also work extra hours”

False: There is no law that says “good programmers work long hours” so the assumption is wrong. In fact, Agile emphases sustainability, you don’t get that by working people long hours.

Lets be clear: Agile does not mean working long hours. If you are working long hours you have a problem and you should fix that.

There is a problem with Karoshi (death by over work) in some cultures but this can’t be blamed on Agile or Lean. Yes it exists, yes it occurs at Toyota in Japan. No I have not heard of any stories of it occurring in Agile Software Development teams or at Lean enterprises like Dell or Amazon. Or even at Toyota outside Japan.

The original XP project, C3, did cause the near nervous breakdown of the first “Customer” - Business Analyst or Product Manager really which was a failure in C3. However, this does some way to supporting the view (held by myself and the poster) than knowing what you are doing (requirements) is important and thus you need more effort here.

To work someone to death or a breakdown is a problem that needs to be fixed.

• “agile does not support use of virutual teams or outsourcing constructions“

False: Where does this idea come from? I’d love to know so I can understand what to disprove!

OK, lets try...

”virtual teams“ - see above.
”outsourcing“ - ThoughtWorks has built a pretty big business as an Agile outsourcer.

• ”agile provides poor quality of software since documentation usually does not exist. If it does - it is written in "reverse engineering" style.”

False.

I have never seen any evidence that documentation leads to high quality software. Year ago I worked on rail privatisation, we had lots and lots of documentation, and then some more. The software was rubbish.

Agile provides high quality software because it simply wouldn’t work without quality. Look at TDD, pair programming, customer involvement, etc. etc. Its all about eliminating re-work, i.e. improving initial quality.

The tests produced by Agile developer are documentation, executable documentation at that but documentation all the same.

And reverse engineering documentation is actually the only sort worth having. Since design and requirements are emergent anything written in advance will change.

• “selling "agile project" as "fixed price & fixed scope" is mission imposible since scope of the project is not defined.“

False: it just means you need a different type of contract.

If Anonymous would like to reply to me please do, but please, next time you make some of these wild claims please explain your thinking or cite your evidence.

A book review of Changing Software Deveopment

The Agile Journal has a book review by Brad Appleton of my book, Changing Software Development. Thanks Brad! I think he put his finger on it.

Changing Software Development isn’t just another book about how to do Agile methods and techniques, its book about change and putting Agile development in the context of learning and knowledge.

Offshoring becoming more expensive

An interesting analysis in McKinsey quarterly about the increasing costs of off-shore manufacturing - Time to rethink offshoring. As is so often the case this piece is US centric, and it is about manufacturing not services, still, some of the data and analysis are worth looking at:

• Wage rises in China mean manufacturing workers now earn $4,140 a year up from $1,704 in 2003
• Weaker dollar also erodes the advantage (and since the pound is low at the moment the same is true in the UK)
• Higher oil prices mean getting raw materials to China, and finished products from there is also more expensive

They also hint at the delays in supply when you ship from China - because you have to order so far in advance and get stuff shipped.

In short, manufacturing high-tech products in China isn’t clearly cheaper any more.

And to proove the point, yesterday’s FT reports: “The latest cheap manufacturing site for European companies is not in Asia or eastern Europe but the US”. (Its a little more complicated than that but have a read for yourself.)

So what of the software industry? Lets apply this thinking, and extend it to India and elsewhere.

• Wages have been rising here too, I don’t know how much by but is manufacturing staff have more than doubled their pay IT workers can’t be far behind
• Weaker dollar has erodes the advantage (ditto the pound sterling)
• Higher oil prices mean flying staff between your offshore development centre and your actual location is more expensive

And of course you have the supply chain delays too. McKinsey doesn’t go into this angle greatly but there is a good analysis in Womack and Jones Lean Solutions: did you know stores have to order their Nike’s a year in advance? Bottom line: you can have lean manufacturing on the other side of the world but you face challenges if you want a lean company spread over that distance.

Regular readers will know I’m all in favour of developing software in India, Malaysia or wherever. However I think the benefits are exaggerated. Or rather, the downsides aren’t appreciated. Somewhere there is a balance.

Optimor: Mobile phone tariff comparison

Long story, I know a guy, who knows a guy who... gets us to Optimior. Their technology evaluates your mobile phone bills and recommends a operator. Their system is in alpha test and they’ve just analysed my phone bill. I won’t be changing operator soon but it looks good.

Tuft, Conway and PowerPoint

People I know who know about graphics and data visualisation tell me Edward Tufte is The Authority. I also hear he is a great presenter and his tutorials worth attending - if you into graphics and visualisation that is. So when I see his name on something I pay attention.

As regular readers know I have a thing about Conway’s Law. So when Tufte’s name came up in connection with Conway’s Law on a recent search I paid attention. Tufte’s point is actually about the inadequacies of PowerPoint.

I agree with him. I really dislike PowerPoint and wish I could give it - and similar tools - up. I’ve blogged about this before. I should report I have failed to give it up. I have two up coming presentations - BCS Project Management and Oredev - and I’ve prepared PowerPoint decks for both.

Why?
• Because they are a crutch to lean on, parts of me is scared without it
• Because the event organizers expect it
• Because I want the attendees to have something to take home
• Because it helps to plug my book (nice big picture!)

The comments and links on Tuft’s piece are even more interesting. Seems NASA are concerned about engineering by PowerPoint and the US military also have PowerPoint trouble.

All the more reason to redouble my efforts and kick the habit.

New writing, new patterns online

Two new pieces on my website for anyone who’s interested.

I’ve kicked off a new series of articles in the pages of ACCU Overload this month entitled On Management. The first of these pieces, Triangle of Constraints is now on my website. Alternatively it is available in the Overload August download.

After post conference editing my patterns from EuroPLoP 2008 are now online. These four patterns continue my series of business strategy design patterns for software companies. They are: Single Product Company, Whole Product, Product Portfolio and Product Roadmap.

I deliberately entitle these patterns “for software companies” although many people are quick to point out these patterns are applicable to many technology companies and to many companies in general. While I recognise this I stick to the “for software companies” formula for two reasons. First I write from experience, I won’t want to step too far outside my experience zone. Second to do proper justice to the wider context I would need to write longer patterns. I wont to keep these patterns short and readable - I aim for two pages and most of them end up at 4 pages!

Actually there is a third reason: a challenge to the reader. I leave some blanks for the reader to fill in, so the reader can make the pattern their own. I drop hints - some of the pictures and examples deliberately come from other industries - but leave it to the reader to bridge the gap.

The Open Source Software Myth

Once in a while I get asked my opinion on Open Source Software projects. Personally I think Open Source software (OSS) is great: Apache, GNU C++, Linux to name a few. But as a project management or product development technique I can’t say I recommend it. There are two reasons I give for this.

First there is no single OSS development model: Apache has a stack of IBM cash, GNU C++ is largely volunteers with chip makers (and others) contributing expertise and resources to help their own products, Mozilla was seeded by Netscape and has done a good job of marketing itself, etc. etc. Some OSS projects have paid development teams, some have single individuals and so on. It is not enough to say “We will do it open source” you need to be more specific.

Second: most OSS projects fail. “Go look at the number of web browsers on Source Forge” I say - a quick search this morning shows 19,362. There are lots and lots of OSS project that go no where. Commercial projects (famously) fail too but the important point is: OSS is no silver bullet.

So with this in mind I was interested to find and read a paper by Kieran Healy and Alex Schussman from the University of Arizona entitled: The Ecology of Open-Source Software Development. Although from 2003 I think the analysis and arguments probably still stand. (This paper appears in several places on the web so I guess it is already well know, maybe I’m late to the party.)

The authors did some analysis on projects in Source Forge and came up with some interesting results. Basically it turns out that when most people talk about the Open Source model, and successful examples, they are talking about the top 1% or less of all Open Source projects. The true OSS model has a long tail.

Taken as a whole OSS projects follow the Power Law - its that law again! The authors say:

“The median number of developers is one. The 95th percentile is 5. Relative to the whole field, only a tiny number of projects have more than a handful of developers. The median number of cvs commits is zero. At the 75th percentile it is 1 and at the 90th percentile it is less than 100. This indicates that there is little or no programming activity taking place on more than half of the projects. Examining the number of message authors across all forums shows that only projects at the 90th percentile and above have more than two contributing message writers.”

And later:

“In summary, we found power-law type distributions for all activity measures in our dataset. In each case, a tiny number of projects dominate an activity-type when measured by volume.”

The projects which are actively developed (in this study these include Crystal Space 3D, Open CASCASE, gkernal) are not the most downloaded (in this study CDex, VirtuakDubm ZSNES). In fact the authors say:

“Measures of user interest in a project — such as site views and downloads — are not closely related to measures of developer activity on a project.”

So what are we to make of these findings?

Well I think it bears out my initial comments. OSS is no silver bullet.

The papers authors propose three hypothesis for further consideration - and given that the paper was five years ago they may well have developed these further.

First they suggest that the involvement of professional developers is key. Despite the gifted ametuer image of some projects it helps to have professionals along. Second the role of project leader is critical - nothing new here perhaps but more evidence that OSS alone is not enough. (Actually, I was reminded of Fred Brook’s Chief Programmer model while I was reading this.)

And third, most interesting to me: the authors suggest that successful OSS projects with have hierarchical structure between leader and development team. Many OSS proponents (e.g. Eric Raymond) suggest a more chaotic structure in OSS projects which may not be the case (remember Healy and Schussman are suggesting a theory here without proof).

Personally all three suggestions ring true for me. There are wider lessons here too for the Agile and business communitiies.

There are those in the Agile community who see it as a route to emulate the success of OSS. However this study shows that the OSS success if not good enough for commercial projects.

Second some elements of leadership and hierarchy are necessary to have a successful project. In other words, relying exclusively on self-organising teams and emergent behaviour may not be enough. Some element of control is justified.

In the business community there has been a lot of talk in the last few years of applying Open Innovation - that is applying Open Source ideas to business problems and products. Proctor and Gamble have one example, Walkers Crisps in the UK is trying an Open Source type idea at the moment. If the OSS experience is anything to go by open innovation may come up with some good ideas but it is not enough alone.

Talk to the BCS Project Management group

I’ve been invited to speak to the BCS Project Management Group - PROMS-G - subject is “Why and How to become Agile”. Its rather short notice this one, 9 September in Central London. I believe all are welcome but advance booking is necessary.

Value Stream Accounting for Lean

Just to finish off my Financial problems with Lean blog post about the financial problems with Lean.

I read the second half of How to Manage Through Worse Before Better the in the MIT Sloan Management Review and while it was interesting it didn’t give my any more great insights. Basically the second half answers the problem described in the first half.

And the answer is.... Value Stream Accounting. Yes it makes sense, yes it is good, and yes its accounting. Thus I found it a little bit boring and I’m not going to describe it here. If you want to know the details read it yourself. Sorry to be mean, I’m busy at the moment so things have to get my interest to get prioritised.

Financial problems with Lean

From time to time the dark side of Lean surfaces. On the whole a lot of this dark side is bunk (rubbish), Lean gets the blame for something that isn’t really anything to do with Lean. Though Lean is not without its problems most of the well publicised cases (like karoshi, death by overwork) seems to have more to do with (Japanese) society than Lean itself.

But it hadn’t occurred to me until today that there were also financial problems with Lean, or to be specific, the transition to Lean. The summer issue of the MIT Sloan Management Review has a piece about financial problems (How to Manage Through Worse Before Better) which can afflict companies transitioning to Lean.

Although this piece is about manufacturing companies not software companies I think its worth discussing the reasons and how they might also effect software companies:

• Lean companies hold little or no inventory, so a company transitioning to Lean will reduce the amount of completed work held in stock (not to forget raw materials and work in progress). But this stock is also shown as an asset on the balance sheet. So reducing inventory reduces the value of the company.

• It is not only the transition company which hold stocks, so too do customers. As the company becomes more Lean the lead time for orders will reduce so customer no longer need to order so far in advance and hold buffer stocks. They will adjust their orders, rather than ordering 6 weeks in advance they may order 1 week in advance. Therefore sales will appear to reduce as customer change their schedule.

• Although the Lean will make the company more productive in the short run it is difficult for the company to realise this benefit. It is not possible to reduce the work force during the transition because managers and workers need to co-operate so managers can’t fire workers (well you could, but imagine what it would do to the rest of your change programme).

• Neither can the extra productive capacity be used for new manufacturing because the company is still in transition and it takes time to introduce new products to manufacturing and optimise the system along Lean lines.

So what about software companies? Actually I think they do, perhaps to a lesser degree:

• Software companies don’t hold stock, but work in progress could appear on the balance sheet, it all depends how the company accounts for R&D so this could be an issue.

• Customers might delay orders once they know they can, this depends on your sales model.

• Software companies face the same problem in laying off surplus workers, if anything the problem is worse. Even though most software companies I’ve ever seen don’t have enough people to do the work they are asked to it these benefits won’t show on the balance sheet or cash flow statement.

• Finding work for newly available resources is also going to be a problem. I’ve blogged before about the importance of Product Managers and the idea that The Bottleneck has moved - if you have developers who are more productive you need more Product Managers - so costs will go up!

Actually things might be worse in software development because of the quality issue. A Swiss friend of mine claims that his software company was forced out of business when they adopted TDD and improved quality. It seems many of their customers were buying new versions of the software, and paying support fees, to get bug fixes. Improve the quality, reduce the bugs and why do they need to spend more money?

My reply is always: its not much of a business model if you rely on your customers paying for fixes. But the point here is that during the transition phase you loose the revenue before the benefits kick in.

I’ve not read the second half of the Sloan piece yet so I don’t know how to resolve these issues but I think this analysis is helpful in understanding why companies find it hard to transition.

Agile control and management

I was expecting slightly more response to my “Why managers don’t get Agile” post last week because this is an issue that comes up again and again and again. Hans Wegener (of metadata fame) did respond and for some unknown reason his comment ended up on the wrong blog post (May’s post on making strategy) - his comment is here.

I certainly didn’t intend to come across as anti-control. True, I do believe that less control and more self-organization can improve results but I know that some control is necessary. The point i was trying to make is: Agile methods do not discuss the role of the manager much, and they appear to loosen control on the development effort. Therefore it is hardly surprising that managers don’t “get” Agile.

Actually I believe that Agile development improves control in an organization for several reasons.

First the illusion of control is exposed. Estimates, GANTT charts and “management by exception” never really controlled development work, they just presented an illusion of control. So much upfront planning was just planning theatre, it never really changed much, development work carried on much the same, work took as long as it took whether the estimate was 1 day or 1 month. Agile strips away many of these illusions - that’s why it is painful at first.

Secondly Agile improves control because work can be stopped at any time and still produce benefits. Stop a traditional project half way through and you have a lot of code which implements some features but is so full of bugs that it is usually unusable. Stop an Agile project half way through and you may have fewer features but the features you have are usuable, there is no need for a test-fix-test cycle.

The removal of the test-fix-test cycle also improves management control. Traditionally this cycle takes up an unpredictable amount of time at the end of the project. Because it is unpredictable control is lost.

Third - and final for the moment - because Agile teams are focused on delivering what the business wants they don’t develop anything else and do deliver what was asked for. Again more effective control.

However this third point does put a responsibility on the customer/business side of things to be able to articulate what it actually wants and to take a part in creation and verification. Again this might look like a loss of control but it isn’t.

For example, a traditionally request might be “Add a widget to the website” and at some unknown date in the future the widget would be added - the colour, size, shape and functionality of the widget might not be what was expected but was there. Such a request given to an Agile team is likely to result in a whole bunch of questions: “What shape do you want it? Colour? When by?” etc. etc. This might look like a loss of control but in fact the team is giving more control to the requester.

One of the things I always tell clients is that Agile exposes problems, and in this case a problem with the management of IT work has been exposed.

Hans ends his post with the comment: “I can't prove this, but I have a theory: developers don't "get" management” and I have to agree with him. Superficially management is like coding, its about organizing stuff, connecting things and putting things in order. However it is very different: the fundamental building block of management is not lines of code but people. Mangers work in ambiguous environments with a lack of information and few ways of testing a hypothesis.

I’m also convinced that many (even most) of the problems software development faces are the result of poor management not technology. Developing software may look easy but it is hard, not only do you need good coders and testers but you need good managers. Being a good coder does not make you a good manager and being a good manager does not make you a good development manager.

Using patterns to capture and communicate knowledge

I have a short piece entitled “Using patterns to capture and communicate knowledge” in the August issue of Knowledge Board. One small contribution to getting patterns used in a wider range of fields.

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.