Agile Lab - Training, Coaching and Consultancy Blog

Thursday, 8 October 2009 at

Do you speak organisation?

Having gone to Andy Murray's Prince2 refresh talk at the BCS, I'm starting to think that the issue between Prince2 and Agile might be slightly more subtle than I thought. Prince2 is a method of talking to organisations.  Agile is a set of methods for delivery, especially for software.  Both methods claim to be able to do the job of the other.  Both are bluffing.

Yeah right, I know, Scrum of Scrums.

Also, as far as I can see (my knowledge of Prince2 is very sketchy) there's nothing in the method to say how you actually get the work done, so what's to stop prioritised lists, Kanban-style displays of work in progress and strict limits to how much of that work is in progress?  I think this is what the guys at e2x were trying to tell me last time I talked to them, but I wasn't ready to get it.

Maybe Prince2 is a bit like Old Entish. Maybe arguments between Agilistas and the gentlemen of Prince2 is a bit like the battle between materialists and idealists in philosophy of mind.


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: , , , ,

Tuesday, 2 June 2009 at

Everything you wanted to know about computers and the web...

Just finished putting together the finishing touches for my course slides (warning, this is huge file) tomorrow for "Managing Digital Projects" this is a course that I give to people in the publishing industry and this third day is an opportunity to cover issues that came up out of the first two days.


My Cheat Sheet for the course tomorrow (Click for full size)


I think this day is going to deal with some questions that a lot of people just feel would be too stupid to ask, but actually don't have very good answers to:

What's a computer?
What's a program?
What is software?
How does the web work?

Having laid all that down, we then go on to SEO and Analytics.

Finally (after taking the necessary 30 seconds to remind them that this applies to publishing) we look at how we can deal with a world that seems to be in permanent seemingly crazy and destabilizing change.


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

Labels: ,

Monday, 18 May 2009 at

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)

Labels: , , ,

Tuesday, 24 February 2009 at

The Trouble with Waterfall

Matt talks about his early experiences of waterfall project management methods - this is the first of a series of clips from a training course 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: , , ,

White Paper on Agile vs Waterfall, uncertainty and open loops

I've just finished a white paper that I've been wanting to write for a while on the differences between Agile and waterfall project management methods. The perception of many people who are new to Agile is that it actually makes the outcome of projects more uncertain, rather than less.

This is absolutely not true, but I think that sometimes, we don't do a good enough job of convincing people.

Lets Not Start at the Very Beginning (pdf, html)

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

Labels: , , , ,

Tuesday, 17 February 2009 at

Two-day Digital Project Management Course in Central London

We're running a course on Digital Project Management at the Publishing Training Centre on the 23rd and 24th April 2009, the cost of the course is £880 + VAT.

The course takes in Agile Methods, but also covers conventional project management methods, as well as risk management, estimation, negotiation and other practical matters involved in managing a digital project. The course is aimed particularly at the publishing industry and at those people who are moving from managing conventional publishing projects to on-line and digital projects.

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

Labels: , ,

Friday, 5 December 2008 at

Marmite and Toast: an introduction to project management


Marmite and Toast gives people a chance to learn the basics of project management and to compare waterfall or industrial approaches to project management with Agile or iterative approaches.

This training was adapted from previous sessions run by Mark Stringer and Matt Gould for a half day for Wired Sussex's Brighton Internship Programme.

Feel free to check out the presentation.

Marmite%20and%20Toast.pdf

Labels: , , ,

Sunday, 12 October 2008 at

Nothing is Digital

Proposition 1: The map is not the territory. What I mean is that nothing that is human is ever really truly on or off or in any other discrete state. This is in the sense that nothing is certain. The world is analogue, regardless of what “digital” structures that we try to put on it and a lot grief comes from that gaps between the digital structures and the places where the analogue world rubs up against them.

Proposition 2: The meaning of a communication is its effect. I think I mean something else as well though. I mean that anything you communicate has more meaning than you think it does. And its meanings spin off in all sorts of ways that you might not expect. We are capable of reacting emotionally to almost anything. Just think of sitting at a red light, waiting a few seconds, you’re starting to get irritated, a few seconds more, you’re starting to wonder why me? A few seconds more and you’re wondering if you could hunt down the people who are responsible for setting these lights and kill them and their families and burn down their houses. What about if the opposite happens? You drive through a busy city on a “green wave”. Every traffic light that you come to turns green. Suddenly, you’re feeling light and relaxed and as if you can do anything. A traffic light isn’t quite a binary signal, you need two digits to deal with its four states (Red, Red and Amber, Green, Amber) but just look at how much emotion it generates. So, even though the traffic light is binary, the reaction to it sure as hell isn’t. People don’t just stop and go at traffic lights, they get emotionally involved. Emotionally involved at just that tiny piece of traffic flow management. Think what might go wrong if you ask one of your employees to do something for you!

