You are here...

Sent from my BlackBerry® wireless device

Posted via email from The Ginger Mumbly

Gig #27 At the Cavendish Arms

Posted via email from The Ginger Mumbly

Late and Over Budget Version 0.2

LateAndOverBudgetV0.2.pdf Download this file

Posted via email from Agile Lab Blog

Late and Over-Budget: If we can’t do it with the lights out, we’d better not do it all

Last week I wrote about the bad news bump, which I think is one of the most powerful tools in the management of an Agile project.  The purpose of the bad news bump is to force a project to a crisis much earlier than is normal in a conventional project.  The purpose of the bad news bump is also to get the bosses to act strategically.  The danger of this approach is that the bosses will act succeed in acting tactically (they will always try to act tactically before they act strategically).  As we discussed in the bad news bump article last week.  One tactic is to simply deny or ignore what they’re telling you. Another is to call you names until you shut up, or get so incandescent with rage that you make sure that you never tell them bad news again.

 

We talked through all of this last week.  This week I want to concentrate on another particularly egregious tactic that is really, really common and intuitive.  Even though it really, really doesn’t work.  It’s got a lot of names, but they all boil down to the same dumb idea.  Trying harder, breaking a sweat, working late, crunch, 19x7.  The basic idea to these is all the same.  An Agile project manager does the maths and finds out that given the size of the backlog and given the velocity of the team a project is going to take longer than it is supposed to do.  When confronted with this the boss says “can’t they work weekends/sleep under their desks/stop sleep altogether etc. etc.?”

 

And of course, they can.  But really, really, this is the last thing that the boss wants. Even though you’re probably never going to persuade him of that – even as he’s being fired, or as he’s appearing at the industrial tribunal. There are two really powerful reasons for this:

 

1) The team trying harder and working late/weekends requires no effort and no change from the boss and hardly anybody likes to work and nobody likes to change. Getting the team to work harder avoids the awkward strategic decision that actually does need to be made.  It stop the boss having to have a difficult conversation with her boss.  And who’s to blame her wanting to avoid that?

 

2) The model of software as cake, that we talked about a couple of weeks ago is all-powerful and pervasive.  In the software as cake model, you want more cake, you get your team to work longer hours and they produce more cake, so what if the odd sleep baker falls in the mixer. Naturally, if it’s too tainted, you’ll throw that batch away.  And just get another baker.

 

Unfortunately, software isn’t cake.  Software development consists mostly of the three T’s – Talking, Thinking and Typing.  None of these can really be done very proficiently with “QWERTY” mirrored on the forehead as a result of a sneaky catnap.  In order to get good software, you need to let your team work at a sustainable pace.

 

When I hear the bosses advocating working “19x7” or working weekends as a solution to the bad news bump.  I must admit, my first reaction is still rage.  My second reaction is to wonder whether the bosses are certain that these people that they’re pushing so hard really don’t work for them.  What if one of them walked under bus whilst on the way home to enjoy his whole five hours of time off?  Are you certain that you wouldn’t be liable?  OK, they’re independent contracts, or they technically work for a supplier.  That’s what EA Games claimed in the law suit that resulted from the famouse “EA Spouse” blog post - http://ea-spouse.livejournal.com/274.html.  But they still ended up paying $100M dollars.

 

The third thing I think (and the first thing that I’m probably going to say) is that it really isn’t a good idea to be trying to explain complex business concepts to someone who hasn’t had a full day away from his desk in weeks.

 

If you can’t persuade the bosses that making highly-educated, technology professionals work until they drop dead isn’t a good idea, I suggest you just ignore them.  Go home at a reasonable time yourself.  Encourage your team to go home at a reasonable time. 

 

And make absolutely sure that all the important work happens during the working week in daylight hours i.e. when you can have the lights off. Even more forcefully than working late and working at weekends, what you should absolutely resist is any attempt to carry out important steps in the software development process over the weekend.  This is what the (rather smutty) title refers to.  You should especially avoid doing things like build and release at the weekend or late at night.  Why?  Because when things go wrong, when the lights are on, there won’t be the staff there to help you.  And when things go wrong late at night when the lights are on and the staff aren’t there to help you and your skeleton team, that’s when you’ll be tempted to cut through all the processes that you normally observe and do things like hack scripts in the live environment, and drop non-source-controlled binaries into the live environment.

 

