Interns: New Ideas, New Faces, New Energy

This is a reply to a post on the London Java Community Forum, I thought it was worth posting here, since it is indeed intern season and I have a bit of knowledge (and fond memories) of having interns myself.

Hi Barry,

Re: Interns, this has turned into a long response: I realise that it's something I'm quite passionate about.

I used to run the interns programme at Xerox Research Centre Europe in Cambridge. During the course of 4 years, I had 4 interns and organised maybe half a dozen interns for other members of staff. I found it to be terrifically useful way of investigating new ideas and doing solid pieces of development that you know need doing but can't seem to get around to (e.g. developing tools that will help you do your main job better - trying out new ideas). Put simply, interns don't have to turn up to all the meetings that you have to turn up, they aren't there long enough. They can be left alone to focus on doing just one thing and so can progress much quicker. They also have youthful enthusiasm and energy - they don't know any better, this can be a good way of injecting some life into a jaded team (one intern that someone else took on at Xerox organised the most amazing candlelit punt from Cambridge to Grantchester - it was a great team-building exercise, far better than go-carting or paintballing).

We also used internships at Xerox as an opportunity to give more junior members of the lab some experience of management. They'll be rubbish at it at first, but it's a very good, and revealing "trainer wheels" experience.

I would also say that this is an opportunity to try out hiring someone who doesn't have a cookie cutter CV and just see how it works out. My advice would be to hire the person with the CV that jumps out at you, irregardless of academic institution/qualifications. Hire a Medieval Historian or a Philosophy student (I'm maybe biased because this is my background). I do know other people in the industry who say that Philosophers make the best programmers. The best intern that I had had a degree in fine art and no technological experience whatsoever, the portfolio she sent me literally made me wince when I looked at it (pictures of decaying meat), but she produced three concept video in as many months which ended being shown at "C-Level" meetings and the ideas in them being used as part of merger and acquisition discussions.

Interns are also an excellent opportunity to try out pair programming (http://www.agile-lab.co.uk/2008/09/loneliness-of-self-taught-programmer.html) with someone who's none threatening and ready to learn.

The only BAD THING I can think of in relation to interns is if you are going to treat them as cheap/free labour. They're not trained, they don't know what you do if you think you can bring them in to do the dull bits of your job without you having to put in any effort, you'll be disappointed.

Hire the brightest one you can find and have fun.

If you're looking to apply for an internship - yes, put down your academic qualifications, but understand, especially in the current climate, that isn't going to make you stand out. I looked at a *lot* of CV's from Cambridge University Computer Scientists, I hired a woman from Winchester who sent me pictures of meat. Put down the strangest achievement that you have (that you're proud of) and label it. If you don't have a weird experience like this, go have one right now.

Regards,

Mark Stringer.

P.S. Just remembered that I had another fabulous intern when I was at Sussex. She was much more talented than me and instantly capable of implement things that I was just kind of dreaming about doing - and there's no way I could have ever got her input at any later stage in her career, she was destined for stardom. Handled properly, interns are a terrific way of getting a lot done in a really short time, good for you, good for them.

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

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)

Four great ways to Learn...

(...and one you might not like)

Learn from Somebody Dumber than You

"Every man I meet is in some way my superior." - Ralph Waldo Emerson

We were in Athens (ah the joy of European Union Research Projects) and I was talking to some Polish guys. I was suggesting that before we start writing any software, we should go and do some "low-tech" activities with the school kids who were going to be the final users of our fantastic new technology. I'd say this guy was in his late forties - lets call him Marek. He was director of a medium-sized software company with maybe 50 employees. "What can a 10 year old teach me!" he snorted.

