Agile Lab - Training, Coaching and Consultancy Blog

Saturday, 5 December 2009 at

3 Reasons NOT to do a Web Development Project

If you've come to this page for whatever reason and you don't work on a web development project, I hope you don't mind if I ask you to leave. This is really private stuff, just for people who try to make websites for a living. Here are some other interesting posts on this blog which aren't quite so private, personal and painful: "What is agile?", "Why is it so complicated?".

OK, now it's just us. These are three reasons (excuses actually) for doing web development projects which I hear a lot. They can all be prefaced with "We're doing this project, even though we're losing money on it because..."

...this is a big name client, a famous name and so it would be good to have them on our client list.


But they're treating you really badly right? You find yourself doing about twice what you would do for any other client just because they're a big, famous name and you want to please them. If you have relationship like this with every big name client that you work with, how long are you going to last?

...this is only a small (money) project but there will be bigger ones from this client in the future.


This might be true. But this means that you have to especially careful to get the balance right between the value that you give to this new client and the money you charge. There's a terrible temptation to bend over backwards to please your new client, in the process losing money and even worse, setting their expectations for your relationship for the future.

If you are being extra nice to them because they're a new client, make this clear that that's what you're doing! Make it clear that you're giving them an introductory rate or a 25% discount or whatever. Use this small project as an opportunity to understand your client - and identify any potential problems. Could you really work with them on a bigger project?

...we need this project just to keep busy and get some money coming in the door.

Ouch, ouch, ouch. And that's just when it's written down. When you actually hear the pain in someone's voice as they tell you, essentially, "We're taking on this money-losing project because we need the money." Oh dear. Hard times. Tough choices. So what can you do, if you really do need the money? Well, one thing is to make the discounting that you're doing explicit. This gives you much better scope for charging your full fee later on any further work. Another, even better option, depending on the sophistication of your client, is to offer a high-quality, reduced scope, full-price solution e.g. "we can't give you the bespoke site you want for that money, but we could skin a wordpress site that gives you 95% of what you want."

But finally. This is the hardest alternative. If you don't think you can make money from the work, don't take it on. As the Zen master said, empty your cup so that it may be filled. Use the time to finish any work-in-progress that is lying around and get it finished. Use the time to improve your processes. Use the time to talk as a team about what the recurring problems are with the work you do, and to suggest possible solutions. Advertise to existing clients and potential clients that you can now take on and deliver work at short notice - for a premium!

Oh and of course. Get some training. I can do it at short-notice for a premium ;-)

If you liked this blog post, you might like these: "I'm your software developer and I'm listening", "John Seddon's Re-thinking Lean Service", "The Value of Something"


For further information, contact mark.stringer@gmail.com (07736 807 604)

Labels: , , ,

Monday, 16 November 2009 at

Do we need one?

When I talked about difficult conversations at Agile Yorkshire last week, the subject of "Hero Programmers" (HPs) came up. What is a "hero programmer"? Lets give ourselves a working definition. A Hero Programmer is someone who:

  • Is deferred to by all the other programmers
  • Has deep technical knowledge of the product/system.
  • Very busy, he works long hours, he pulls all-nighters for the good of the company – hey, he’s a HERO.
  • Widely regarded as indispensable by other people in the company.
  • Rarely takes holidays.

Sounds great. A hard-working, highly-skilled and very valuable member of the team. So what’s the problem? Well, there can be a few problems. Here are some other possible features of the Hero programmer.

  • Makes big technical decisions without consultation (i.e. changing the implementation language for the entire project).
  • Saves technically difficult work for himself rather than distributing it through the team.
  • Decides what features get worked on next
  • Regards himself as the architectural (or even moral, aesthetic) guardian of this system. And regards these ideas as higher than any mere “business” goals.
  • Refuses to pair program (often suggests code reviews as an alternative, though they rarely actually happen).
  • Rejects as a "waste of time" or a "fad" any of the basic technical improvement practices suggested by Agile: continuous integration, refactoring, Test Driven Development and even sometimes source code control.
  • Is DEEPLY suspicious of consultants.

Do any of these sound familiar? Is this you?


When I talked at Agile Yorkshire the subject of "Hero Programmers" (HPs) came up when I was talking about issues around identity. I talked about 5 identity dimensions which I got from this book - "Beyond Reason":

  • Appreciation
  • Autonomy
  • Status
  • Affiliation
  • Role

And when you think of Hero Programmers in line with these identity dimensions you can see how difficult it is to budge an HP. Along each of these dimensions, our HP is strongly rewarded. They get lots of appreciation – bosses, project managers, customers are grateful when they finally get the functionality that they want. Because the HP is the only one that can do a lot of the trickier bits of development they have the autonomy to decide what gets done, in what order. In the company and sometimes also by customers the HP is regarded with high status.

Very often, the HP's affiliations are not to the team that he works with. He may also feel an affiliation to an international band of coding gurus whom he talks to daily online and sees at conferences. To him, what they think of what he does is far more important than his work colleagues. And this brings us to his role as he sees it – keeper of the pure flame of the architectural (or sometimes even artistic, ethical) integrity of the project.

He probably gets very sniffy whenever anybody talks about money.


So, along 5 different measures of positive identity, the position of HP buries the needle. No wonder HP’s don’t want to change. From the HP’s point of view, the only direction is down. If he changes the way he works, if he gets promoted, he moves away from things that he knows (software development) to things he doesn't know (business, team-leading, management).

Do you have a problem with an HP? Here are some things you might try that I know have worked elsewhere. Most of these suggested approaches involve increasing the HPs status and autonomy rather than attacking and restricting them, which is what the usual (and greatly feared) move into team-leading and project management threatens:

  • Reduce the work load for the HP: Insist that he take his holiday. When he is at work, he shouldn’t be max-ed out, he should be given time to teach others what he knows and think strategically.
  • Turn the HP into an internal consultant – whose job is to roam between projects and solve the really hard problems.
  • Turn the HP into a "fellow" who's job is to think great thoughts and come up with new ideas.
  • Get him to talk and teach, write books, to your staff and on the conference circuit. It will be worth the travel expenses.
  • Turn the HP into an external consultant, hire out his specific, excellent skills to other companies.
  • Turn the HP into an open source guru – put some aspect of your project out in the public domain and give your HP the task of leading it.
  • Turn your Hero Programmer from a Code Geek into a Business Geek. A friend of mine used to write the software for the hedge fund that he part-owns, but now he involves himself far more in the minutiae of the tax laws and the mechanics of limited liability partnerships.