Proposition 3: Nothing anyone does is digital, their motives are always complex.

There are all sorts of ways in which understanding this, and continuing to keep it at the forefront of you mind can really help.

1) This means that nothing is ever finished, and nothing is ever perfect

This means that you need strategies in place for deciding when something is “good enough” that you can go with it, and getting it past that point, otherwise you could be stuck, literally forever.

This also means that whatever situation you’re in, no matter how good it is, you can make it better. This is how the Japanese can work apparent miracles, not with radical changes to their processes, but with incremental changes.

2) This also means that project management methods that try to talk about work as if it’s a digital system (one where everything is definitely specified) and then try to supply methods that can manipulate a digital system are doomed to failure. From proposition 1: the map is not the territory comes the understand that no-one can say precisely what they want, from proposition 2: The meaning of a communication is its effect comes the understanding that even if someone could perfectly say what they want, there is no guarantee that when they asked someone else to get it for them and they would get what they want. This is why one of the most important aspects of Agile is, not the short iterations, but the information that comes as feedback. Feedback gives you a mechanism for getting nearer perfection. But it doesn’t guarantee it.

This is also why trying to drive project management digitally - as if a project were some kind of adding machine and all you need to do is to be told how to turn the handle - is doomed to failure. This is why stand-up meetings are a good idea and why, if you’re working with people long-distance or distributed you are instantly at a disadvantage and need to use all the equipment you can, conference calling, video conferencing, on-line chat to do the best you can to make up for the shortfall in “analogue feedback”. This is why you need to demo what you’re doing to the client regularly and often. Analogue feedback stops expensive fights. It’s why there’s more road rage than pavement rage. It’s why people say things in emails that they’d never say in real life.

Whenever you’re thinking of project management in mechanistic terms, don’t. Maybe think of your project instead like there’s been an earthquake at the zoo and all the animals have escaped. You need to capture the animals? Are all the animals equally easy to catch? Are they going to use the same methods? Is maybe more important that you catch the lion or the mountain goats? Once you’ve got the hang of netting all kinds of beasts as a team, would it be OK to have one of the team drop out and be replaced by “another equally able animal catcher” who you’d never worked with? Would this have any effect on the team?

3) Sometime what people do is digital, they just say the things that they need to say, do the things that they need to do, but their heart isn’t in it. The American’s have an expression for this - “phoning it in” and generally, behind this kind of “just doing my job, just doing what I was told to do” behaviour, there are other, more complex motives. What this means is that you can’t get people to act well, digitally unless you get them to act analogically. You don’t want anybody who does as they are told working for you. No matter what you’re paying them, no matter how supposedly senior to them you are, you still have to persuade them to do what you want in such a way that they put their “Heart and Soul” into it.

This means that multi-tasking is very bad. Again, get away from the idea of your brain as a machine. No switches. Imagine instead that it’s a troop of monkeys feeding on the fruit of two trees? How long does it take to transfer a troop of monkeys from one tree to another? What if you kept switching trees 10-20 times a day? Would you have some tired hungry monkeys? Research shows that it can take a programmer as much as 40 minutes to get all his monkeys back in his programming tree after an interruption like the phone ringing.

Labels: , , , ,

Friday, 15 August 2008 at

What's in a name?

[Sitting is Starbucks in Leeds - up here to run an Introduction to Agile Course]

Is your company Agile? Yes, I thought it would be. I don't think I've talked to anyone who didn't claim that their company was. Of course, further questioning would often reveal that they weren't actually doing fixed-length iterative development, weren't actually planning in terms of stories or any of the other things in the Nokia test. It took me a long time to realise why I wasn't getting an honest answer: no one is ever going to say that they're not agile. How likely is this?

Q: Is your company Agile?
A: No, not us, we're lethargic and arthritic.


The word "agile" perhaps betrays the movements American roots. It has lots of positive connotations: energy, intelligence, responsiveness. But (perhaps this betrays my British roots) this means that admitting you're not agile has all the opposite connotations: lethargy, stupidity, unresponsiveness. Nobody's going to admit to that - even if it's actually how they feel. And lets be honest, we all feel like that some of the time.

Trying to make people feel bad about themselves before you try to sell them something guaranteed to make them feel good is a standard sales technique. Whether you're selling soap powder of salvation it can be very effective.

We believe that (almost) all our potential customers are very clever people. They are doing a pretty good job with the tools that they have at their disposal. They don't need salvation - they need some new techniques. What we try to do is give them better tools, not software tools, not technological tools, but conceptual tools that allow them to do a better job.

Labels: , ,

