Inspect & Adapt

Have you ever come across one of those people who, even though they’ve only just arrived on the scene, is keen to tell you that, “(they) know exactly what the problem is” and “what you need to do is...”? Well I have – unfortunately on more than one occasion - and I find them extremely annoying!

I’m sorry, but it doesn’t matter what your background is and how much experience you have, you cannot possible approach a person or team in such a manner and retain your credibility.

It’s not just consultants who can fall into this trap. I’ve also seen recently hired employees make this same mistake. Let me reiterate, this is not a great first impression to leave behind! Having been on the receiving end, my immediate thoughts about the offending individual are generally extremely poor and certainly not repeatable here.

To be fair, I don’t think this is a common trait, which is why it sticks out like a sore thumb when you see it. Most of us understand how to treat people with a bit more respect.

I’m not certain it’s deliberate either. It’s more likely to be a lack of emotional intelligence in the offender. Or am I being too generous?

Anyway, you can probably tell that I’ve just had such an incident and it prompted me to write. It’s actually quite cathartic.

The question that’s just struck me of course is how do I come across when I first arrive somewhere new? OMG, do I make this mistake too? Surely not!?!?!

Perhaps now is the time to state what I actually set out to do and this is where the title for the entry comes in. I believe in the ‘inspect & adapt’ school of thought. Before expounding my opinions, I would much rather take the time to understand the situation, determine if I have any relevant experience to contribute and then tailor my thoughts and suggestions to the context at hand. Experience counts for an awful lot, but it needs to be applied to fit the current environment if it is going to make a difference.

If you read this, know me and think that I have my own challenges and opportunities to improve in this area, then please let me know. However, if that's the case, do treat me gently with your feedback as you now know that at least I think I'm doing the right thing!

"Agile is expensive" - discuss...

I was surprised recently when I was told that "Agile's ok, but it's expensive". That was a first for me. I'd never heard anybody say that before. What could possibly have possessed them?

It's the sort of statement that sets my mind racing. What could I have missed? Is it perhaps true? After all, many say that perception is reality. It was no good, I was going to have to think about this further.

So, here I am, thinking... is Agile expensive?

First, let's understand the basic premise - "I thought 'it' was going to cost X, but 'it' ended up costing X+Y and I got less (of 'it') than I expected.". If indeed that is your reality then I can certainly sympathise. However, can you attribute that failure to being Agile? Isn't this just a classic example of project overspend, de-scoping and, quite probably, time overrun?

Perhaps being Agile has somehow exacerbated the situation? Perhaps the innate ability to embrace and respond to change has been so successful that the only logical conclusion is project failure?

Let's walk through a simple example. Assume at the start of the project I want 5 features delivered and the estimate is 5 person weeks of effort. The team diligently produces the first 3 features, expending 3 person weeks, which are then presented for feedback. Naturally some changes are discussed and prioritised. Being Agile, the team responds. After a further 2 person weeks of effort (reaching the original budget), the team presents the 4th feature, plus the prioritised changes. More changes are approved and the team then expends 1 further person week to complete those...

STOP! Look at what just happened. Because we responded to the changing requirements, we only got 4 out of 5 features delivered for a cost of 6 rather than 5 person weeks. At the micro level, the team took the appropriate direction and delivered the most important features, but at the macro level we have (perceived) overspend and de-scoping.

In my experience, at the iteration-to-iteration micro level, this type of occurrence happens all the time. So, if you're not rolling that up and communicating appropriately at the macro level, it's no wonder that Agile can be perceived as being expensive - "I'm getting less and it's costing me more" screams out, even though what you're actually getting is what you want, not what you originally thought you wanted.

No doubt my example is one of many reasons that might explain the 'expensive' comment. However, I can definitely relate my own experience to that example and, I think, it is an important reminder that managing all stakeholders and their expectations is every bit as important as being Agile in the first place.

Why Agile?

As a software evangelist who has experienced the evolution of software development methodologies, it is easy to see and understand the benefits of the Agile movement. However, our business colleagues are typically less interested in iterations, increments, pair-programming, TDD, etc. So, how do you go about explaining why your IT team is going through a massive change and what the upside will be? Well, here are some ways that I've found effective in the past:

• Delivering Exactly What You Need - working closely with business users throughout the project, refining requirements and deploying the most useful features first
  
• Reducing Time To Market - delivering effective solutions early, building additional features in stages and stopping when it's good enough
• Building Higher Quality Solutions - minimising live issues through collaborative teamwork and solid engineering principles

And if that's not enough, we would of course expect to see:

• An increase in customer satisfaction
• Better resource utilisation
• A reduction in software maintenance costs 
  

Agile is not a silver bullet, but it does tick all of the right boxes.