One thing that occurs to me is that if you keep seeing the same situation again and again, it must be a "stable" situation – what John Nash would call an "equilibrium". There are powerful the drivers are to keep somebody in this role (run through the identity list and think about the role of project manager – why would anybody want to be one?). The trouble is that it's a local equilibrium that prevents any kind of positive change. If a team that has formed around a "hero" programmer, out of frustration with this stability and stuck-ed-ness, very bad things can happen.


Yeah, yeah, he's a life-saver, but you don't have to work with him


If the HP is a founder they can be ousted in a coup by other board members. Or if the company finds finance, or is taken over, they are swiftly removed (VC’s have developed the sharpest skills for dealing with HPs through sheer necessity). Often the team or the company around the HP just evapourates, the juniors get less junior, read the writing on the wall and walk away. But these are actually good outcomes compared to the most likely outcomes in the short term.

Things carry on as they are.

Labels: , , ,

Friday, 17 July 2009 at

What Could Possibly Go Wrong?

We know all the theory right? So now all we have to do is put it into practice? How hard can that be?

I read a blog post a couple of weeks ago about how to keep your brain sharp as you get older. This is the kind of thing that is to Twitter (with the oldest average age of any social media network) what relationship quizzes are to fashion magazines.

I don't remember most of the recommendations (probably because I'm getting old - boom! boom!), but one of the suggestions was that you try to do things with the "wrong" hand. I'm left-handed and all the way through school struggled to write as quickly and as neatly as my right-handed school mates. And trying it out has revealed to me a marvellous instant demonstration of the difference between theory and practice.


Right-handed writing, the first time I tried it


So, for several weeks now, I've been writing my morning journal with my right hand instead of my left. It isn't easy. I'm a lot more relaxed now, but when I first started doing it, it was physically demanding. I found myself having to deliberately stop myself from gritting my teeth and curiously jutting my jaw - sort of like somebody might act if they were trying to amputate their own leg in an action movie.

And the writing itself was diabolical.

I would often find myself just heading off in the wrong direction with the pen, or "losing it" altogether and not being able to write anything at all.

But of course, the more I've done it, the easier it's got. Very early on in the process it dawned on me "Hey! I already know how to write! I already know all the letters of the alphabet and how to put them in the right order. In other words, I already know all the THEORY of writing, but that doesn't mean that it's any easier to put the thing into practice."


Three weeks later - better but still room for improvement


When you try writing with your wrong hand you realise very quickly that putting theory into practice is a separate process from understanding the theory. For handwriting, putting theory into practice involves changing the way muscles and neurons work, storing new information inside them, and that's a non-trivial process that takes time.

There's the learning that, and then there's the learning how and very often they're two seperate processes.


Some points that I've noticed about trying to experimenting with this radical change:
  • If I take the trouble to visualise a word before I write it, writing the word feels much easier and looks much better.
  • Doing something so strange, results in the whole of your body tensing up which results in terrible handwriting. But if you relax too much, that's no good either, nothing happens. You have to actively look for a balance between focus and relaxation.
  • When you first start doing it, you're knackered after half an hour, actually, probably about ten minutes.
  • Latin characters are designed to be written right-handed. There's a kind of rolling flow to writing right-handed that you never feel when you write with your left hand. Every now and then I feel this "flow", normally when I forget that I'm writing with the wrong hand and concentrate on what I'm writing.
  • Exploring all the possibilities of writing with my right hand, cutting loose, letting go, scribbling and shading, drawing big shapes and small shapes, tiny stick men and perfect circles, seems to improve things just as much, if not more than simply concentrating tighter and tighter control and getting the letters perfect. Periods of "going crazy" scribbling and doodling followed by focussed concentration seem to work best of all.


Left-hand writing, perfected over about 36 years.


Any of this got anything to do with Agile? With training? With Lean and Kanban and experimenting with new methodologies? I dunno, what do you think?

For further information, contact Mark@agilelab.co.uk (07736 807 604)

Labels: , , ,

Thursday, 16 July 2009 at

Notes on Rachel Davies workshop "The Role of the Agile Coach"

Rachel Davies ran a very interesting workshop yesterday at MiniSPA2009 on "The Role of the Agile Coach."

I won't give away the details of her workshop, but suffice to say that it involved some people working on a task and other people taking management roles. It looks like a very simple activity, but to me it felt like a re-run of the Stanford Prison Experiment with non-toxic glue and feathers.

Some observations from the experience:
  • Even though Rachel's an Agile coach and this workshop was supposed to be about Agile coaching, everybody, especially those in management roles seem to treat this as a waterfall project, even down to trying to treat the instructions that came with the activity packs as a fixed spec.
  • I was a worker, and as a worker my main motivations were to bond with my other workers and to make myself useful. I didn't really take any notice of the coach who was there supposedly to ask questions.
  • Comments from the two people who were asked to take on management roles were almost all critical. In a sense, this was an artefact of the task - what else did they have to do but point out what they thought was going wrong?
  • The spec for the task was very loose, but that didn't stop some people who were in management roles adding in extra assumptions, assuming spec where there wasn't any. And assuming that part of the task was to hammer down the spec.
  • I found myself saying "We thought we were being creative, but management just thought we had no idea what we were doing." Oh boy did this chime! To some degree with my experience at Xerox, but especially with my experience working in research at Universities.
  • We got fascinated with the task and missed a (perceived to be) crucial aspect of the spec. In the end I fixed this as I walked up to submit our entry. "Management" on our team perceived this to be a grave failing, even though my last minute solution worked.
  • As a team of workers, we instinctively seemed to understand that we had to feel each other out and understand what we capable of - I think this is what's called the "Forming and Storming" sections of team building. Management focussed instantly on the "Norming and Performing" and fretted and criticised as it watched our "Forming and Norming" activities.
