Something for the Weekend - Fail Fast

In a recent interview with Wired magazine, Lee Unkrich (director of Toy Story 3) said something that reflects an important part of any truly successful team. It's also a principle that's deeply embedded into Agile Development teams.

Here's the quote:

"It’s important that nobody gets mad at you for screwing up. We know screwups are an essential part of making something good. That’s why our goal is to screw up as fast as possible."

Without doubt that's contrary to popular belief... People focus on getting everything to 95% before they're prepared to share it... but don't you find that often the 95% position still has flaws? And that often it's too late to really react to them? (Therefore is that really 95%?)

A few thoughts that underpin this:

* In true 'no blame' cultures having the freedom to take calculated risks means that some will pay off and some won't. The key to unlocking innovation and creativity lie in having a 'safe' environment in order to explore ideas.
* No one person should have a monopoly on ideas. The wrong environment can suppress ideas from all but the most confident.
* The trick is to seeing the outcome of any venture as positive, if it's paid off you've increased the quality of what you're doing, if you've failed you've learned from it.

What I'm not suggesting is that it's ok to fail overall... in fact, far from it! The key word in Unkrich's quote is "fast" - The very idea of failing fast is to guarantee success! So how do we do this?

Experiment openly and visibly (through documentation, prototypes, conversations, presentations) - ensuring that all failures become minor setbacks.
* Create a culture where small failures in the delivery cycle become successes in learning, consider them R&D! It's the only positive thing to do if they happen.
* Actively encourage the sharing of ideas - everyone has them.

Sources

Interview with Lee Unkrich in Wired http://www.wired.com/magazine/2010/05/process_pixar/
Spotted via the 37Signals http://37signals.com/svn/posts/2348-its-important-that-nobody-gets-mad-at-you

Something for the Weekend - New in at #1

A slightly more businessy than the usual 'Something for the Weekend' this week, but I wanted to share some exiting research that gives recognition to the how important the role of the Business Analyst is in today's IT environment.

Research conducted by Forester and published in CIO Insight places Business Analysis at the number one slot in terms of the 'Most Important IT Roles'. I'll let you read the report yourself but I'm sure you'll agree it’s a staggering development.

Click Here

To further reinforce those messages I wanted to share two further recent research findings with you:

• 71% of failed software projects are traced to poor requirements*
• 40% of the effort in an average software project is fixing errors, and requirements defects account for 56% of re-work**

I'm feeling a distinct groundswell both internally (to my organisation) and externally in that recognition - A high note to finish the week on!!

Sources:
Main Article - CIO Insight
*CIO Magazine
**Butler Group 2005

Something for the Weekend - Simon Sinek's Golden Circle

This week, a simple technique to gain more effective and powerful communication.

Simon Sinek is the marketing consultant who developed the 'Golden Circle' - a model based on changing our natural communication style from talking about 'what' we do to talking about 'why' we do it. As he explains in his recent presentation at TED, this technique is a common trait across great leaders and organisations.



Understanding and explaining the 'why' is a really important aspect of our roles if we're to get the best possible support for the initiatives we progress. As Simon states a few times in his presentation "people don't buy what you do, people buy why you do it".

Two reasons I think this is useful to us:

• I've mentioned previously (SFTW - Solution Addicts - 4th May '10) that I believe it's an important part of our roles to help people who have pre-defined solutions (rather than problems) to articulate and back up why they want them. Not to provide unnecessary challenge but to aid a common understanding and perhaps find better, more effective options.
• As analysts our processes & techniques can seem a little abstract to the uninitiated - we know why we do them (I hope!) - Should we on occasion be clearer with our stakeholders in order to gain greater contribution / commitment?

Here's the link, it's 18 minutes long. If you can't spare that just watch the 5 minute segment between 2:00min - 7:20min.

http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action.html


Enjoy and have a great weekend-

David

Something for the Weekend… Solution Addicts

Recently I've noticed an increasing amount of people coming to my desk with predefined solutions, whist to a large degree this is admirable, on further probing there's often a lack of definition about the problem is that needs to be addressed or perhaps more specifically the root cause of that problem.


It's logical that people do this… traditional business teaches that we shouldn't dwell on the problems but instead be taking action to resolve/improve them, and after a while it becomes a habit, and ultimately an addiction. - We start to think about answers faster, faster and stop taking the step back to really look at what we're trying to achieve. A really clear symptom of this is when new information (inevitably) emerges or challenges arise and U-turns are required on solutions as a result (or worse). Framing problems and root-causes up front help with this enormously… if your solution is addressing the root-causes of a problem, new information can only help to build and evolve a better solution.

It's our role as analysts to do this, so how do we go about it? The first is step helping people to admit they have problem (i.e. not that they have solution). I've attached an 8 min video to a presentation by lady called Mary Poppendieck - she's a prominent voice in Lean based software development techniques and in this video she does a fantastic recap of pareto charts & fishbone diagrams and the importance of testing your analysis by completing what she terms "Many Rapid Experiments" http://www.youtube.com/watch?v=MhxyO6jUubQ.

These techniques will no doubt be familiar but digging them out of your toolbox and dusting them off is always a valuable thing to do.

If you've got any questions on the techniques Mary talks through do let me know.

Enjoy and have a great weekend-