Here’s an equally commonly lost point – in fact it’s almost identical.
Agile (or Lean, TOC, whatever) is a means, not a solution.
Our customers, users and stakeholders don’t want “agile”, they want “success”. Once they have success they’d quite like a means of making that success more repeatable but ultimately they simply want success.
We seek to promote our way of working (one of our goals as an agile community) but risk missing the actual goals of our stakeholders?
Our conversations should move away from Agile by name and onto:
how do we best attain our stakeholders goals?
how do we effectively identify those goals?
how do we attain consensus on what those goals are?
what do “success”, “good” and “OK” look like for everyone involved?
If we step back, agile is just a marketing term – a simple pattern for a collection of mostly proven ways in which we believe we can work effectively. Where we need that marketing or verbal anchor, let’s use it – (much like we’ll use whatever agile practices and culture we know are useful in attaining our stakeholders goals) – but let’s ensure we’re not having methodology and culture conversations for the sake of methodology and culture alone.
Before diving into “agile” discussions, step back and (re-)establish what success should look like for your customers and users from their perspective.
Just under 4 years ago I set myself a goal to “socialize the concept of technical debt” within my organization. I had a strategy but no visible means of measurement. When I’d achieved my goal it was obvious that I’d succeeded but I had no direct evidence to prove it. – and why bother? – I succeeded.
Thanks to Luke Morgan (Agile Muze) for the inspiration of the “Elephant Test” – I’d never heard of it until last week.
For years everyone I know has been indoctrinated into using “SMART” goals (as defined in the early 1980s). As a line manager, employee of multiple large corporations and one-time domain expert in learning and performance management systems I too bought into and supported the “SMART” mnemonic.
Here’s a challenge – try running a 5 whys exercise on each of the attributes of SMART.
I can develop valuable meaningful responses (not excuses) to most of these except measurable.
I’ve spent enough years working for corporations that love to measure to have a very good handle on the values and dangers of measurement. But until my inspiration from Luke, I never had an alternative.
Today I do!
Why measure something when you implicitly know, trust and recognize what you’re looking at?
The Elephant Test “is hard to describe, but instantly recognizable when spotted”.
A big leap in agile management is trust. Trust your teams to do the right thing.
If you trust your team to set and accomplish their own reasonable goals, you must also trust their judgement.
If you trust their judgement, they must be able to recognize when they’ve achieved a goal.
Measurement is the most brute force way of recognizing something – but not the only way.
Software development and management is a knowledge activity. We tacitly know what’s right and wrong and we openly share that recognition. Occasionally we choose to measure but much of the time we trust our judgement and that of our teams.
So if the team says they saw an Elephant, chances are they saw an elephant.
Or don’t you trust them?
If that Elephant happens to be that your team believes they’ve met their goal and their stakeholders agree, why must that goal be explicitly measurable?
I know when I’ve made a difference and those around me know when I’ve done a good job. That team consensus is far more rewarding and more trustworthy than preparing measurable evidence – it’s also a lot harder to game and a lot harder to sub-optimize your behavior to group perception than around numbers.
Next time you’re looking at goal setting. Don’t go overboard on making them all measurable. If they can pass the elephant test, that should be more than sufficient.
Try starting out with a clear simple vision, good direction, a suitable time window, a strategy and some commitment to do the right thing and work from there. You’ll know amongst yourselves when elephant-testable goals have been achieved (and delivered in good faith). These may also be some of the most valuable impacts your team can have.
Last year Chris Matts wrote an insightful post reflecting on the Agile Manifesto and business analysis. At the time it sparked some creative thinking but I didn’t turn it onto the right words.
Now I have them.
Writing software is just a means to an end. Our customers and users don’t always want software (with the exception of games). They want to be able to achieve something and fulfil their role.
Software was developed to help us achieve things in more effective, efficient, accurate ways. We have CAD tools because it’s seen as better than traditional draughtsmanship. We have Financials applications because it adds more value than traditional double-entry book-keeping. Software is written for commercial fighter aircraft because we made them too complicated for people to fly alone.
I could go on…
Remember you’re solving someone else’s problem or making someone’s life easier or safer, not just writing software for the sake of software.
The next time you think about adding a speculative “neat” feature or idea to the backlog, think about who will actually get value from it.
Admittedly, sometimes it might just be to tick the box on an RFP in which case your investment should be lower than if you’re delivering for real end user value but there is business value in doing something.
Inspired by this post I just read from Seth Godin. As an average joe, hob-nobbing with CEOs isn’t so likely for most of us but the interpersonal interaction certainly is worth making time for. However…
If you’re paying to learn and thinking of attending Agile 2011 (or any other really big conference) take a team!
For the last couple of years I’ve attended the big US Agile Alliance conferences. I love going although I miss my family; I really enjoy the social interaction, spending time with (on the surface) a bunch of smart, similar-minded people sharing a week of learning, collaboration and fun. There are of course undercurrents (see this old post from Jean Tabaka) but I still find attending these conferences a rewarding experience.
For anyone that’s not been, the Agile 20xx conferences are huge and seem to be getting bigger every year. The number of parallel tracks – all with great presenters means you really have to make a plan.
Each year I’ve attended, I’ve had the luxury of going out as part of a team. My advice to future attendees is the same – take a team and collaborate on what you want to see.
My goal each year is to walk away with at least 3 key pieces of new thinking that would add value to my teams. The travel and conference fee for just 3 ideas might be excessive but as I said, I also go to learn, collaborate and have fun.
If even 1 of the ideas I bring back is sticky enough to be introduced successfully to a group of nearly a thousand engineers worldwide then I think that’s worthwhile!
So which sessions do you attend?
Personally I tend to steer away from the “rock star” sessions. Most of what they’re presenting is covered in their current or forthcoming books (and I read a lot of those already) so I don’t get much from them. Other members of my team don’t read so much and so will go along to some of these. Get the team to strike a balance but make sure the motivation is to learn and share, not just to meet “famous people“.
The stuff out there from people without book deals is rarer so I make the most of those sessions but less-experienced or well-known presenters may mean a higher risk of a not-so-good session. Also keep an eye out for the open space sessions and lightning talks. You’ll find a lot of up-and-coming talent and thinking out there but again, your mileage may vary.
I also tend to look for things that are relevant to my current context, and future direction, not just my current role. A big part of my interest is in viewing things from other people’s and roles perspectives – for example I’ve never formally had the job title of “tester” but “Agile Testing” is one of the best books I’ve read that really “gets” cross-role pairing and test strategies – relevant to developers and managers, not just testers!
Others may prefer to spend the entire week in “UX” or “Testing” tracks but generally I strongly discourage spending the entire week in a single track in your own domain – you just don’t learn enough of the other interesting gems. Maybe it’s just me but agile isn’t just about your own specialist area, it’s about the whole team and organization.
Having presented at Agile Cambridge last year; I and my team have submitted a couple of proposals for Agile 2011 as we’re hoping we can start to give something back. There’s a lot of presentations out there so our chances are slim however despite the number that don’t make it, there are hundreds of great ones that do.
When planning your sessions, take a team and go for a knowledge portfolio – balance risk & reward to get maximum return on your investment. You won’t regret it.