I told you there was going to be one that you didn't like, you can skip down the page if you want, but this is the interesting one. Hear me out. As you get older, you get smarter and smarter, and wiser and wiser. You get more and more skilled in whatever it is that you do. You get fancier and fancier titles - hey aren't you Chief Head General Technical Development Officer of Grand Vizier High Poo Bah right now? You're really important right? So, here's the problem. The higher up this mountain of achievement you get, the harder it is to find anybody "smarter" than you to teach you anything in your own field. All the books are for beginners, and the gurus? You went to college with the gurus, that guy stole your girlfriend, that woman's CTO of your chief competitor, she's not going to teach you anything. Do you see where this is leading? You're climbing a mountain of enlightenment, but you're also digging yourself a hole. The more and more senior you get, the fewer and fewer people can teach you anything in your direct field of expertise. But as if that isn't bad enough, the more and more senior you get the more and more danger there is of what Roger Fisher calls "status spillover" and I call "status creep."

Status creep is the insidious assumption that because you are very important you know everything there is to know about everything. And the more important you get in your organisation, the more the junior people around you will collude with you in this deluded opinion. In my opinion someone like Richard Dawkins is a status creep but that's a rant for another blog. In short it's the "What can a ten year old teach me?" attitude.


Richard Dawkins - stepping outside his area of expertise? (Picture courtesy of Torley)

Status creep is very dangerous because you can very quickly get to a point where you think that what you don't know isn't worth knowing. The question is, ARE YOU SMART ENOUGH TO LEARN FROM SOMEONE DUMBER THAN YOURSELF? The attitude that everyone can teach you something is an amazing one to have. If you can (at least every now and again) approach the world with this attitude, there's the possibility of carrying on learning until your final breath. Well, if you are, then that's where I come in. I'm not as smart as you are. I don't know everything there is to know about your business. I don't know everything there is to know about project management or even about Agile. I do know a bit about communicating Agile concepts. I do know a bit about putting people at their ease in training courses and giving them the opportunity to look at their work from a different point of view and improve their skills and techniques. I know which Agile concepts people have the most difficulty with (stories, velocity) and I know ways of easing them through these difficulties.

So, if you're down and troubled and you need a helping hand. You might sit down and ask yourself some of these questions.

• What can I learn from someone who earns half my salary?


• What can I learn from someone half or a even a third of my age?


• What can I learn from someone I don't like?


• What can I learn from the people who work for me?


• What can I learn from my boss, who's a complete idiot?


• or even... What could I learn from a trainer?

Those other four great methods of learning.

Read a Book

Books, audiobooks, DVDs and other "informational products", you don't have to read. You can listen to it or watch it on your iPod. Books etc. can be very informative. I hope I'm not telling you anything new here. Of course, theory is no substitute for practice, just a practice is no substitute for theory. I start on many new topics this way and sites like Amazon are great for suggested further reading. And - I know I shouldn't say this but it's true - bittorrent sites like Pirate Bay are great for checking out informational stuff, like audiobooks, especially for business and software development, (a representative of the FBI may call) before you actually buy.

Find Yoda

Find someone who knows it all in your field. An expert, a guru. This can be very good, but it can be harder than you think for several reasons. First, you've got to find your guru, of course, gurus are few and far between, so this might take more time and effort than you expected. Second, gurus are in great demand - a lot of people will have had the same idea that you've had - so the guru will probably have put some obstructions in the way to make it hard to get to him. Third, in order to get anything out of a guru, if there is something that he can teach you, YOU have to do lots of work. This guy is the guru. He's not going to go to the effort of spoon-feeding you all the basic concepts you need to get started. He's not going to bother with you at all if you haven't even got the basics. He's not going to go through everything he says and make sure that it's all on the "same page." Tim Ferris has written very convincingly about this in his book "The Four Hour Work Week."

Buddy Up

One of the quickest and most powerful ways to learn anything is to watch and listen somebody who is just slightly more advanced than you. If you know any small children who have a slightly older sister or brother you'll know what I'm talking about. This is one of the main advantages of pair programming.

Disadvantages? Could be that pretty soon, you know what they know and they know what you know. This shared vision and shared approach can be great, but if you don't have anybody in the team who's reading about new stuff, or questing for a guru, there's a risk that things can get stale.