For further information, contact Mark@agilelab.co.uk (07736 807 604)

Labels: , , , ,

Tuesday, 16 June 2009 at

Six Things you Really Need to Know about Your Customers

I'm running Introduction to Agile Courses in London on 9th July and in Bristol on 5th August.

This post is mainly aimed at people who are trying to write software for their customers, but it probably applies a lot wider than that. When I run training courses on how to handle difficult conversations, I try to get across the idea that you should try to move a conversation away from message delivery, to information discovery. But when you do that, what information are you trying to discover? Well, these six areas aren't a bad place to start.

Timing

Following on from yesterday's post, it's a good idea to understand as much as you can about your customer's timing issues and expectations. This doesn't just mean time-scales and deadlines for the projects you're working on, but also the kinds of timings that are important in their business. It means anything else that you can possibly think of related to time. When do they get in the office? How late do they stay? In their business what is regarded as a reasonable response time for a query? 2 days? 20 seconds? What's the planning horizon for their business? There might be lots of different answers. For example, in advertising, pitches might need to be knocked up over night, but billboard space needs to be booked three to six months in advance for a campaign.

Dali melted timepiece

What are the timing issues?



Comprehension/Comodification

For want of a better clumsy term or two, what I mean is, is the business that your client is in a new, pioneering innovative business, or is it completely understood, a commodity, where competition has to be on price and efficiency and organisation has be to perfect. People who work in industries that are comprehended and comodified can find web and software development utterly bewildering. A common recent example is the experience of producers from television moving over to "produce" (i.e. project manage) web development projects. The costs of producing a 1 hour documentary or a 30 minute studio-based sitcom are well understood. The costs of producing a successful social media website aren't.

Campbells soup

Is your customer's business a commodity business?



Money

How do your customers make it? Which of their activities makes loads of cash? Which of their activities make hardly any cash? What is expected of your software in relation to making money? What are their margins? They may not know some of the answers to these questions. Even if they do, they may not want to tell you. But the more you know about this, the better placed you are to deliver them the software they need, within a suitable charge structure. For example, if they plan to do the bulk of their business using your software over long period of time, maybe a maintenance and licensing deal makes more sense than an upfront fee. If they intend the website to be more profitable than any other business that they've ever run, they might have a problem.

Suppliers

What kind of relationship does your customer normally have with suppliers? Are these relationships based on good personal contact or on contracts? Does your customer make money by playing one supplier off against another to get the lowest price (as do, for example supermarkets?). What sort of response do they expect from their suppliers in terms of responsiveness, exclusivity, even level of formality?

Identity

Who are these people? How do they see themselves? Are they ruthless business people? Intellectuals? Great craftsmen and women? Artists? Teachers? Curators? Healers? COmmunicators? A large number of people that you meet in business never wanted to be in business and aren't in their post entirely for the money (or at least that's what they're telling themselves). You need to know why they're there, otherwise you're conversations with them will make very little sense.

Maria Callas

How do you customers see themselves?



Software Knowledge and Experience

What knowledge of the internet, the world wide web or of software is there in the business? What knowledge is there of what the internet/web/software can and cannot do? Does anyone in the business understand what bespoke software is? Does the business have any experience of commissioning bespoke web, or any other kind of software in the past? Was commissioning software a good or a bad experience? What was good about it? What was bad about it?


What kind of technology do your customers consider to be "state of the art?"



This is a far from exhaustive list, but the better the answers you have to these questions, the better the chances for the project as it progresses. I also hope it's clear how important it is to know how your own organisation would answer these questions. What are your timing issues? How you do you see yourselves? What is your identity? How do you make money? How do you want or expect to be treated as a supplier? More to the point perhaps, what's your experience of software and the internet?

For further information, contact Mark@agilelab.co.uk (07736 807 604)

Labels: , ,

Monday, 15 June 2009 at

The Secret of Comedy (and Project Management)

One: Do you want to know the secret of comedy is?

Two: Yes, I do want to know what the secret of comedy is.

One: OK, I want you to stand there, opposite me and ask me in a strong, loud voice "What is the secret of comedy."

Two: What? Now?

One: Yes, now.

Two: OK, here goes. Are you ready?

One: Ready.

Two: Sure?

One: Certain.

Two: And what is it I say again?

One: [Through gritted teeth] What is the secret of comedy.

Two: OK, OK, secret of comedy. Got it.

One: All right then.

Two: All right then. [pause] What is the....

One: TIMING!


