Search This Blog

31 May 2012

Where are we going? How do we know it's a good place?

More Snowden on Complexity. In two parts.
Thanks Kallokain,


  • If you don't understand something you can't scale it.
  • Apprenticeships are the path to mastery
  • Analysis and synthesis aren't either/or
  • Premature convergence can be a problem
  • Design thinking isn't a best practice - don't start with the problem, seek serendipity.
  • Soft systems and visualisations (Checkland)
  • Exaption is cool
  • Don't be comfortable

23 May 2012

Competing values

In 2007 I came across this model by Cameron and Quinn (1) describing aspects to an organisation that shape how you might focus your management style.  The essence of the model is open versus hierarchical control models and an internal versus external focus. Cameron and Quinn's model then gives us four cultural domains to consider;
  • Clan; Open culture, internal focus
  • Bureaucracy; Hierarchical and internal focus
  • Market;  Hierarchical, but market focused
  • Adhocracy; Open culture and  market focused

What do these domains mean?

The Clannish organisation, like the local family run restaurant, where people come together more for the social interaction that anything else. The controls are light and open because in this context people are intrinsically motivated to come to work for the reward of social interaction. 

It sounds nice until you realise that the team are very much focused on themselves and paying attention to changing market conditions, and even customers isn't really on their radar. Being a staff member is fun, but at the end of the day this business is at risk to competitors and to changing market conditions. This may have been the organisational style of the media industry in decades past, and is still the cultural style at some educational institutions.

Bureaucracy is much maligned, and in the context of this model we can see why; people are not in control of the work they do, and it is internally focused rather than on the market or customers.  

Bureaucracy makes sense in some circumstances, and our history shows us where; the people with power have accumulated so much they need someone to guard it.  But the problem that brings is you have to arm the guards and they might want to take over themselves.  The answer is to separate out logistics from the armed forces. Neither can operate without the other, and the structures and command culture reduce the risk of collusion and a power upset.
Where might bureaucracy still remain a viable strategy in our world? Wherever people with power want to stop others from usurping it.

The Market model is where the customers, guided by strict operating protocols dive how we operate. The finance market are an interesting example of this. My most recent encounter was a discussion about internal charging for services.  A system like this helps focus energy on unified goals.

In Cameron and Quinn's thinking this was still also process and hierarchy controlled operating model, but depending on the execution, economic systems like charge-out models can be implementations that might sit on the northern sector of the control-open axis.

The adhocracy is a rare model, because traditionally as organisations get bigger they fall into the model of defending the status-quo. The adhocracy style can be found though, in high performing organisations and in smaller nimbler organisations like start-ups.

This model can be particularly well observed in the open space movement where people come together, try experiments for a few hours or days and then walk away with new value having been created.  The adhocracy is paying attention to the market and has an open culture.  It is the model that we typically aspire to when citing case studies of successful organisations.

In case you are wondering this is the target for people in the lean and agile movement. How can we take our teams on a journey from bureaucracy to adhocracy? What are the way-stations along the way?

Further thinking

There are a number of ideas that come from thinking about this model.

The first I came up with was "What are the environmental models that suit one quadrant over another?"  I could come up with an example for everything, but think I may have been forcing the issue.  It is eminently possible that in a post-industrial economy everyone should be directed to the top right quadrant as soon as possible.

The second question I thought of was when I participate in organisational change, what options and tools do I have, and what techniques can I employ on the journey to adhocracy.  Cameron and Quinn's work gives some insight here, but I'd like to have a more context specific set of examples I can access.

The third question is "To what degree are we aligning (or not aligning) our operating models to our cultural models?

The authors have some of the answers, but we need to explore and discuss these ideas more.  I am keen to hear your thoughts on this.

(1) Cameron Kim S and Quinn Robert E, "Diagnosing and changing organisational culture; based on the Competing Values Framework" Addison Welsey Publishing Company Inc, 1998.

22 May 2012

Ultimate BA technique battle video

Stephan Dekker who runs an ALM group in Melbourne took a video camera to our BA technique game and has posted it online. The first part is below, Click through to the ALM site if you want to watch all of it (about 60 minutes.)

in 6 x 10-15 minute increments

I reckon we should put these techniques onto trump cards like this one...

18 May 2012

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.

17 May 2012

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.)
Idea for homepage
Ideas for 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)

16 May 2012

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.

15 May 2012

Project estimating: What could possibly go wrong?

"Are we born to be optimistic, rather than realistic? Tali Sharot shares new research that suggests our brains are wired to look on the bright side -- and how that can be both dangerous and beneficial."

10 May 2012

Learning, Video Games and Photoshop

I regularly read Rands in Repose, and today's article was nothing short of awesome. If you're not a Rands reader, I highly recommend you become one, if for no other reasons, for bits like this:

