Is your bacon on the line?

Source: implementingscrum.com

I’ve worked in a few organisations and on a few teams now. Most of them (ab)used some form of agile methodology. They paid lip service to the benefits, but treated everyone like a pig. The “flat hirearchy” mentality which unfortunately just doesn’t work because in every organisation, and indeed in every role, there are pigs and there are chickens.

Is your bacon on the line?

I know for a fact that the metaphor above would have failed in a number of the teams because the dicipline wasn’t there – The answer from each and every sales person would have been, yes my bacon is on the line; I need to make this sale. From management, yes all of our bacon is on the line; we make this big sale, or we need these changes they will make the company!

The problem with both these arguments, and this is what the chicken helps us show, is that the failure for the pigs is a disaster. Failure for a chicken means they just need to try again and they might get the elusive golden egg – or was that a goose…

At any rate to take the sales argument to task – just that there tends to be more of them and it’s easier not to pick a fight with management – You wouldn’t have some techie telling them how to conduct sales, coming up with a new procedure for them to implement or rewriting your pitch – say just for example cold calls from a call centre then escalating hot leads to the sales team so they could focus on closing better leads. It might sounds alright, but the techies aren’t the pigs in this situation. If the idea turns out to be a rotten egg, the techies aren’t really affected, the can turn around a new egg in a day. For the sales team on the other hand, they’re losing sales and commission.

Similarly feature ideas from sales staff should be treated just like any other feature request. Might be a good idea, but it should be given no extra weight. Try to avoid falling for arguments about them talking to customers all day long – it sounds good, but they’re talking to people who may one day use your product and it’s easy to say you would use a specific feature, it’s quite another to actually use it. 

As people who know me, know already, I don’t actually believe in building what the customer says they want – more often than not they don’t really know either. I find a much better process for everyone is to have a discussion with them about what they want to achieve and to measure what they’re actually doing. Developers know best what can be done, users what needs to be done – how something is actually being used is a matter of fact and should be measured. Features can then be developed and added to meet your vision. 

I’ve been in the position all too many times that a feature was requested because “everyone I’ve spoken to” wanted it. When the feature was implemented, it cost a lot of potential development time didn’t advance the product vision and ended up not getting the customer! Then to add insult to injury people started wondering where we were on the list of features that actually did advanced the vision – as if that schedule hadn’t been compromised by slipping features in. Rinse and repeat a few times and before you know it, it starts to look like all the features the techies are adding aren’t adding any value – which quickly turns into the techies aren’t adding value. 

The above doesn’t always necessarily follow adding a few features people ask for, but at the end of the day features and how they’re implemented should be the responsibility of the ones with their bacon on the line, not the chickens. 

Related articles by Zemanta

• Keep Agile When You Are Doing Agile
• Closing the gap between development and operations
• agile company creation

Related posts:

1. Release early – Release often
2. Don’t sell features
3. Don’t listen to your customers
4. almost profitable
5. Peanuts and monkeys.