New Kids on the Block

My first ever commercial IT project was to tweak an existing application that sent out financial news by email. I remember really enjoying the challenge. I learned how to set up my local dev environment. I learned about the release process using foil packs of tea as release tokens (creativity was what made the Dot.com days special). Most important of all, I learned how to write code better by looking at bad code.

As time passed, I was exposed to terms such as ‘maintenance’ (more sinisterly known as BAU – Business As Usual) vs ‘greenfield’. I was surrounded by developers who complained that BAU was gruntwork, that they wished they could do greenfield work instead.

‘Avoid maintenance work at all costs’

Many of those developers were given greenfield work, only to create an even larger legacy of bad code. I found that I appreciated a balance of maintenance and greenfield work because, together, they reminded me of the cost of over-engineered or badly designed solutions that I would have to help support.

The Longest Journey

Still, the conundrum of endless maintenance bugged me. Then one day it dawned upon me: Everything in life is BAU, be it buying milk, having breakfast on a Monday morning or attending yet-another-pointless meeting warped by political posturing. And, of course, keeping fit.

Welcome to your most important maintenance contract. It’s for life. Make it fun. Fill it with learning. Make it meaningful.

‘No one enjoys their job as much as you do. You have way too much fun.’

– Grumpy

Agile Games Day

This Monday marked the day of yet another of Agile Firsts. It was the first time in Agile history that the XP Game and Business Value Game were played, back to back, in a single day, at work.

Learning Through Fun and Games

The day began with a frenetic ice breaker exercise during which participants introduced themselves to three different people, tasked with finding out three interesting facts each about one another, spending only three minutes per pair. What’s striking about this exercise is the rapidity with which folks are able to identify the things they have in common in so short an exchange, such as their mutual passion for cricket and life experience as parents with small children.

XP Game Teams: The Ones vs Agilites

Next, we moved straight onto the first game of the day: the world-renowned XP Game invented by Pascal Van Cauwenberghe and Vera Peeters. The XP Game is a great induction into what being part of an Agile team feels like. Who would have thought that blowing up balloons, building houses out of cards and folding origami paper boats and hats could teach you so much about iteration planning, estimating and velocity? Thanks to Pascal and Vera, work is made fun again, with quality built into everything we do.

Witness the intensity of concentration on furrowed brows in the pictures. Can you feel the buzzing activity as folks work hard at completing user stories with the highest business value possible? Now, look around your work place. Are you surrounded by such enthusiasm and dedication? If not, playing the XP Game with your team may be an antidote to corporate inertia and ennui.

Roles and Responsibilities

Next up was a team exercise to define what being an Agile Team Member means. ‘Agile’s about being creative,’ cautioned one participant as he put coloured pen to paper and started scribbling. ‘It’s nice to work in a colourful team space,’ he added with a shy smile.

Business Value Game: The Cake Eaters vs The Cake Snatchers

To complete the Agile Games Day, we played the all new Business Value Game, also brought to you by Pascal and Vera. What’s striking about the games Pascal and Vera create is their relentless pursuit of learning through fun and games. The games demonstrate time and time again that to do great work, you have to have fun.

The most important lesson that runs through both games is collaboration. To win, you have to work as a team. If it’s that simple, why doesn’t everyone do it?

Imagine. It’s 10.15 in the morning. The team’s just finished their daily standup. One of your team members seems to have gone missing.

The Office

(In an open plan office)
S.: Morning!
P.: Morning. (Pause) Everything all right?
S.: Sorry I’m late. I had to go to the vet.
P.: I didn’t know you had pets.
S.: I don’t.

It turns out Sruthi had found a sparrow lying injured on the road on her way to work. She immediately took the wounded bird to a local vet, but they refused to look after it, so Sruthi took it home and made it a comfortable little bed on her kitchen table. She then fed it some milk before setting off to work again.

Sruthi and I had had another of our 1-2-1 Agile Coaching sessions the week before. I learned that she loved animals and would like to be a vet if she could do anything else other than her current job as a Java developer.

On that fateful morning when Sruthi saved the sparrow, we both knew that her detour wouldn’t negatively impact the project. The project deliverable was being integration-tested and we had to wait until the US dev team came online in the afternoon (UK time) before she could do any more testing.

Just before Sruthi went back to her desk, I asked her what state the sparrow was in. She said she couldn’t see any external wounds, but that the bird seemed very weak. ‘It’s likely the bird won’t be alive when you get home tonight,’ I said. Sruthi looked surprised. It was the first time I had to deliver that kind of bad news on a client engagement.

The next morning, the sparrow was gone, but Sruthi and I both knew we did the right thing.

Folks who are genuinely agile, understand that people and trust are at the heart of Agile. Is there anyone on your team you don’t trust? Why don’t you trust them? What does what you think about them tell us about you?

Writer to Reader