A friend of mine won a contract to build a website for a Mainstream Media (MSM) company. He thought things were going well. They had some kind of spec in place (this wasn't an Agile project). There'd been meetings the MSM guys had seem casual and relaxed. They didn't seem too bothered about contracts. My friend got the impression that this project was being done "under the radar" of normal corporate procedures. He was a bit surprised. He'd heard bad things about this company, maybe they were wrong, maybe he got lucky. They were just approaching two weeks before the site went live and everything looked to be going smoothly.

Then the telephone calls started. We've decided that we need all this extra stuff, by the end of the week. What about this? What about that? We can't host it in this country, we have to host it in this other country for legal reasons. Talk to our lawyers, they'll explain what they're going to do to you if you host it in the wrong country. What do you mean that's going to take an extra week? It can't take an extra week. Then the contracts started arriving. Extra clauses saying that the developer would bear the costs of any extra work, hidden on page 237 of a 400 page contract. Suddenly, when they turned up to meetings, there were five times as many people turning up from the MSM company's side and most of them seemed to be lawyers. And they weren't nice people. If my friend didn't do exactly what they told him, if he didn't sign the contract, they made it clear, he'd be out of business.

My friend, did what he could. Bravely, he refused to sign a contract he didn't have time to read. He agreed some kind of halfway house with the hosting, his loyal developers pulled several all-nighters to do all the changes that were required. They got something out for the deadline.


The first rule of comedy - timing



The next time I saw him I was expecting more tales of lawyers contracts, unexpected changes. But when I asked him about the project he just shrugged. "They seem to have lost interest."
"What?"
"That's how they work. They get all worked up before a release date, and they lose interest. They're straight on to the next thing. They're not worried about you any more. We've been to a few meetings, they're relaxed, just like they were three or four weeks before the deadline."
"Did you sign their contract?"
"No."
"Did they pay you?"
"Yes."

When I run my Introduction to Agile course over more than one day, (for example, the Managing Digital Projects Course) I start the second day with a discussion of negotiations and difficult conversations. One of the things that I recommend you try to do is to move from adopting a negotiation position to discovering value, to move from "message delivery" to a learning conversation. And I think one of the most important things for each side in a potential "difficult conversation" to learn about each other is their expectations of timing and time-scales.

For further information, contact Mark@agilelab.co.uk (07736 807 604)

Labels: , , , ,

Wednesday, 10 June 2009 at

5 Steps to Internet Innovation?

I was please that it was working. I could see how this might be regarded as a bit far outside the remit of "Managing Digital Projects". But as I mentioned that the key assumption that the newspapers had been hanging onto - that they could make money from selling content - had been pretty comprehensively blown out of the water. She started shaking her head and then angrily asked -
"But then how ARE we going to make money?"
"I dunno, maybe you aren't. Maybe somebody else who's got a business model that works on the internet is going to ruin you."
"But that's not fair!"
"No, maybe not, but that doesn't stop it being true."
She kept shaking her head. But finally she said.
"Yeah, you're right. You know, you should tell my boss this. I think he needs to do this course". She was all limp and defeated. [depression]

She didn't actually work in the newspaper industry but she was clever enough to see how the internet was going to affect how she made her living just as radically. She was in an industry that had once been the epitome of respectability and was now overrun with spammers and charlatans.

I’ve spent a lot of time recently talking to people who work in the publishing industry whilst teaching my course "Managing Digital Projects." The format of the course was a bit unusual: the first two days of the three-day course are separated from the last day by about 6 weeks. The idea is that people who attend the course can go away and try out some of techniques that I've suggested and report back.

The structure also has another benefit. It gives me a chance at the end of the two days to ask the course delegates if there was anything that they wanted me to include in the last day, if there was anything that I hadn't covered.

One question that someone asked me in the first 2 days was "What's the difference between a digital project and a digital product?"

I thought a lot about what the difference was between a digital product and a digital project. I realised that there was a kind of technical issue around how to create e-books if all you have is the hard copy. Lots of stuff to do with arranging for people to do double keying in the Phillipines and something I know absolutely nothing about. But I also suspected that hidden inside this question was a kind of assumption about what a digital project is - that it's just an opportunity to sell the same kinds of things that you used to sell offline - products, on-line.

And this lead me to think about about Elisabeth Kübler-Ross's five stages of grief (sorry, this is how my mind works).

Denial, Anger, Bargaining, Depression, Acceptance.



There's quite a lot of criticism of Kübler-Ross's account as a description of grief, first of all because most people who are grieving don't seem to be denying anything. But it strikes me as a brilliant and useful model for lots of other situations where somebody is being told something that they don't want to hear. And this interests me partly because, as part of the MDP course, I teach how to deal with difficult conversations, and partly because:

as a consultant and trainer that's exactly what I spend most of my time doing: trying to tell people things they don't want to hear.



I realised that people who are asking me to talk about what a digital product is are actually in denial. The web is going to bring about a massive wave of change in their world. And they don't want to know about it. In the course, I used this marvellous blog post by Clay Shirky about the terrible state of the newspaper industry to illustrate just how powerful and destructive denial can be. The newspapers have known that the web is going to rock their world for at least ten years.

And their main response has been denial.


To be honest, I was a little worried about this section, even though I put it in the "and finally" slot at the end of the day. Even for me, it felt a little bit off beam, but:

I don't think I could have got a better response.

Labels: , ,

Tuesday, 26 May 2009 at

Timing and Music - The Tunnel and the Timeline

Following on from my posting last week about different ways of seeing time - it occurred to me that these two ways of seeing music are in fact different ways of seeing time. Why did the designers of "Guitar Hero" choose a tunnel view of music rather than a time line view?

Is it because a lot of people find it much easier to deal with than a time line view? Why didn't they extend it to 8 notes? Does it break down and get too complicated? This is the way you store music, for example on a pianola.


Guitar Hero - Tunnel Vision? The notes you have to play flow towards you



Why is conventional music notation stored on a timeline? What are the benefits?


Manuscript Music. Remind anyone of a Gant chart? OK, a very, very busy one.



Coming back to Agile, is Agile a method of taking a tunnel view on a time line? Hmmph. Dunno, and that's all I've got time for today. Still think good project management is about knowing when to use which view and how to switch between the two.

For further information, contact Mark@agilelab.co.uk (07736 807 604)

Labels: , , , ,

Friday, 15 May 2009 at

Trade-offs

A really good way of improving the exchange of information between clients and suppliers is to try to get them to tell each other about trade-offs. Every business has them.

When you're buying a car or a coat - do you buy the cheapest? Thought not. So what's wrong with the cheapest car? What's wrong with the cheapest coat? OK let's make a list: horsepower, features, handling, quality, style, having to wrestle someone for it in Primark.


Primark - Pile it high... (pic courtesty of adotjdotsmith)

Do you buy the absolutely best quality? No. The most possible horsepower no. Do you by any chance instinctively understand that when it comes to cars or clothes there are whole bunch of trade-offs? You can have cheap, but it won't be fancy. The faster it goes, the less likely it is that you can get a baby seat in it (or get baby vomit out out of the carpet). You can have top-quality cashmere haut-couture but it won't be cheap and you probably won't want to wear it when you go to the gym. You can have cheap, but don't expect it to fit.

Get the idea? It isn't just one trade off, there are lots. You don't really understand anything, until you understand the tradeoffs. And it's more complicated that that. In software development they're very often three way rather than two-way trade-offs.

I took part in a panel discussion where one of the other members - Chris Heilmann - said that whenever he starts talking to clients about writing software, he draws three circles and labels them "Cheap", "Fast" and "Good". Then he tells his clients that they can have any two - that's at least a start at getting his clients to understand that there are trade-offs.


Expensive? Yes. Stylish? Yes - but maybe not the right thing for the beach...(pic courtesy of Tammy Manet)

When we first started doing Agile training, we had great difficulty explaining the difference between the Agile concept of stories and terms used in other design methodologies such as "Use cases". Things got much easier when we started to talk about stories as "negotiations" (or trade-offs) between scope, priority and effort. Stories are dynamic. Each story is an exploration of a possible trade-off. When you start to think about things like this, you begin to realise what an improvished, static and inadequate thing a specification is.

For more about trade-offs, read from Gerald M. Weinberg - Secrets of Consulting.


For further information, contact Mark@agilelab.co.uk (07736 807 604)

Labels: , , , , ,

Tuesday, 12 May 2009 at

Agile Training - Why Bother?

This is an article about a blog post I don't like. Here is one by Paul Dyson on Agile project management that I really do like. Why aren't many other people thinking so closely about what the project manager actually does?

Why Bother?


Why bother with Agile Training? Isn't it just a waste of time? When you search for "Agile Training Blog" using Google - one of the first posts that comes up is a three year old post on a dead blog (hey you Google boys - are you sure this is right?) claiming that Agile training is a waste of time. The gist of the post is that when you attend an Agile training course you're going to get one of two things for your money: either you'll get taken through all the Agile concepts or you'll be regaled with war stories of the trainer's Agile experiences.

Education Bad


The point of the author of the "Why Bother with Agile Training?" blog post is that either of these approaches is a waste of time. If the course is just a lecture that takes you through the standard Agile ideas and concepts, you could have just as easily read about these in a book. If the course is just a collection of war stories, the chances are that they aren't going to apply to your situation.

Wrong and Wrongerer


I don't agree with either criticism. It's always useful to have someone who understands the material to take you through it. There are a couple of aspects of Agile - stories, velocity - that in my experience people don't immediatiately "get". And the idea that you can't learn from other people's stories because they aren't in the same situation as you is just strange. How else could you learn most things? If someone tells you not to put your hand in the fire, because it burns, what do you do? Say to yourself? "Oh that was a completely different fire, not comparable to this fire at all. Ow! Ow! Ow! Don't just stand there! Call an ambulance!"



Can you Feel it?


But the most important reason why I disagree with this post is because I think there's a third kind of experience that you can get from training. An experience of what it feels like to do things in a new way. And that's why I work really hard to develop and improve the exercises that I include in my courses. Through the exercises, I want to give people an idea of what it actually feels like to take a brief for a project, break it into stories and then develop it iteratively, using time-boxed iterations. By the end of these exercises, there's a much better chance that they "get" what I mean by a story and have a feeling for how to calculate velocity and use it in future iterations.

fire - like they say in the war stories - it burns
Fire - like they say in the "War stories" - it burns. (Picture courtesy of . SantiMB .)

For further information, contact Mark@agilelab.co.uk (07736 807 604)

Labels: , , , , ,

Wednesday, 6 May 2009 at

Seven things that you should know about Agile

Here are some thoughts I keep having about Agile which I don't think I've written down anywhere.

1. Agile Moves Difficult Conversations: Agile moves difficult conversations - it doesn't remove the need to have them, or the need to know how to have them. We're in the uncertainty and ambiguity business. If it was certain and unambiguous, there'd be a macro to do what we're doing and we'd be out of a job. Management of digital projects happens where the rubber of software development hits the road of actually business requirements, this is always going to be a point of friction that smells a bit of burning.

2. Agile is more convincing when it's running: Agile is much better when it's running, but a lot of the training, documentation and persuasion is (and has to be) focussed on what it's like to start up an Agile project. People are never really going to go for Agile until they "get" what it feels like to be in the middle of a well-functioning Agile project. One way of getting people involved in the Agile process is to ask them the favour to suspend judgement, or perhaps work against their better judgement. Not forever, but for an iteration or two(I wrote a bit more about why Agile looks better once you're actually doing it here).

