Monday, December 31, 2007

Carpe Annum


Here's your chance to define a new beginning...

Friday, December 28, 2007

Andon du Jour - London Underground Part Deux

It seems the topic of the London Underground has struck a chord with many readers. Unfortunately, it's not so much a symphony as irritation caused by chafing after a day out on the beach.

So I decided to contact London Transport regarding the mystery of the closed staircase.


Here is their response sent on 23 December 2007:
"I'm sorry for any problems this may have caused you. I've spoken to the Duty Station Manager responsible for North Greenwich and he has explained the following to me. The staircase was closed on health and safety grounds due to a customer incident. The management team along with our contractors, Tube Lines, are currently investigating and hope their proposed plans will mean the staircase can be used once more."
The seemingly helpful Customer Service Advisor, let's call her Susie, closes with:
"I hope you find the above information helpful and once again please accept my apologies for any inconvenience this may cause."
It's possible that her apology is genuine, heartfelt even, but I just don't feel the love. I don't sense she really cares. If I were Susie, I would have:
  1. Provided an estimated date on which the issue will be resolved (and if I didn't know, I would find out since I should know);
  2. Let the customer know that I'll keep them updated with the progress of the handling of the issue;
  3. Find out the full impact the closed staircase was having on the customer since the information may influence the speed at which the issue needs to be resolved.
But Susie didn't do any of that. Most people would have given up after the first email. I suspect Susie was hoping I was one of those kind of people. I mailed her back requesting more information:
"Many thanks for your reply. As the staircase has been closed for at least 3 months, are you able to provide an estimate on when it will be re-opened? We use the station daily and have not seen any signs of inspection going on."
Credit to Susie, she responds back:
"Presently we can't estimate an accurate timescale however, as soon we have a definitive date I will duly let you know."
Dear reader, rest assured I, too, will duly let you know. The good news is that we have a lead. Tube Lines. They seem to be the impediment du jour. That's consistent with the information from the station manager.

Meanwhile, should you have any concerns regarding London Transport, don't hold back. I'm sure they'll be glad to hear from you. Let them know what you think. You can reach them at: Customer.Services@tube.tfl.gov.uk.

Hate something, change something, make something better. It's unlikely you'll make it worse.

Thursday, December 20, 2007

The Importance of Christmas

I like Christmas. A lot. I've come to appreciate Christmas like I do weddings. I feel the same way towards Agile. All three operate on a manifesto of sorts that people can choose to either respect and adhere to or flout and play-pretend.

Everyone just wants to have a good time. And why not? In my experience, practicing Agile is a bit like driving. When you tell people you use Agile to deliver projects, you're signalling intent, one of collaboration instead of conflict. After signalling comes fulfilment, made real through behaviour and action.

It's like driving to the shops and indicating you want to turn left and then actually turning left. Unfortunately, many of the Agile drivers I meet signal left and then turn right. These are the same people who wonder why their passenger-team doesn't believe or trust them to drive safely. Unskilled drivers are a menace to themselves and everyone else on the road.

Agile, like Christmas, creates a culture of shared reality. By having a common and worthwhile goal, one that produces genuine value for instance, people will figure out difficult (impossible) problems like they've always done: through co-ordination, cooperation and convergence.

Agile is the ultimate endurance test because it demands openness, stamina, consistency and constancy. What would your project be like if everyone tried their best to get along with one another, do the right thing and do things right? It would be like Christmas. Everyday. For Everyman. How civilised.

Make 2008 matter. Instead of letting others make mincemeat out of you.
Thanks for reading. Merry Christmas and a Happy New Year!

Saturday, December 15, 2007

Agile Adverts 2007

I recently came across this rather fantastic competition from Agile 2007.

'Developer Abuse'
This one's errily accurate. Remember: it doesn't have to be this way.

'Being Agile is Our Favourite Thing'
This entry's quite clever, entertaining and hilarious. Watch it with your team. Play it loud. Sing along. Do whatever it takes to maximise your Agile reach.

Friday, December 14, 2007

A Tribute to My Team

Yesterday, I participated in the last daily standup with my latest distributed project team in 2007. Special thanks to Pete, Jeff, Smitha, Barry, Owen, Simon, Manoj, Nat, Tom, Tamas, Grant and of course, Ivan! Their greatest achievement was helping to maintain the joy-pain equilibrium that, for me, gave the project meaning. It's people who deliver projects, but it takes real teams to deliver quality sofware. Most important of all, they helped make learning possible.

'No egos' - that's an observation from the project retrospective we had back in November that sticks in my mind most. How many teams can say that I wonder? This doesn't mean we were cold-hearted, dull automatons. Not at all. Because we had a shared understanding of what collaboration really means, we raised impediments (even if that meant sometimes we had to face more obstacles than achievements). And we pulled together to resolve them. Everyone just mucked in. You have to acknowledge a problem before you can fix it.

Over time, we came up with our own team manifesto by defining:
  • what an 'open environment' means to us
  • what a 'team' means to us
  • what 'quality software development' means to us.
While the manifesto is an achievement in itself, it clearly demonstrates that the best ideas come from each individual thinking as an individual as well as working as part of a team.

For me, the best day of the project was the team gathering - a day where we began brainstorming ideas that contributed to our manifesto ultimately and the day when we played the XP Game. Team Tarka vs Old Peculiar. The pictures tell the real story: so this is what a no-egos team looks like. Seeing is believing. It's up to all of us to demand better of ourselves.

Sunday, December 09, 2007

The Next Killer App: MBPPF!

It began with MBWA...
I first came across the acronym MBWA (Managing By Wandering Around coined by Tom Peters) during the DOTCOM boom. I'd just started working as a Java developer. Managing By Walking Around is about wandering the 'shop' floor and observing how your workers do their job. It's about getting and staying in touch with the people doing 'work-that-matters'* (also from Tom Peters). It's about learning about impediments so that, as a manager, you can help remove them. It all makes sense.

As far as I can tell, it's equivalent to Toyota's Genchi Genbutsu (Go and see for yourself). Unfortunately, the particular implementation of MBWA I was exposed to seemed more like a constitutional, post-lunch walkabout by a manager who didn't care much about talking to all the people, let alone hear about our progress or concerns.

I suppose that experience made me begin to doubt management. That and the fact that pay increases seemed to be negotiated down the pub instead of being based on performance during work hours.
Call me old-fashioned - it's simply not right.

Then one day, the time came for me to transition from developer to management. I'd read a lot about Agile and recognised the importance of delivering business value. Like all managers, I was faced with two thorny problems: 1) business value was difficult to quantify, so the movers and shakers sent out an edict of: 'Do as I say' using MosCoW rules; 2) developers weren't enamoured with poorly defined requirements - it's hard to derive satisfaction from delivering a never-ending 'something'.

Still, I beat the 'Deliver-Maximum-Business-Value' drum, because that's what leaders do, right?
Business Value = Job + Salary -> Survival + Nice Holidays. For the department. For the developers. And for me.

The Next Killer App: MBPPF!
But delivering business value alone is not enough. Not for me. Doing work-that-matters on its own isn't enough either. Success means making the most of your options. Maximise your people's potential and watch your options grow.**

What motivates me most is what I call MBPPF*** (Managing By Putting People First). The MBPPF model works like this. It looks familiar because all of its constituent parts are taken from existing models. Good ideas are, more often than not, composites of existing ideas. If you have to have wheels, round ones work best in my experience.


What does Putting People First mean?
  1. Start with a main goal - To deliver Genuine Value to your customers: Identify what people want (preferably things that would enhance their lives in some way). Something for which there is a demand is easier to sell. This means you can focus 100% on differentiation and quality.
  2. Do enough upfront business analysis: Brainstorm how best to fulfil this want (taking into consideration the product's context such as time and place). Know why people need it, when they need it by, how long they need it for and what else they can use it for.
  3. Build a team that cares: Put together a bunch of competent people who want to fulfil this want, as a team of creative, thinking individuals. Show you care by consulting, involving, informing and empowering your team.
  4. Everyone does work-that-matters: This is a great motivation for many people. It leads to the elimination of waste and can be leveraged to put best practices in place. When you do something that matters, most people naturally want to get better at it. Now that's a real bonus.
Sample practices of MBPPF!
  • Put people-interest ahead of everything else (and watch the decision-making machine produce the optimal solution).
  • Spend time with people because they matter most.
  • Hire people better than yourself.
  • Know when you need help then ask for it. I'm constantly amazed by what I get back in return.
The rest is based on what works best when you apply the principle of Putting People First. Try it. You might like it.


*Work-that-matters: Have you noticed how many organisations are encouraging their staff to get involved with planting trees and painting classrooms these days?

** I like to maximise mine with Real Options.

*** MBPPF: The Disclaimer: Just as any successful diet/fitness regime requires willpower, MBPPF requires people willing to get involved, people who will muck in as pigs instead of play chicken.

Friday, December 07, 2007

Festive XtC: 11 December in London

Suffering from the winter blues? Fed up with never-ending requirements discovered during UAT? Then come along for a spot of festive cheer and peer coaching at next week's Extreme Tuesday Club in London. Hope to see you there! Where? There.

Thursday, December 06, 2007

Kanban du Jour - The Tell-Tale Tannenbaum

It's that time of the year again: gratuitous displays of a jovial fat man in a red suit scaling miniature gingerbread houses and base jumping off slippery rooftops. If the advertisement boards are correct, it's also time for seasonal teeth whitening. O! And, of course, the hordes of plastic trees in the shopping arcades. (Better a plastic tree than a tree on death row in the living room.)

Ho! Ho! Ho! Spot the problem
UK tradition has it that shopkeepers save up
to pay for decorations to attract more custom during the Christmas period. In return, they get to worry about not only having their in-store goods stolen, but their pricey Christmas baubles being taken too. The plastic card boasting of CCTV monitoring is an example of trust broken. It tells us, loud and clear, that we are a thievery nation.

Where did all the trust go?

It reminds me of when managers give their teams approximate (fictitious) deadlines to work towards instead of actual ones. One date for the development team, another for the customer. Presumably it's because they think that developers are lazy and won't work hard without unrealistic deadlines. Such behaviour helps us identify the chicken managers from the pig managers. By keeping the actual deadline to themselves, such managers are witholding information. By withholding information, they are limiting the team's options to work optimally towards successful delivery. By putting in a false constraint, a manager is actively guaranteeing their project will fail. By doing so, they're also limiting their chances of personal success. If you are committed to a team, witholding information is illogical.

Teams know when they're being controlled. Unlike collaboration, the command-and-control style of management can reduce or even eliminate trust. Without trust, there can be no loyalty and commitment. Without loyalty and commitment, you can forget about performance. Chicken managers often confuse collaboration with coercion.

You have to put trust in to get trust out.