P.: I compare Agile to a pair of socks.
J.: I know, I read your blog.
P: What do you think of it?
J.: I like it. It’s quirky. And it’s based on genuine coaching experience. (Pause) I’ve often thought of writing my own.
P.: That’s a great idea! For years, I didn’t think I had anything unique or worthwhile to blog about. Then I finally decided to share my take on Selfish Programming.

A Blog Reader’s Story

AS A Reader
I WANT to read about other people’s ideas, opinions and experiences
SO THAT I learn new things or re-learn things important to me that I’ve forgotten

Acceptance Criteria

[Y] Is there a steady stream of new posts to keep me reading (at least one per month)?
[Y] Is the information authentic (based on personal experience and perspective)?
[Y] Does the blog give me new ideas?
[Y] Does the blog help me develop my existing ideas?
[Y] Does the blog help me look at my bigger picture?

A Blog Writer’s Story

AS A Blogger
I WANT to share things I’m passionate about in a fun and creative way
SO THAT we become a little more agile every day

Acceptance Criteria

[Y] Does my blog have a clear purpose?
[Y] Do I share information useful to others?
[Y] Do I present the information in an engaging way?
[Y] Is the information authentic (based on personal experience and perspective)?
[Y] Do I have fun blogging?

A Portal to Endless Opportunities

I blog because it:

• Challenges me to think deeply – to question why I’m doing what I’m doing
• Forces me to communicate effectively – in terms of saying what I mean and meaning what I say
• Creates opportunities, such as being invited to present at conferences like Université du SI
• Connects me with other people I would never otherwise meet, learn from and collaborate with

Why do you want to blog? Once you know why, why not create your own blog in under 25 minutes?

‘To some, responsibility is a burden. To others, responsibility is a reward. For many, responsibility means having someone to point to.’

– Christopher Avery

It was great to finally meet Christopher Avery at the Agile Business Conference this Wednesday. His presentation on the Responsibility Model, delivered in person, was every bit as insightful and entertaining as I hoped it would be.

‘Humans are born to learn’

According to Christopher, Responsibility has long been considered as a character trait. Or, depending on your view of the world, a character flaw.

Newsflash: Responsibility is neither a character trait nor flaw. Christopher describes Responsibility as the way you respond to a problem. Responsibility is completely subjective. It’s also a feeling. This is why Responsibility is so difficult to talk about.

For me, the most effective way of thinking about Responsibility is to compare it with Accountability. According to Christopher, delegating Accountability is the first tool of management. It’s a one-sided agreement-making process in which one individual beholdens another regardless of whether or not that individual accepts the responsibility that has been thrust upon them.

Responsibility, on the other hand, empowers an individual by giving each of us the choice to acknowledge then embrace the uncertainty surrounding our lives and to do something about it.

Redefining Responsibility

There are six progressive phases in the Responsibility Model:

1. Denial – ‘Problem? What problem? There’s no problem.’
2. Blame – ‘I don’t have a problem working with you. You seem to have a problem with me. That makes it your problem. ‘
3. Justify – ‘I guess it’s possible that I’ve become insensitive to other people’s feelings and needs. I can’t help it though. After all, I’ve been doing this job for a long time. It’s who I am.’
4. Shame – ‘What have I done? I’m going to look such an idiot in front of the people at work. How am I going to live it down? Why should they help me after the way I’ve behaved?’
5. Obligation – ‘Tell me what you think I should do. I have no choice but to do it (even though I don’t want to). I’ll do whatever you say. It’s only a job after all (no one can expect to do a job they love).’
6. Responsibility – ‘I can wait for them to change but that could take forever. No, it’s up to me. I want to fix the problem. So how am I going to be a better colleague? I know! I’ll listen more. And be more considerate towards others. It’s a start.’

Taboo Who?

Embrace responsibility. Instead of skirting around it, talk about it. Practice moving through the 6 phases of the Responsibility Model. Help each other spot when one of you become stuck in a particular phase. The key to continuous improvement are what Christopher has identified as the Keys of Responsibility.

The Keys of Responsibility

1. Intention – Commit to doing or stop doing something.
2. Awareness – Learn to recognise when you are in each of the 6 phases. Look out for how you feel in each of those phases. Use the feeling to help you recognise which phase you’re in and evaluate why you feel that way you so that you can move onto the next phase towards Responsibility.
3. Confront – Face the truth head on. It’s sounds simple, but it’s not easy. How honest are you with yourself?

Adopting Agile brings out the best in people, it brings out the worst in people. That’s because Agile is a challenge for change: for the individual, for the team and, above all, for the organisation.

For many people, Agile evokes fear. Fear of uncertainty, fear of looking foolish, fear of being held accountable, fear of the problems it uncovers, fear of having to deal with those problems. That’s a lot of fear.