3. Yeah yeah Agile - it's a People Problem: Talk all you want about processes, but in the end, it's always a people problem (I was reminded of this reading Gerald M Weinberg's "Secrets of Consulting").

There is an oh so seductive little delusion that almost everybody is susceptible to - if we talk about people using systems language and mechanical terms like "man month of effort" and "design resource" we can somehow magically get over the fact that our star Java programmer has BO and our lead designer needs to up his anti-depression medication. Sorry, not going to happen.

4. Agile isn't permission to start speaking Klingon or Elvish: If you start talking an entirely new language to your customers and your managers you're going have problems. Agile might show you that there's a way of writing software that really works. Great. That doesn't mean that you're not going to have a gargantuan task communicating this to other parts of your organisation and to your customers. This is an important part of your job as a project manager. It's no good giving people who want a planned project a "if you want a guarantee buy a toaster" attitude. To a large degree, you're going to have to at least *start* making Agile work within the terms that they already understand. You have to square this circle. That's your job - if it was easy, there'd be a macro for it and you'd be at home in your boxers watching daytime TV.

5. There is no problem: Everybody and everything works perfectly already. Yes, you heard me. Yes, I know, I know, I know. Shut up and listen! Deep breath. Imagine what I've just said is true. What are you not seeing, if it is true that the mess you find every morning in the office is the best that all those people can do when they're working perfectly? The status quo is some kind of equilibrium between a whole bunch of powerful forces. In many ways that are invisible to you, it's probably the best and safest deal that the people working within it can get (read some John Nash before you start arguing with me). When you start to change things you're going to find out what some of those powerful forces are. You're maybe going to find out why what looks like poor performance isn't so bad after all.

6. You're a Knowledge Worker - and you don't know what you're doing: If you're talking to me, you're probably not a designer, or a programmer, or a project manager, you're probably all of those things and none of them all at once. All that posturing about how you're not going to do something because it doesn't fit with how you see yourself or how you were trained or what your job title is is really tiring (although part of being a project manager is probably to have those conversations). You're a knowledge worker - which paradoxically means that you spend most of your time doing things that you're not trained to do and have no idea about. That's what modern work is like. Read some Peter Drucker.
7. If I hit you hard enough, you will cry: You are not Chuck Norris - and will therefore get your ass kicked, in difficult conversations, in your attempts to introduce Agile to your organisation. Your success will not be measured by the number of times that you got your ass kicked, but by how quickly you recovered from said ass kicking and what you learned from it.

For further information, contact Mark@agilelab.co.uk (07736 807 604)

Labels: ,

Tuesday, 24 February 2009 at

Iterative Development

Mark talks about the process of iterative software development. This was filmed at our "Introduction to Agile Methods" training course that we did in Plymouth in January 2009.



For further information, contact Mark@agilelab.co.uk (07736 807 604) or Matt@agilelab.co.uk (07713 634 830)

Labels: , , , ,

Wednesday, 18 February 2009 at

Good to see...

...that I'm not the only person thinking about this "difficult conversation" stuff in relation to project management.


http://commentsonmyworld.wordpress.com/2009/01/08/good-pm-3-convey-bad-news/


For further information, contact Mark@agilelab.co.uk (07736 807 604) or Matt@agilelab.co.uk (07713 634 830)

Labels: ,

Wednesday, 31 December 2008 at

Because I can't afford sky writing...

...I'm just going to set this in big bold text.

Almost every difficult conversation will involve strong feelings. It is always possible to define a problem without reference to feelings. But that's not true problem-solving. If feelings are the real issue, feelings should be addressed.

This is from a book I'm reading: "Difficult Conversations: How to Discuss What Matters Most"


For further information, contact Mark@agilelab.co.uk (07736 807 604) or Matt@agilelab.co.uk (07713 634 830)

Labels: , , , ,

Friday, 19 December 2008 at

Overhead in a London Cafe

MAN: OK, so what would you need in that report?
WOMAN: So how's that report going to work?
MAN: It would be like that CSV -
WOMAN: Oh, so you've got to enter all that information?
---------------
MAN: So one's going to be a client email and one's going to be for these guys - one for the organisation.
---------------
WOMAN: I thought we were working together on this.
---------------
WOMAN: You're sure I couldn't get this cheaper elsewhere?
---------------
WOMAN: I only have £10,000.
MAN: But you only have to sell 4 ads...
WOMAN: It doesn't work like that - what are you saying, that you want to invest?
MAN: It's just not worth our time. It's not software that we'd want to use again, it wouldn't be worth our time investing.
---------------
WOMAN: Why does it cost so much? I mean, if I was going to sing, I could charge £10,000
---------------
WOMAN: I thought download meant music download.
---------------
MAN: You could try and get it cheaper elsewhere, but if you get cheaper site, it will be done by cheaper people. You know I've seen people try to get sites done using Ukrainians...
WOMAN: What are you saying? They're inferior because they're from a different country? They're cheap because they need the money, they're not dressed in fashionable clothes like you, they're not going on fancy hoildays.
---------------
WOMAN: I think your developers probably have a name for you that you don't know.
---------------
WOMAN: Now "forward to a friend", when you click can that... What do those words mean?
---------------
MAN: Hang on a minute, why are we forwarding to a friend?
---------------
MAN: But the link won't work
WOMAN: Doesn't matter, it's just for marketing
MAN: But that's going to be bad
---------------
WOMAN: I thought you knew about that.
MAN: I did but...
WOMAN: Now you're actually thinking about it - how it would work.
---------------
WOMAN: That would be brilliant J
MAN: Yeah - that would be brilliant, but it would cost.
---------------
WOMAN: It wasn't part of the spec - that's what you're gonna tell me six months down the line.
---------------
WOMAN: You know, I think you have a bit of OCD (Obsessive Compulsive Disorder). But I think you do have a bit. I'm a victim because I'm having to pay for your disorder. I mean other people have medication.
---------------
WOMAN: And can we change the colours
MAN: Yeah - but it's going to cost for you to change
WOMAN: So in that case, maybe we should keep it as neutral as possible.
---------------
WOMAN: Do you guys have employees or are they contract?
MAN: Both.
WOMAN: Really? You have full-time?

For further information, contact Mark@agilelab.co.uk (07736 807 604) or Matt@agilelab.co.uk (07713 634 830)

Labels: , ,

Tuesday, 16 December 2008 at

Aspects of Agile - Scarcity and Consistency

We're called Agile Lab - not Agile Museum. And that's because we're always working to develop our understanding of Agile, and especially, to understand how Agile thinking connects to other kinds of understanding. That's why in this lecture, given recently to final year product design students at the Edinburgh College of Art, we talk about some thinking from the field of social psychology which is powerfully relevant to project management and Agile thinking.

No Robot Dogs Allowed

This is a talk which joins up a bunch of things that I read a while ago about social psychology and the "science" of persuasion, especially in a book called Influence: The Psychology of Persuasion
by a Social Psychologist called Robert Cialdini. When I was teaching our Introduction to Agile Course, I found myself very often trying to deal with objections to Agile ideas by explaining the notions of Scarcity and Consistency. And I also began to realise that a lot of the objections that people who attended my course were raising were also motivated by the kinds of psychological influencers that Cialdini talks about. Cialdini actually talks about six different influencers, but today, I'm just going to concentrate on Scarcity and Consistency, maybe some other day, I'll talk about the others.


Can I have a volunteer?

So when I gave this talk at the Edinburgh College of Art - I asked for a volunteer, preferably someone who could drive. I asked my volunteer to sit on a chair, close their eyes and pretend that they were driving. And since I was in Scotland, I asked them to imagine that they were driving up country at the end of the day, perhaps to a little cottage somewhere in the highlands.

Snow

Then I asked them to imagine that, as they were driving, it started to snow. And it snowed and snowed until the snow was so heavy that they couldn't see the road. Then, I asked them to imagine that they suddenly realise that the road veers sharply to the left and doesn't go straight on as they imagined! What should they do?

On this particular occasion, my volunteer wrenched the steering wheel to the left. We then discussed what would have happened if she'd done this in real life. Would she have skidded off the road? What should she have done? Steered into the skid, pumped the brakes? Changed down to a lower gear? The problem is that what you do in these situations is instinctive, unconscious and - as in the case of wrenching the steering wheel to the left, not always, actually, the best thing to do in the circumstances. But of course, with training and practice, you can be taught to do something different in those split seconds. You can be taught to do the right thing, the thing that the experience of others and lots of research has shown to be better than your gut instinct. In many ways, this is what Agile Training is about - giving us better instincts.

Influence by Robert Cialdini

And I think that's why I started to come back to a book I'd read, maybe a couple of years ago, the more that I taught courses in Agile methods, because the psychology of influence is all about playing with your instincts. Most of the people who are trying to persuade you to do something (the ones who are any good at it anyway) aren't trying to make you think, they're trying to stop you thinking. They're trying to use the fact that you will, reliably wrench the steering wheel to the left and stamp both feet to the floor when you realise you've missed a turn in the road.

Fields

A long, long time ago, this was all fields. For England this was about three hundred years ago. And when England was all fields (and still some forests) how rich you were depended entirely on how much land you owned. England in the middle ages was slightly poorer than some other countries - for example Poland - because there were slightly more people per acre of land.


Malthus

And this idea that land, food resources are scarce and that if there are more people, there is bound to be famine, disease and disaster is a very powerful one. In England, as the population grew it was described most famously by Thomas Malthus:

"The power of population is so superior to the power of the earth to produce subsistence for man, that premature death must in some shape or other visit the human race. The vices of mankind are active and able ministers of depopulation. They are the precursors in the great army of destruction, and often finish the dreadful work themselves. But should they fail in this war of extermination, sickly seasons, epidemics, pestilence, and plague advance in terrific array, and sweep off their thousands and tens of thousands. Should success be still incomplete, gigantic inevitable famine stalks in the rear, and with one mighty blow levels the population with the food of the world." Thomas Robert Malthus (1766 – 1834)

Factories

The irony is that at the very time that Malthus was claiming that Britain couldn't support its population, it was suffering a labour shortage because of these things. The invention of manufacturing and mass production in England and the US shifted the balance of who was wealthy from the people who owned the most land to the people who could make the most stuff that people wanted.

Factories

For a couple of hundred years, the richest men in the world were people who figured out how to make things that people want - like cars. They realised that you can get round the Malthusian problems of scarcity by just making stuff up - as long as it's stuff that people want.

Then this guy came along...

Turing

This is Alan Turing. It's arguable whether he actually came up with the design for the first real, working computer, but even if he didn't, he did come up with the idea of a "Turing Machine" which was a theoretical machine that could calculate anything. And so we moved into a new era of non-scarcity. Soon the richest man in the world wouldn't make anything that you could even touch or feel.

Bill Gates

Yes - this guy is arguably the richest man in the world and he didn't make it from farming. Computers took us into a new age of non-scarcity.

And this guy...

First web surfer

Does anybody know who he is? He's arguably the first web surfer. The man who shared an office with Tim Berners-Lee.

So we've come a long way from the times when how much land you had was a direct measure of how wealthy you are. Almost all of our wealth now comes from making stuff up. But even though we live in an internet age, we've stone age brains...

Daily Mail

The idea that some scarce resource is being exhausted - as is implied here, houses, jobs, school places, hospital beds - is a powerful persuader. It's like the feet shooting out and the steering wheel being wrenched to the left. It's instinctive, it's primitive. And the people who are using it, in newspaper headlines like this - or in adverts that say things like "Limited Edition" or "Sale Ends Saturday" are relying on you reacting instinctively.

Wizard of Oz

And the scary truth is - we can never go back to Kansas, not even if we wanted to. We can't go back to everybody having their own bit of land, not without the famine, war and pestilence that Malthus promised. If we want to be richer (actually, if we want to just keep living in the manner to which we've become accustomed) we're going to have to make up new stuff.

