Optimism is necessary and troubling

As a follow up to this video on the optimism bias, I thought I would add a few comments.

Tali's hypothesis is that optimism is a critical element of success. Without optimism we'll just give up, or not have faith we can overcome the challenges that beset us. So optimism is a net gain for the human race.

On the other hand, optimistic estimates make us fail.  We fail because we set unrealistic expectations and thus when we deliver, we let people down.

It's a conundrum. How do we optimise delivery by taking advantage of our natural optimism, and still avoid over estimating our ability to solve the problem?

Some solutions that have been tried in the past include;

• Separate the people who do the work from those who do the estimates so you can bypass the optimism in the team
• Ensure your team has pessimists on board so that they can speak of the worst case, bundle this with blind delphi estimates
• Force thinking by the team about best, likely and worst case through scenario modelling, and weight the estimates with historical performance or arbitrary numbers

None of these work particularly well.

Our preferred method today is to use historical data. And if we don't have some, to work in small bacthes until we do.

The jury is still out on how we budget for the rocket to Jupiter.

What's the ultimate agile BA technique? Paper Prototypes

 According to the meetup group we played with the other day it is paper prototypes.  

(You can see the whole list of techniques we discussed here, and the game we used to create the list here.)

Ideas for DarkPatterns.org homepage

What we the criteria that got it up as the champion technique on the night?

• You can test business ideas with them
• Paper prototypes can be built quickly and edited just as quickly
• They can be disposed of equally quickly and with less fanfare than the deletion of an exquisitely crafted Balsamiq wireframe
• Pictures tell a thousand words
• Screen sketches capture key business data
• Screen and flow sketches capture important process and interaction flows
• The combination of the above help you discover edge cases
• A paper sketch doesn't get you caught up on details of design or UX

Here are some handy resources on Paper Prototyping

• Wikipedia page
• A case study on designing a University web application
• An online book - Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces
• A handy Youtube clip showing someone do it particularly well (embedded below)

Analyzing without a License

I've posted about him before, but if you're not reading Jeff Atwood's Coding Horror blog, you're really missing out. Today's post is perfect. There are several lines that really stuck with me, here is one of my favorites:

Please don't advocate learning to code just for the sake of learning how to code. Or worse, because of the fat paychecks.

Over a year ago, in response to one of my posts here on the site, someone told me that if I didn't like how developers did their jobs, I should go out and write the code myself. The idiocy of the statement just astounded me. Now, here is one of the premier programmers in the world, backing me up.

You see, learning to code is very similar to business analysis or project management. It may sound like something that anyone, given a weekend and a 'Teach yourself XXXXXX in 24 hours" book can do, but learning a programming language does not make you a developer, nor does learning the concepts behind business analysis or project management make you either one of those professions.

My biggest concern is that most everyone should not learn these skills. To quote the movie Tommy Boy:

Tommy: I can get a good look at a T-bone by sticking my head up a bull's ass, but I'd rather take a butcher's word for it. 

Most business people shouldn't need to know more than the basics about technology and they definitely shouldn't know enough to try doing project work, at least not beyond being a SME. Its not that these people are dumb, far from it, but their expertise is in running the business. Those of who work on projects, developers, analyst and PMs, have our areas of expertise as well. Some of the skills overlap, but lots more do not.

With my background as an analyst, I do tend to see everything through that lens. When I'm in a meeting to discuss a recently discovered problem or opportunity and the first thing I hear is someone say, "What we need to do is..." I find myself trying to breathe deeply and not lose my temper. Starting at the solution without really getting a firm understanding of the problem is one of the worst mistakes you can make when doing analysis. It is a very easy failure to make, one I see analysts make regularly, but one that you have to train yourself out of in order to be the best at what you do.

Be an expert at the things you're really good at and leave everything else to the experts in other fields. When we work together as a team of experts in our own field, we do better than a bunch of amateurs who don't know enough to know they don't know what they're doing.