Thursday, 14 August 2008 at

Best feet forward?

Please don't anyone take this as advice of road safety. It's just an exercise.

Push your chair back from the computer. Just relax. Imagine that you're driving along in your car down a very familiar stretch of road. A journey that you've done lots and lots of times. Yes, that's it, mime holding the steering wheel. You can't close your eyes, because then you won't be able to read this, but in your mind's eye, imagine what you can see. Familiar roads, familiar corners, and junctions. Then suddenly, something jumps out in front of you. It's a toddler, chasing a ball. Stop! Stop! You have to STOP!

If you're used to driving a manual transmission car you probably wanted to stamp both feet straight out in front of you. One on the brake. One on the clutch. When we want to stop a car in a hurry that's our instinctive reaction. We tend not to think about it, there isn't time. But is it the best?

If the road conditions are good, it's probably the best, most effective strategy, but what if the road conditions aren't good? What if it's raining? What if it's snowing what if there's an inch of ice on the road? If the road's slippery, it's best to pump the brakes. But what do you do if you thump both feet to the floor and you start to skid? Apparently, you're supposed to turn into the skid to regain control even though this feels like exactly the wrong thing to do. People can learn to drive in wet and icy conditions, they can learn to resist their first instincts, pump the brakes and turn into the skids but it takes time and practice, rarely do people spontaneously do the right thing.

Someone was asking me yesterday why so many projects use a waterfall approach rather than an agile one. I think it's for similar reasons. In industrial societies waterfall methods are deep down in our brains. We just assume that the way that anything complicated gets done is by putting together a long, complicate plan and then trying to deliver on it. No matter how many times the result of this is the project management equivalent of skidding into a ditch, because this is our hard-wired, instinctive approach, we carry on doing it.

Agile is the project management equivalent of pumping the brakes and steering into the skids.

Labels: , ,

Wednesday, 28 May 2008 at

Change glorious change - why Agile is right for schools

A deputy head of a large rural primary school coming out of special measures recently described her working environment as one of continual crisis management. She talked about the way that they have to run the school pretty much on a week by week basis with continually changing priorities, an unstable staff base with a lot of absence and transience and with continual external interference.

A now ex-principle of a large academy school in London described the changing curriculum and increasing focus on creative, enterprise, innovative and project based learning as one in which teachers are now project managers as well as educators. He went on to describe the fact that projects have to cope effectively with continual flux in resources and with the time constraints of the timetable and therefore the notion that careful planning will somehow ensure success is a misnomer - it is the ability to deliver projects by coping effectively with continual change, reshaping and re-prioritising as you go that will ensure successful outcomes.

These two examples represent opposite ends of the spectrum in terms of school 'type' and current 'success status'. Yet despite this they both require internal process for leadership and management that can cope successfully with constant re-prioritisation, constant resource flux, limited time. They also need process that is light weight (teachers are time poor), easy to learn, flexible, works for external collaboration, is formalised enough that it can be reported upon and have success criteria built in, all of which is offered by Agile.

The following elements of Agile all map effectively onto the needs of schools:

  1. Iterative working - by planning in terms of what can be achieved over a period of one month/half a semester/a term or whatever time segment works in terms of an individual school, Agile fits naturally with a school's 'heart beat'
  2. Constant prioritisation - by recognising that demands on staff time and school priorities change on a term by term basis (or week by week in the case of a school on special measures), an approach that deals effectively with this is essential
  3. Velocity - having a system built in that allows planning to respond effectively to constant change in time available to those delivering projects allows the project to fit the available time of those involved rather than the people having to fit the project and therefore massively reduces the risk of failure
  4. Stories - the use of a narrative based needs and outcome communication approach allows Agile to work effectively as a planning and negotiation tool (particularly when used with inter-iteration re-prioritisation) with all stakeholders within a school community including governors, teachers, support staff, local authorities, partner schools and organisations, parents and pupils
  5. Test-first - by determining how successful completion of tasks is to be recognised and negotiated before work begins, it becomes clear to understand what has been done and what hasn't and provide a clear progress reporting mechanism
  6. Stand-up meetings - Agile works best with regular short meetings where people look at the stories they are working on, report on progress made and barriers encountered. These meetings can happen effectively in the coffee-length restrictions of break time, the 10 minutes available at lunch or before registration or before going home
This is just a sketch exploring how Agile would work in schools, but Agile grew out of the need for an approach that could deal effectively with constant change in needs and resource flux and does not allow these inevitable challenges to lead to failure. Therefore it would appear that Agile may well have a lot to offer school leadership and management.

Labels: , , , ,

Wednesday, 21 May 2008 at

What can Agile process provide to investors in innovation?