I hear objections about scarcity all the time when we're trying to teach people about Agile. In fact, the most frequent objection that I hear is "But this is a fixed price project." In almost all of the cases where people have this objection, I suspect that the scarcity of budget isn't a real scarcity - like a scarcity of wheat or a scarcity of land. Rather it's a fake scarcity - like a scarcity of designer handbags or bargain sofas. Someone is artificially creating scarcity to persuade someone to do something that they don't want to. And when the scarcity isn't real, there are a lot of alternative ways of making progress.

Pie

"Good negotiators make the pie bigger." Good negotiators find a way out of the "scarcity trap" by discovering new things that are of value to the parties in a negotiation. And Agile methods present lots of opportunities for making the pie bigger and exploring what's of value to the client. When you're you're working using Agile you should be suspicious of any claim for scarcity, if there isn't a physical thing like a wheat field or an oil well involved the scarcity probably isn't real. Someone is just trying to use your primitive fear of scarcity to persuade you of something. And that's your cue to do some work to make the pie bigger.

Cialdini

OK, so that's scarcity taken care (for now), so we'll move on to another one of the "six influencers" mentioned in Robert Cialdini's book.

Who wants a sweetie? Ok, this works better in real life that it does on the web.

Cialdini

Imagine the following dialogue:

Me: Would you like a sweet?
You: Well, thank you very much, I'd like one of the purple ones.
Me: Well, I've changed my mind now, you can't have one.