Just Do It

Teach yourself. Don't read the manual. The world is full of self-taught writers, musicians, programmers and mathematicians. There are tremendous advantages to this approach. You don't know any better - so many great advances have been done because the people who were doing them didn't know that they weren't supposed to be able to do that. You can go at your own pace none of that feeling left behind or getting annoyed because you got it and others are still struggling. And you can follow your passion - you can do the things that you want to do. And there's an even more powerful advantage to this method because, when you do decide to use one of the other methods, learn from a guru, find a buddy, read a book, you'll be intimately acquainted with the problems and so really want to know the answers.


Paul McCartney - self-taught. (Photo courtesy of Slagheap)

Of course, there are some problems as well. Following your passion can also mean "avoiding the hard bits" and "avoiding the embarrassment of getting it wrong in public". I've written about this a bit here at "The Loneliness of the Self-Taught Programmer."

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

Timing - Time Lines

I remember walking back to Fife Park (I think now, thankfully demolished) when I was a Philosophy student in St Andrews and looking at people on the street and thinking "I bet those bastards think time's unproblematic." I'd been reading "McTaggart on the unreality of time." And it had seriously disconcerted me.

And I've been reading about time again just recently, with similarly disconcerting effects. I know this would be something that David Allen, a veteran new-ager (if there can be such a thing) would describe as Wah Wah Woo Woo stuff, but I've been reading about Time Lines and I can't but think that it's very relevant to project management, and to the difficult business of persuading people that Agile is a very useful approach to project management.

OK - just as a bit of fun. Sit down. Feet on the floor, arms are your side. Relax. Think of an event that happened in your past. OK, now can you tell me where this event is? Can you point to it? Right, now arms by your side again - think about something that's going to happen in your future? Where is that? Can you point to it. Try this with other people that you work with, try it with your friends, your spouse. Do they all see things the say way as you do? No? Interesting huh?

The basic finding seems to be that some people "see time" when they think of it, in front of them as a series. Very often running from left (the past) to right the (future). The present is just another slot in the series. Some other people experience time as something that they are in, with the past somewhere behind them and the future somewhere in front of them (that's me).


The road ahead - this is something like what I see (actually turning off to the right) the past is behind me, where it's hard to see.


Some kind of timeline - this is what I think many other people see - and many project managers (click for bigger picture).


I suspect the truth of the matter is that both perspectives are required (otherwise, why are they both so prevalent) and that managing projects effectively means knowing how and when to flip between the two (or maintain both views at the same time). I suspect a lot of project management problems come from being stuck in the wrong view, or insisting on only one view.

What do you think? Let me know, either via mail or in the comments.

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

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)

On blogging - a post that never was - and an elephant in the room

I tweeted this:

Ugh!Didn't like http://bit.ly/mIdJU Really? I should write my own blogging software? If I write a novel should I write a word processor?

Which resulted in this response from Dumbledad.

