Search Results for: zachman

Towards Next Practice EA

by

A few weeks ago, @Cybersal and I met with @snowded to talk about enterprise architecture. He showed us a graph of the Complex Space, whose two dimensions were Evidence and Consensus. Dave has since posted a version of this graph on his blog.Source: D…

The value of lenses

by

image

TOGAF

Zachman

Agile

Scrum

Kanban

XP

User centred design

Lean

Lean startup

Service design

Design thinking

Behavioural economics

What do these things have in common? These are all things I’m either interested in, read a lot about, studied/got certified in, or use/have used in my work.

The other thing that they have in common? None of these things are The answer.

I like to think of each of the list above as lenses that help you view problems in a different way, using them individually or in combination can help inform your view of the problem space and give you greater options when looking for solutions.

It is very tempting for us to find a methodology or framework that resonates with us at a point in time (for me back in 2006, it was Scrum) and start to see everything through that particular lense.

There is a danger in relying on one lense too much and that in focusing on the use of one lense we become myopic, concentrating on using our chosen methodology/framework/process without understanding its application in the context of the wider problem space.

Example:

A few months ago I attended the excellent @SyncNorwich monthly conference. One speaker gave a talk about using Kanban on a software development project. It was a really informative talk about using Kanban on a project, the team seemed to work really well, the ‘product owner’ seemed happy and they shipped early and often. It all sounded great until the speaker put up a slide showing the tiny amount of usage/sales of the product.

I was left with the conclusion that using the lense of Kanban had enabled the team to deliver the wrong thing really really well. The weak link in the chain was whatever design process the Product Owner (and his team) used to feed into the development process.

I raised this conclusion with the speaker, he didn’t seem to think it was his problem (or Kanban’s). The fact that the organisation he worked for had ploughed (i’d estimate) several hundred thousand pounds into developing products that customers didn’t use, didn’t seem to register as a problem. His team had delivered what his customer (the Product Owner) required using Kanban, worrying about what the real customer actually wanted wasn’t even on his radar. The net result was the customer’s needs weren’t met. Whatever lense we decide to use the needs of the customer should always be in plain sight.