How do you feel? Wronged? Betrayed? And how do you feel about me? After just this tiny bit of unreliability, don't you that I'm either a little bit untrustworthy or a bit mad, maybe a bit of both? Perhaps something a bit like this gentleman.

Lord Archer

This man went to jail for - actually not for telling a lie - but for making preparations for telling a lie if it were necessary. But the way people treated him after he'd been caught, shows why our second influencer - consistency - is so powerful. If you aren't consistent. If you don't always say the same thing, if you aren't a man or woman of your word then people are tempted to draw one of two conclusions, either you're mad, or you're dishonest. Nobody wants to be thought to be either of these, so the pressure to be consistent is very powerful.

Chugger

And the people who want to influence you to do things - like give them money - know that. Consistency can be used in all sorts of ways to make you do things that you otherwise might not want to do. For instance - collect for charity.

A sample of Bloomington, Indiana, residents were asked to predict what they would say if asked to spend three hours collecting money for the American Cancer Society. Of course, not wanting to appear uncharitable to the survey taker or to themselves, many of these people said that they would volunteer. The consequence of this sly commitment procedure was a 700 percent increase in the volunteers when, a few days later a representative of the American Cancer Society did call and ask for neighbourhood canvassers. - Robert Cialdini: "Influence - the psychology of persuasion"