Mark, really I wanted to comment on this tweet of yours(http://twitter.com/Mark_Stringer/status/1762534980 ) but you haven't blogged about it! Anyway, surely if I usurp a post on your seriously undangerous picture you wont mind ;-)
Don't you think that in the early days of the novel writers were developping tools in tandem with the novels themselves. One thinks of Proust's layers and layers of stuck on corrections and rewrites. Even now some writers use old typewriters, some a mass of post-its in a shed.
So, we're close (ish) to the start of blogging wouldn't you expect bloggers to tinker with blogging tools. Some wont have the skills to build tools, but some will. Some wont have the skills to customise tools, but many will. And they'll all have the skill to customise their blogging process.

I understand Dumbledad's point - and I agree with it to some degree, of course people with all manner of abilities should carry on innovating, improving an customising tools - as if anybody could stop them. But that still doesn't stop me disliking that post. I think it tries to create the impression that you have to able to do this kind of tinkering to even start SEO'ing your blog. And this just isn't true. Surely, making this the first point in your list would tend to put of the 99% of people (maybe more) who can't write software.

I don't want to create this impression. I would like as many people as possible to know just how much they can do - how easy it is to say what the hell they like - and get people to read it via search engines, without knowing a single thing about the technology (this is why I think Darren Rowse's #31DBBB is a very noble pursuit). There's nothing wrong with people learning everything about the technical stuff later, but putting it right at the front feels a bit like a smoke screen.

Perhaps hidden behind this - let's not call it dishonesty, let's call it - "strange emphasis", might be a discomfort with the way the world of the web and blogs and SEO is changing. Certain aspects of the business of setting up and promoting a website and a blog - and some much more complicated sites - are becoming very cheap and easy to do for people who have a minimum level of technical skills. The person I know who knows most about SEO is a photographer. At the same time, the technical knowledge of the "not technical" people is increasing in areas that are directly useful to them. A friend of mine was just telling me yesterday that he tried to tell a film director that he couldn't have something that he wanted on a blog - the film director's response was "Why not? I can get that in moveable type - look just give me access to the CSS and I'll do it."

OK - this is how I manage to shoe-horn this post into a blog about Agile software development methods. The cost in time and money and skills requirements of knocking up a pretty darn good state-of-the-art website is falling catastrophically. The way things are changing is going to play havoc with "established" models of software development - even Agile ones. Talk to a lot of companies that try to make money from web development and they'll tell you that they only really make money on the "easy" bits - setting up, hosting, CMS. It's devlish hard to make money out of actually writing new software. What's going to happen when the punters can easily do all those bits themselves and only ask the technical people in to do the difficult bits? This is something that occurred to me when I listened to a 10-year retrospective talk "Agility in the UK" at SPA2009. Some of the speakers seemed to think that we were still in a world of "soviet style" 1-2 year development projects.

Web developers: are they?

(photo courtesy of Phil Guest)

or are they heading for?



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

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. (Picture courtesy of . SantiMB .)

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

What's Right with this Picture?

I've just been reading this post and it made me think of something funny that happened just after we'd started up in business. We'd been asked to do some consultancy that involved interviewing people who ran "small creative businesses". I arranged to meet one woman, who ran her business from the garage in her back garden. When I talked to her on the phone, she was a bit worried about the idea of me coming to her house and suggested that we meet in the local pub. I understood totally, and agreed to meet her at the pub. In the meantime, I mailed her to confirm the meeting.

The day before the interview I just rang her again to confirm.
She said "Is that you in the picture on the website?"
"Yes" I said.
"Oh, that's all right, then, there's no problem, you can come to the house."
"Er, OK, I'll be bringing my partner with me."
"That's no problem."

So, clearly something about that picture is working, although I'm not quite sure what. It's taken a few days before I got married in Greece and when I'm surrounded by friends, so maybe I'm relaxed, and that comes across. It's actually cropped from a bigger picture showing me with my baby nephew on my knee and he always makes me feel good natured, maybe that's it.

I dunno? Maybe it's not the right picture for business, maybe it says relaxed and friendly, but it also says "utterly harmless". What do you think?

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

A Big Hello to all our Regular Readers - and the Irregular Ones

I've been belatedly following the #31DBBB programme of Darren Rowse - 31 Days to a better blog. And day 5 suggests that I engage with my regular readers - those who comment regularly on my blog, by sending them an email. Well, I don't have that many readers (yet, positive, think positive). So I thought I'd thank three people who've commented on my blog.

Dave Dawes (http://www.entreprenurses.com/)

I met Dave at a Nesta unconference on the state of the Health Service - I'm not sure why I was there (I don't think it was my name on the badge I was wearing) and we stayed in touch. I like talking to Dave because he's a huge source of experience, enthusiasm and encouragement on the subject of trying to make it on your own as speaker/trainer/consultant and entrepreneur. When you try to make it on your own, what you definitely need is comfort and cheer from other people who've actually experienced it rather than homespun advice from people with safe jobs and pensions - "Sex advice from virgins" as Dave put it.

I don't like talking to Dave because whenever I do, I then hit Amazon hard and buy a ton of books.

Alex Kohlhofer (http://plasticshore.com/)

I used to work with Alex at Soda. He was great to work with, even when things got very, very tricky. I don't see much of him any more because he insists on living in Austria! Still, if I wanted someone to design a website for me, and I had any money, he would be my go-to guy.

Tim Diggins (http://www.red56.co.uk/)

Tim is the cause of all the "Fry up lunch" posts on this blog. He makes me think. He is a cultured and intelligent gentleman who is very interested in all matters Agile and works harder than anybody else I know to actually put these things into practice in his coding. He's who I'd go to if I wanted some really complicated software writing (sigh, if I had the money).

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

This is just a list - but a very good one

Just sent this list of references out in an email to my students on the Managing Digital Projects course. I think it's a good list, so I'll share it here as well.

Difficult Conversations - http://bit.ly/17jqqB
Getting to Yes - http://bit.ly/8DBgb
Sources of Power - http://bit.ly/LcK9H
The Web 2.0 Paper by Tim O’Reilly - http://bit.ly/ICDiz
The sceptical Facebook article - http://bit.ly/2088J
Extreme Programming - http://bit.ly/H0JV1
Scrum and XP from the Trenches - http://bit.ly/20k7hl
The Strength of Weak Ties by Mark Granovetter - http://bit.ly/wGxX

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

3 Ways to Loosen Up your Thinking

"Yeah, my thinking about the case, man, it had become uptight." - The Dude, Big Lebowski.

Here are three things that you can do to loosen up your thinking. Don't think about it - just do it. Go.

1. Take a plain piece of paper

OK, look at that blank piece of paper and feel the pain of writers the whole world over who have to stare at a blank and then somehow try to make a living by making marks on it. Then forget about that and scrunch that piece of paper as tightly as you can into a ball. That's it, really tight. Now. Place that balled up piece of paper on your desk, or somewhere down in front of you and get another piece of blank paper and a pencil or a biro. You've got 5 minutes, as accurately as you can draw every angle and every crease of the balled up piece of paper. Every detail, every wrinkle, every variation of shading.

Begin.

This is an idea taken from "Drawing on the Right Side of the Brain" by Betty Edwards. The idea is that by giving the "logical" part of your brain something really, really, tedious to do, you make it give up and go away and give the other part of your brain that sees the big picture and makes "illogical" connections a chance.

2. Go somewhere where you can be on your own.

Look around and start pointing to things and naming them out loud. Mug. Computer. Book. Desk. Speakers. Chair.

OK.

Now do the same thing again, but this time give things the wrong name. Point to a mug and call it a "turnip". Point to a chair and call it an "interim report". Try pointing to things and calling them by very concrete names - point to a wall and call it a "haddock" try point to things and giving them very abstract names - point to a biro and call it a "lifetime retrospective". Keep doing this for about 2 minutes.

This idea is taken from Keith Johnstone's book "Impro" - it's a marvellous book. I've no idea what the theory behind it is - I don't think Keith does theory. He says that after you've done this exercise, the world seems to be sharper and more vivid place - it works for me.

3. Read this

In Broken Images

He is quick, thinking in clear images;
I am slow, thinking in broken images.

He becomes dull, trusting to his clear images;
I become sharp, mistrusting my broken images.

Trusting his images, he assumes their relevance;
Mistrusting my images, I question their relevance.

Assuming their relevance, he assumes the fact;
Questioning their relevance, I question their fact.

When the fact fails him, he questions his senses;
when the fact fails me, I approve my senses.

He continues quick and dull in his clear images;
I continue slow and sharp in my broken images.

He in a new confusion of his understanding;
I in a new understanding of my confusion.

I'm a sucker for poetry. One of the things it does is use words in new ways to see the world differently. Just about everything Robert Graves wrote, poetry and prose is worth reading.

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

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)