But there’s more. The fear of the consequences if we ignore the problems. And the biggest fear of all: the fear of having to face ourselves.

Perfect is Poison

‘Our Agile process clearly isn’t perfect yet. What we need are lots more iteration zeros to get it right.‘

Perfect doesn’t exist. Perfect is something we aspire to, it’s elusive by design. People use it as an excuse when they’re unable to cope with mistakes, especially their own. Mistakes they made in the Past, mistakes they’re making in the Present, mistakes they’ll continue to make in the Future – if we choose not to change.

Perfect as Procrastination

Wisdom comes from experience. Experience comes from learning. The most valuable learning happens when we make mistakes. That’s where Agile comes in.

Agile is about Continuous Improvement. Agile is about failing early, so that we can learn from our mistakes earlier – instead of waiting for things to be perfect. Before you can fix a problem, you have to first acknowledge it exists. Especially if it’s your fault. Don’t wait for when. Ask others for feedback then change the way you work. Now.

One Agile coach says to another, ‘How do you find the strength to carry on?’

The other coach replies, ‘I believe in “happily ever after“‘.

Going Off the Rails

In my experience, the toughest period on any Agile Enablement gig is the first two iterations. Some have described it as a rollercoaster ride – the corkscrew-space-mountain type where you can’t see where you’re headed because everything’s pitch black, your stomach’s one big writhing ball of worms and you have begun to doubt you’ll survive.

It’s also the roughest of rides because just when you think you’re getting it, you discover there’s more to learn. And then some. It’s harder to go on precisely because you remember the difficult road upon which you’ve just travelled. And your gut tells you that it’s going to get harder before it gets easier.

The Road Less Travelled

Agile is about Continuous Improvement. If you’re truly dedicated to improving, you will demonstrate your commitment by learning new stuff and brushing up on the old stuff. Eventually, the old stuff gets displaced by a re-combination of the old and new and you come up with better ways of working.

‘H’ for Helping Yourself

People new to Agile almost always believe they’re already agile. This is rarely the case. The penny only drops when the first person in the group openly acknowledges that, ‘Hey, it’s not a process problem we face, it’s a matter of mental attitude’. The greatest impediment to Agile adoption is people. It’s you. And me.

‘H’ for Hope

If you’re genuinely agile, you don’t just give up. Why? Because you know there’s always hope. You know being agile demands continuous improvement, so as long as you’re changing yourself for the better, you’re one small step closer to a better and happier work life. You can help make change happen at your organisation. What’s the one small change you can make to yourself today to change things for the better?

If Agile were a food (instead of a project delivery methodology focussed on people and collaboration), it would be Marmite.

Marmite is a savoury black spread made out of yeast extract. Yes, that’s right: extract of yeast. To some it’s taste-bud tingling good while to others it’s more revolting than three-day old roadkill on a hot summer’s day.

A Love-Hate Phenomenon

It’s estimated that around 50% of the entire UK population love it while the other half hate it. Marmite reminds me of Agile precisely because of this polarised reaction to something as simple as extract of yeast. Marmite reminds me of the extreme reactions I get from folks new to Agile who find themselves challenged by the fundamental values of Communication, Simplicity, Feedback, Courage and Respect and what these values really mean in practice.

Processes Don’t Fail

Some individuals say, ‘Agile’s not for me!’ while others say, ‘Agile doesn’t work!’ Then there are those who declare, ‘I can deliver much more on my own!’ To which I would reply:

1. Agile is for the team, not just the individual.
2. Processes don’t fail, people do.
3. If what you do depends on work others have to do before it can be released to Live in order for its value to be realised, how can you measure success solely based on your own endeavour?

Actions Speak Louder Than Words

Agile is much more than just a way of working. It’s about taking responsibility for who you are and what you do, both as an individual and as part of a team. Agile is about putting your team before your ego so that you and your team can move forward together. What value do you place on teamwork? How agile are you really?

Rejection’s tough to take. More often than not, it’s painful, humiliating and disappointing. Sometimes even devastating. It can get really ugly, not just for you, but for all parties involved.

Now we’re all agreed on what rejection feels like, here’s how to best deal with it: Avoid rejection by improving your interviewing technique.

Rejection Can Be Avoidable

In the world of consultancy, failing to get a contract is a form of rejection. Likewise spending five years on a supa-dupa high profile project only to have it rejected two weeks before it goes live because we got the requirements wrong also merits an R for REJECT.

Just as you would spend some time preparing for a romantic night out with a significant other, be sure to gather the information you need to bring about a happy ending to your business engagements.

How the Nine Boxes Technique Can Help

The Nine Boxes is an interviewing technique from the Solution Selling® sales process.

It’s a structured approach for:

1. Discovering the root causes of problems
2. Identifying those affected by the problems
3. Creating an agreed common vision of the solution between you and your customer.