Seven hundred percent! That's the power of consistency.

Korean War

During the Korean war, the Chinese were exceptionally good at getting American prisoners of war to say things that were critical about America, and also getting them to say positive things about the communist regime. The didn't torture their prisoners, but they did use consistency as a powerful weapon.

Prisoners were frequently asked to make statements so mildly anti-American or pro-Communist as to seem inconsequential ("The United States is not perfect." "In a Communist country, unemployment is not a problem."). But once these minor requests were complied with, the men found themselves pushed to submit to more substantive requests.

The majority [of American POWs] collaborated at one time or another by doing things which seemed to them trivial but which the Chinese were able to turn to their own advantage.... This was particularly effective in eliciting confessions, self-criticism and information during interrogation.

So you see, you agree to one small thing, and the next thing you know...

Washing Machine

...you're buying a washing machine. Yes the same principle used by Red Army interrogators is being used by the people who design competitions for washing machines. If you write down in your own handwriting that you really like this washing machine - then guess what? You're working hard for the washing machine company to convince yourself that you really like their washing machine.

Bob Dylan

"A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines." - Ralph Waldo Emerson

Consistency is especially dangerous for innovators and creative thinkers. How can you innovate and be creative if you bow to the pressure to do exactly what you've always done? When Bob Dylan moved away from acoustic folk music and "went electric" in the late sixties, someone famously shouted "Judas" at one of his concerts. Bob's response was to turn to his band and snarl "Play fucking LOUD." But it takes a lot of guts to be inconsistent especially if everybody liked what you used to do (anyone remember when Bob started wearing make-up in the 80's?).

Tony Blair

And maybe for some jobs, being consistent is well, just not consistent with being successful. It's rumoured that before he became Prime Minister Tony Blair was asked whether he was Scottish or English and he replied (jokingly?) that that was something that would be reviewed over the course of the next parliament.

And maybe being a project manager is one of those jobs. One of the most common complaints that I hear from project managers is that they can't negotiate when they're "on the back foot". They promise to deliver something for a certain budget, in a certain time frame and then they can't. They feel terrible. Because they've been inconsistent, their client, they feel, is entitled to think that they are either incompetent or dishonest. Not pleasant at all.

How can Agile help? Well, Agile can't stop, or even really fight the power of consistency, but it can offer some alternative things to be consistent. Firstly, if you're consistent in the way that you apply the agile concept of velocity, you're going to know very early on whether you're going to be able to deliver what you promised when you promise. Secondly, if you follow this blog, you'll know that very often - to quote my friend Tim - "the only projects that we make money on, are the projects where we admit up front that we don't know". Being consistent about admitting when you don't know can save you a lot of trouble - and make you money. Your client is trying to get you to promise the earth for the price of a pizza - does that me you should go for it?

Consistency is a powerful tool (remember the American prisoners of war - remember the seven hundred percent increase in charity volunteers). The only real way to fight it is to use it for your cause and to be consistently honest with your clients about what you can and can't estimate and honest with yourself (in terms of velocity) about what you and your team can and can't do in a specific period of time.

And so now to the star of the show...

Robot Dog

What's all this about robot dogs? Well, the story as Robert Cialdini tells it is that he meets his neighbour in a toy shop on new year's day. And they both think that it's quite a coincidence, since they met each other there exactly a year ago, and, since they're both busy men, even though they're neighbours they hardly ever see each other the rest of the year. What's even more of a coincidence is that they're both buying the same toy - lets say it's a robot dog. The must have toy of the year.

When he gets into work a few days later, Robert Cialdini mentions this to one of his colleagues and his colleague - who used to work in the toy industry laughs a low dark laugh and explains that it's no coincidence. The toy companies spent years trying to figure out how to make sure people carried on buying toys into January, they tried all the usual stuff - sales, special offers, finally they hit on the use of a powerful tool of influence - scarcity! Around Christmas, rather than making sure that there's a plentiful supply of whatever the must-have toy of that season is, the toy companies create an artificial shortage. Then in the New Year, they ramp up their advertising and lo and behold there are plentiful supplies of the must-have toy.

Cialdini is furious when he hears this. He feels so manipulated - and he a social psychologist who should know about these things. He shouldn't be so easily suckered by a straight-forward scarcity ploy . He resolves to take the robot dog back. But BOOM! KABAM! - here's the other half of the double whammy? As his cynical friend in the office points out, he's buying the robot dog because he's promised it to his son. Does he really want to be the kind of dad who goes back on his word? What's he going to say to his son? I would have bought that for you son, but I decided not to be a puppet of the capitalist system - cue wailing cries of betrayal from the apple of his eye. Yes, backing up the scarcity move, is a consistency move.

In the end, he takes the robot dog home to his son. Older, wiser and hopefully not so easily fooled next time.

"You said you could do this for this for this amount of money. Now you tell me you can't. Well, there's no more money. What are you going to do?"

Sound familiar? It's just the old robot dog double whammy in a different time, a different place but with just the same power. Agile methods and Agile training can give you some tools to deal with these situations. Negotiation strategies can help provide "wiggle room" where is supposed to be nothing but scarcity. Tracking velocity and being consistent with the maximum "don't lose money" rather than "stand by what I said when I didn't know what I was talking about" can ease the psychological pain of appearing inconsistent.

Merry Christmas and a happy new year to all our readers!

For further information, contact Mark@agilelab.co.uk (07736 807 604) or Matt@agilelab.co.uk (07713 634 830)

Labels: , , ,

© Agile Lab, 2007-2009. All rights reserved.

sitemap

Powered by Blogger

Subscribe to Posts [Atom]