The idea of using an Agile approach to investing in innovation is nothing new. The BBC Innovation Labs have been doing this for many years through providing single iteration support to those with an interesting idea. The BBC invest in many companies producing a demonstrable first version of their idea before deciding to invest further. This approach massively reduces the BBC's risk as they are able to see both whether the idea has legs once it becomes demonstrable and if the development team are up to the job.

This use of single iteration development terms is used as a way of selling Agile development by providing massively reduced investment risk through only committing to a single iteration while delivering working code. This means that at the end of the iteration the buyer can take the code to another development team if they so wish. In the case of the Innovation Labs it is likely that the BBC would retain some degree of exploitation rights to the IP should they wish to take a good idea that was badly realised to another team.

The fact that Agile is so effective at marrying formalised project and product development management with creative and innovative process means that this is a no brainer for those that have worked in this way. Having talked to a number of investment organisations recently, it appears that Agile offers another potentially useful tool in addition to monitoring progress that can be tied to investment rounds as used by the BBC. This is effective communication.

The process of using stories and prioritisation enables the investor to see exactly what decisions are being made and to interrogate the rational behind prioritisation. If an investor takes part in the transition from iteration to iteration they have a clear picture of what is going on and are able to feel sure that their money is being spent realistically. The investor will also able to see the progress being made through the presentation of demonstrable tested development. This provides clear windows for investor communication while leaving the innovator free to get on with their work during actual iterations.

Therefore Agile's embracing and normalisation of constant change and risk (essential ingredients of innovation) combined with a process that effectively exposes this makes it a perfect process for allowing a better relationship between investors and innovators.

Labels: , , , , , ,

Monday, 21 January 2008 at

What is Agile? Stories, Iterations and Dealing with Constant Change

1 Agile refers to a bunch of project management methods that are well suited to managing projects in an environment where everything is changing. Agile methods came from software development but can be used for managing all sorts of projects.

2 Using an Agile method, a project team organizes all its work into "stories". A "story" is a short description of one thing that needs to be done on the project.

3 The list of stories are prioritized in discussion between the project team and the client.

4 The team, in discussion with the client select a number of the stories to work on over a short period of time (from about a week, to about a month). This is called an iteration. Each story in an iteration is assigned to a team member. This team member estimates how long the story will take.

5 The aim at the end of each iteration is to have something working to show the client. The client then has a chance to give feedback, to add new stories to the list of stories still to do, or re-prioritize the stories that are already there.

6 The team go through the stories that they've finished and compare how long they estimated they would take with how long they actually took. They use this as guide to future estimation.

7 The client and the project team go through the newly-prioritize list of stories and decide on the next iteration.

Read More:

Agile on Wikipedia: http://en.wikipedia.org/wiki/Agile_software_development

"Extreme Programming" by Kent Beck

"Agile Software Development with SCRUM" by Ken Schwaber and Mike Beedle

"Scrum and XP from the Trenches" by Henrik Kniberg

Labels: , , ,

Friday, 21 September 2007 at

What can Agile do for school management?

Having spent many years working on co-design and partnership projects with schools, I have become aware of the fact that schools in the UK, and particularly secondary schools, are in a constant state of flux. Even the best performing schools are continually managing change as handed down to them by government or because they get specialist status, being rebuilt or trying to become more outward facing through working in partnership with industry, cultural organisations, HE and FE. Then there are those schools that get entirely new management teams as they become academies or are working to get themselves out of special measures. These schools have to deal with change upon change and at times will feel like they are in constant crisis mode.

As Agile methodologies begin to be applied in new environments, it seems that schools are an obvious candidate as organisations that could really benefit from Agile. Some of the reasons for this are as follows:
  • Constant change - as mentioned above, schools are continually working in an environment of constant flux and Agile is all about constant change.
  • Lightweight processes - teachers are overworked and are resistant to anything that feels like additional management, administration or responsibility - Agile is simple and does not require reams of additional paperwork.
  • Minimum iteration - in schools resources, particularly time, are scarce. Teachers will buy into a process and a project if they can see that it is delivering for them. Agile delivers results quickly and requires visible success criteria.
  • Needs orientated process - the Agile use of 'stories' as a key concept used for defining goals and considering prioritisation is very useful for schools. Teachers often think in terms of 'need' and 'limitation' and both these are core elements of 'stories'.
Schools are expected to work in terms of projects more and more. Teachers need to be able to work together and with external organisations on project development and delivery in order to respond to the constant change that they are faced with. Agile is much more suited to the school environment than traditional project management approaches. It is flexible, easy to understand, lightweight and quick to implement, delivers visible outcomes quickly and responds effectively to constant change.

Labels: , , ,

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

sitemap

Powered by Blogger

Subscribe to Posts [Atom]