Bonus: The information gathered feeds into user stories as demonstrated by Dave Nicolette.

During the information interview, we gather information about 3 aspects of the problems:

• Details of the problems
• Those impacted by the problems
• What the world will be like when the solution is in place (outcome visioning)

For each aspect, we ask 3 types of questions (3×3=9):

Type 1: Open questions allow the interviewee to tell their story (aka Qualification):

• ‘Tell me about…’
• ‘What happens after that?’
• ‘Why is that?’

Type 2: Control questions help fill in the facts of the story (aka Quantification):

• ‘How much…?’
• ‘How many…?’
• ‘How often…?’
• ‘When does that happen…?’

Type 3: Confirm questions verify the interviewer’s understanding of what the interviewee has said (aka Confirmation):

• ‘If I’ve understood correctly… Is that correct?’
• Only when the interviewee replies ‘Yes’ does the interviewer proceed by posing questions about the next aspect of the problem.

‘Sounds complicated – what do others think?’

I’ve co-presented The Nine Boxes session with Pascal at a number of conferences and participants come out amazed at how quickly and accurately the structured approach helps them elicit the root causes of problems. Most important of all, those who play the role of interviewee (the customer) always say what a refreshing change it is to talk to an interviewer who is a good listener and is capable of developing an accurate understanding of the problems.

The Nine Boxes Technique game was created by Pascal and can be downloaded from our Agile Coach site.

What You See Isn’t What You Get

‘But what if clarifying the problem leads us to discover it isn’t a problem after all?’ I hear the consultants among you ask, throwing your hands up in horror. ‘That’s great news – congratulations!’ I say. After all, it’s one of the best possible outcomes of using the Nine Boxes. Why? Because a customer who is genuinely committed to continuous improvement for their organisation would:

1. Be impressed by your problem finding acumen and thank you heartily for helping to clarify the misunderstanding that has caused so much confusion and resulted in so much time wasted to date.
2. Be impressed by your professional integrity for being open and honest instead of charging them for inventing a solution to a non-existent problem.
3. Ask you to help identify areas where improvements can be made.

More Than Words

Build integrity into everything you do. Take the 5 Agile Values to the next level: build Trust and increase Transparency.

* Special thanks to Gino and Pascal for taking this entry’s feature picture

Fear of the Unknown

One interesting similarity between being a coach on an Agile Enablement gig and presenting at a conference is this: dealing with an audience who secretly fears the Unknown.

In my experience, there are 3 main groups:

a) Those who ask for help
b) Some too afraid to ask for help
c) Others who think they know it all

Which group do you most identify with? For most people, in an ideal world, change would happen with minimal pain and even less hard work. In fact, many people don’t feel they need to change: ‘Help? Why would I need help? Of course I support Continuous Improvement! Change is for other people though. I don’t need to change.’

These folks make-believe that others need to change, but not them. These folks are usually the ones most resistant to change and this resistance manifests itself, at best, as self-deprecating humour or cynicism and, at worst, as silent sabotage.

The major casualties of such silent sabotages are the individuals themselves. I know this because whenever I resist change I miss out on learning new things and re-learning lessons I’ve forgotten. I end up losing out. I become the largest impediment I have to deal with. But I have a choice. I have the power to remove this seemingly insurmountable impediment by confronting it face-to-face.

Should I stay or should I go?

Occasionally a coachee asks me outright if they’re cut out for Agile projects. They’ve usually taken a bold leap of faith by daring to try to do something different while their colleagues and mates at work look on in wonderment / disbelief / morbid fascination*.

It’s a tough question to answer. As a coach, I’ve learnt the importance of providing feedback that helps people improve instead of criticising or passing judgment. After all, who am I to cast the first stone if I’m not prepared to offer suggestions when asked to help others change for the better? I’ve also learnt that anything that doesn’t increase value leads to more waste. A waste of breath, a waste of time, a waste of human life.

What is potential?

Agile has taught me that everyone has value. Before Agile, I remained sceptical of such a notion. Before Agile, the notion that everyone has value was merely a hollow incantation that, as a manager, I recited and barely believed.

As an Agile Coach I’ve learnt to spot potential. First I had to define potential. Potential for me means a willingness to learn which really means a willingness to change. Most important of all, potential is the willingness to change oneself instead of expecting others to change. After all, we can only change ourselves and lead by example.

Survival of the Fittest

I often hear folks say, ‘This organisation will never be agile’ or ‘Agile only works on certain types of projects – it won’t work on mine’. The reality is this: processes don’t fail, people do. If a process doesn’t work, people can change it. Believing change for the better is impossible is like clinging onto the belief that the world is flat. For as long as a team or organisation can improve, Agile can help you deliver value. So the question we all have to ask ourselves is: what’s my time worth to me? Don’t let it be a waste of breath, a waste of time, a waste of human life.

* Delete as appropriate