When I think of this kind of scenario, I vividly remember a former boss of mine considering dropping non-source-code-controlled binaries into a live environment.  If we’d let him there was more than a slight chance that he could have left $30M dollars’ worth of software in an impossible to roll-back, un-repairable state on a live site. What is particularly dangerous about these kind of “lights-on” late-night antics is that developers, even very senior developers who should know better, will cooperate with these kind of late night antics.  The reason I think, comes back to the three T’s – good software development should always consist of talking, thinking and typing. It’s a bit dull.  Every now and again, a bunch of mostly blokes are going to want to stay up late, get drunk and set fire to something so they can feel their life has meaning.  If you’ve ever read “The Secret Life of Walter Mitty” (and if you haven’t, then you should – here http://www.all-story.com/issues.cgi?action=show_story&story_id=100), there’ a distinct air of  “Pocketa, Pocketa” about this need for drama.  The trick is, as a manager to make sure this happens well away from access to the live server.

 

This is software development.  Not field surgery, not guerilla warfare. There should very rarely be any requirements for drama and heroics.  Those who want this kind of drama should perhaps take up paragliding, or talking loudly in a received pronunciation acccent in certain West Yorkshire pubs (I can give you a list).

 

This is also why I despise military analogies for software development.  In any software project that’s delivering anything valuable, nobody should be going over the top of anything and nobody should be throwing more bodies at the problem.

Posted via email from Agile Lab Blog

IMG00355-20120916-1341.jpg

I ordered pancakes and this is what they bought me.

It has candied peel in it. Now feeling naked without a Cath Kidstone handbag. Sent from my BlackBerry® wireless device

Posted via email from The Ginger Mumbly

The Agile Bad News Bump Graph

Posted via email from Agile Lab Blog

Late and Over-Budget: The Bad News Bump and the Five Stages of Grief

I wanted to write today about the power of the Agile bad news bump.  I got this idea from an Agile Coach that I worked with at JP Morgan – Scott Bird.  Being an American and more comfortable with sports metaphors, he called this “The Agile Hockey Stick.”  The basic idea is that in an Agile Project, bad news shows up earlier than in a conventional project.  The more sophisticated idea is that the shape of bad news is different in an Agile project than it is in a conventional project.  But people who are unused to Agile projects assume that the shape of the bad news is the same.  And this is the main reason that they go crazy when they find out right at the beginning of the project that there is already trouble.

What causes the bad news bump in Agile projects?  Well, the bad news in an Agile project really happens when two important agile artefacts collide – the prioritised, effort-estimated backlog and velocity.  The effort estimated (preferably in terms of complexity points rather than the nightmare of ideal days)backlog is a catalogue of everything that needs to be done on the project.  But we don’t really get an idea of how long the project is going to take until we actually start to work on the backlog.  Once we do start to work on the backlog, what tends to happen is there is a very quick realisation that the project will take much longer than was initially estimated.  This alarms a lot of senior management.  They can’t believe that development has only been going for a few weeks and it is already in crisis. They are used to reporting from conventional projects, that is they are used to being lied to for almost the entire duration of a project, until the lie becomes untenable and the bad news finally leaks out.  Also, unconsciously, the think that this is still going to happen, that they are going to get bad news and then yet more bad news later. They tend not to understand that discussion about how long the project actually might take, based on data mean that the risks associated with the project are being addressed at a point where there is still time and resources to do something to correct them.

What should management and senior stakeholders do when they get this bad news  - that the project is about three times the size, or is going to take about three times as long as they thought it would? Well, before I get on to what they should do, let me just run through what they will do.

1) Deny it

As anyone who’s read their Elisabeth Kubler Ross will know – denial is the first stage of grief.  The first reaction of the bosses to early bad news about a project will almost inevitably be denial.  Yes, that’s right.  Given actual data to set against their pristine plan, they will believe the plan rather than the actual data.  Very often this will be coupled with requests for ridiculously detailed estimates of how long remaining work is going to take (in one extreme case, I had requests for estimates down to the minute).  This is a real danger point.

2) Get annoyed/accusatory (anger)

“I thought I hired professionals who knew what they were doing.”  Well, if you understand the nature of the Cynefin framework, and which quadrant software development sits, you’ll understand that the people who do software development aren’t professionals. But this attack has power.  Again this is a real danger point.  Especially if it’s framed as “Well, if you can’t do it, maybe I’ll have to find someone who can.”

3) Bargaining

Bargaining can be a good stage.  It can be a disaster.  What you want to be bargaining about is scope.  You want to get an agreement from the bosses that it’s OK to deliver a reduced amount of high-value, high-priority scope in a reasonable amount of time.  What you absolutely don’t want to agree to is any “solution” which involves your teams working late, or working weekends, or in any other way “trying harder.” Trying harder simply isn’t a strategy, it isn’t even a tactic.

You also want to avoid any kind of double-counting or arithmetical tricks.  This is amazingly common. A popular tactic at this point is to split the development team in two – and then “plan” to give each team the same amount of work as the original team.  Another, more subtle, but equally useless tactic, is to “share” key team resources across several projects.  This is an area where spread sheets are a menace.  It’s just too easy for someone more in love with plans than real data about actual progress, to shave, round, leave out and double-count until the “numbers look right.”

4) Depression

“This is going to upset a lot of people. We’re going to look bad.  This is going to be very embarrassing for the company. Is that what you want? ”  Nobody wants that.  Everybody is trying to do a good job, to the best of their abilities.  This is another danger point.  Everybody wants to show willing.  Nobody wants to be a naysayer.  It’s very tempting at this stage to say something like “well, we’ll try our best.”  What else were you going to try?  Your second best? If you do say something like that, what the bosses will actually hear is “forget what we said about this project taking three times as long as you thought, we’ll simply do it all for when you want it.”