Photoshop’s goal isn’t entertaining unless you think the national pastime of bitching about Photoshop is a sport. Photoshop has no points or leaderboards because Photoshop is a tool and the perception of tools is that you must be willing to supply blood, sweat, and tears in order to acquire the skills to become any good at using them.
Make a list. Tell me the number of applications you use on a daily basis where there is a decent chance that you’ll end up in a foaming at the mouth homicidal rage because of crap workflow, bad UI, and bugginess. Is Photoshop on that list? Yeah, me too.

Photoshop isn't one of my regular tools, but the Mac image editing app Pixelmator absolutely is. Why? Two reasons... first, its slightly cheaper and second, it doesn't make me want to gouge my eyes out every time I open it. No, I'm not a professional image editor, so I don't need Photoshop, but the few times I've tried to use it, I run screaming back to Pixelmator every single time.

I bring all this up because I feel that programs like Photoshop just need to die. Die a horrible death. In a fire. Then get its ashes buried in the deepest part of the ocean. Never do we want to involve ourselves with something that makes our users want to hate our product. This is a sign of a product, and the project that creates it, gone wrong.

Oh, and before I forget, there are a few other apps that fit on my 'list' as well. Naming them all would take too long, so I'll list categories instead, but I bet your list looks a lot like mine:

  • Microsoft Office
  • Project Management apps
  • Requirements Management apps
  • Defect Tracking apps
  • Testing Automation apps
Pretty much, if its a tool used by project people, I'm probably going to hate it. That's sad, because in the 10.5 years I've been doing this, it hasn't gotten any better.

(Yes, there are some fine tools out there; I just don't get to use them, and even those I have played around with that were not terrible still made me want to gouge out my eyes at least once a day because of some insane thing it did.)

What's on your list?

Join us and blog at Better Projects

It's time for us to refresh the tone and content here and so we would like to hear from people who would be interested in joining Ted, me and the occasional other to blog here.

The rules are pretty simple; share what you are learning as you grow in your role.  Get in touch if you are interested and we can talk more.

3 May 2012

Being agile; not so important after all

Being agile is not always important.

The interwebs have a thing going on in recent months about the difference between doing agile and being agile.

There are a bunch of agile things that correlate with positive business outcomes, but they aren’t universal are they?

I work at a university. What we do in the IT Department is important but it is barely core business.  Core business for universities comes in three forms; Innovation borne out of research,  student experience, and subordinate but critical to that; teach experience.

A side note on that topic: Research and student speak for themselves. That’s where the money comes from, either directly or through government grants.  Teacher experience is worth noting because most teachers in universities are working at below their market value.  For example, all of the teaching staff related to ITC that I have met at Swinburne are smart, pragmatic and well informed in our industry. They could all be earning much more as consultants and industry practitioners. But they sacrifice earning more money in order to be able to participate in the shaping of the industry both through research and through teaching students.  There is clearly consideration in that.

Back to being agile.  What can the IT Department do to affect these three aspects of the business? Yes there is a place to play in making commodity systems (mostly procured, not built) work.  And yes, if they don’t work it can be a big deal.  So you need to be capable at managing commodity services.

Where does being agile play into that?  Where is the need for responsiveness to market conditions? How does an effective IT department affect enrolments or staff engagement?

It doesn’t really does it?

Yes, it will. When traditional education starts to feel the effects of the current and next waves of industry disruption technology will matter.  But it probably won’t come from the OT Department. Instead the fancy innovations will be business led, often with IT partners outside the organization.

IT will still be important, but it will become a hygiene factor rather than something that gets discussed at the University Council.

And so, while being competent matters, being agile doesn’t.  

So why pursue agile practices?

Perhaps because they might become table stakes for being competent.  Perhaps because IT will partner with the business in innovation and industry disruption (They are probably as good if not better than many IT partners universities work with.) Perhaps because, as a developer led movement the agile values and ways of working are imbued with respect for the workers.

Perhaps because, once you understand it, you realise that working in more traditional command and control modes is fundamentally stupid. Enabling people to do their best is a much more savvy way t do business than managing to the lowest common denominator, or trying to manage away all risks through mandated methods.

2 May 2012

The ULTIMATE business analysis technique

Agile Business Analysts

A Melbourne community meet-up group 
invite you to

Fight! The ultimate BA technique 

Tuesday, May 8, 2012, 6:00 PM 
Microsoft office, LVL5, 4 freshwater place, Melbourne 

At this month's Agile BA meet-up we share our favourite techniques and search for the ultimate technique - that's right; the one method to rule them all!

We will do this via a game. Teams will form and share their favourite techniques and methods, with examples of where they have been successful.

Teams will then pair off against other teams and present their favourite methods and challenge the other team with counter examples or questions. The rest of the room vote on the winner. We repeat this in a series of four to five rounds until a winner is found.

Along the way we hear lots of examples of where analysts have deployed successful techniques and hear what situations they may not work in as well.

Learning Objectives 
This is a fun interactive way to review a broad range of methods and techniques, to talk about them, and hear stories of when they have been successful in the field.

You bring
Your variety of experiences, an inquisitive mind and a pen and paper. Post it notes would also be good 

Audience level 
All levels of experience are welcome. Diversity of the whole room is what is most important. The call to action