This admission that the real reason they’re being so difficult is that THEY are going to have to have an awkward difficult conversation is actually the opening that you need to get a decent bargain.  Which bits of functionality would be enough to save face/avoid embarrassment/stop the stock price from plunging?  Let’s agree to do those first as a priority.

5) Acceptance

This is where you’re headed.  You hope.  The one thing that you have on your side is that you are actually collecting the figures that show genuine progress through the backlog.  If you get denial initially, you can wait an iteration and then point out the realities again.  This is why it’s so important to resist any attempts by the bosses to manoeuvre you into promising something that you know to be impossible.

Pushing through or over the Agile bad news bump can be a hairy experience. It can feel a lot like white water rafting.  A properly turbulent experience where neither you, nor your bosses know which way is up.  If you’re doing your job well, you’d be delivering good news to the bosses wouldn’t you?

But the Agile bad news bump, can, if handled well, actually be a powerful method of aligning senior management and stakeholders.  Negotiating bad news this early in a project does one of two things – it either kills the project, or makes it stronger. The bosses and teams that are actually doing the work, to one single view of where the project is and where it’s going.

Obviously what you’re hoping for eventually is for the bumps to get smaller.  And if you start to put similar work in the same problem space through a mature team they will do.  They won’t go away altogether.

Posted via email from Agile Lab Blog

You are here...

Sent from my BlackBerry® wireless device

Posted via email from The Ginger Mumbly

You are here...

Sent from my BlackBerry® wireless device

Posted via email from The Ginger Mumbly

You are here...

Sent from my BlackBerry® wireless device

Posted via email from The Ginger Mumbly

Gig Monday 10th September Comedy Virgins at the Cavendish Arms - Stockwell. FREE!

Directions:

http://goo.gl/maps/0wp4S

Posted via email from The Ginger Mumbly

Video of my stand-up - need to get some new ones

Posted via email from The Ginger Mumbly

Paralympics Routine - Let Me Know if You're Offended (except by the bits that are rude to David Cameron)

What's all this fuss about Prince Harry?  If I want to see a naked, ginger idiot,  I simply look in the mirror?

I'm allowed to be gingerist.

I went to see the Paralympics swimming a couple of times in the last week.  And I have to admit that any reservations I had about the quality of the competition completely evaporated when I saw the first race.  It was a back stroke race and it was won my this guy with no arms - he's called Tao Zheng of China.  This guy is fucking hard. Not only did he swim with no arms, when he gets to the end how does he stop? He bangs his head into the wall.  Not by accident ON PURPOSE 'cos that's the fastest way to finish.  Now that is some dedication.

But I have to say, I don't think he's anywhere near as fearless and dedicated as our own prime minister David Cameron.  He's so desperate to get a photo opportunity which might give the idea he's a human being, he actually turned up for 10 minutes to watch Ellie Simmons win the gold and then presented her with the medal.  If I were David Cameron, I'd be ever so slightly worried about escaping with my life if I were surrounded by British disabled people, certainly I'd expect to be pulling prosthetic legs out of my arse for a week - "That's for docking my benefit you shiny headed fucker."

It has been heartening though to see that Oscar Pistorius is capable of competing on a level playing field with able-bodied athletes - for the prize of being a bad-losing twat. "It's not fair" this is my South African accent "It's not fair, he ran faster than me, he must be cheating." In

But there's dedication, and then there's dedication.  Has anybody read about the guys who cheat in the Paralympic games? Has anybody heard about how they cheat? Apparently some of the athletes artificially elevate their heart rate by electrocuting their own testicles. I'm sorry.  I don't intend to ever be that dedicated to anything.  I love comedy.  I really do - I'm never hooking my nads up to a car battery for it, even it if did get a laugh. Do you know what some of the side effects are of this particular method of cheating?  Bleeding from the eyes - nose bleeds and stroke.

Now this is just me.  But if I was in a wheelchair.  I'm not saying everybody should think like this.  At I know we're making a joke about a tragic situation, but if I were in a wheelchair.  I think one of the things that would be going through my mind would be "Well, that's me excused games FOREVER." I really don't think I'd be saying "Dad are you using the car, 'cos I was thinking of going down the gym with the battery."

I realise that Paralympics is a touchy subject. Some comedians have got in trouble for telling Paralympics jokes. So I just thought I'd end with this.

What's got a big ginger beard and 30 seconds to live? Frankie Boyle at a Gulf War veterans benefit.

Thank you, good night.

Posted via email from The Ginger Mumbly

Very Little

It is indeed very little that we need! But lacking that, the journey into the labyrinth is without hope.

Joseph Campbell - The Hero With A Thousand Faces
Sent from my BlackBerry® wireless device

Posted via email from What Stringer's Reading

The Theatre

In that loft every one of us was a success in life - not a single failure - which is the alchemy that draws the misfits of the world into theatre.

Joan Rivers - Enter Talking

Posted via email from What Stringer's Reading