You are here...

Sent from my BlackBerry® wireless device

Posted via email from The Ginger Mumbly

You are here...

Sent from my BlackBerry® wireless device

Posted via email from The Ginger Mumbly

You are here...

Sent from my BlackBerry® wireless device

Posted via email from The Ginger Mumbly

You are here...

Sent from my BlackBerry® wireless device

Posted via email from The Ginger Mumbly

Hello Mum - Kitchen/Living Room

Sent from my BlackBerry® wireless device

Posted via email from The Ginger Mumbly

Hello Mum Kitchen

Sent from my BlackBerry® wireless device

Posted via email from The Ginger Mumbly

Hello Mum - Garden

Sent from my BlackBerry® wireless device

Posted via email from The Ginger Mumbly

Software isn’t Cake or What the Cyenfin Framework says about the Kind of Plans you Should Make for Software Development

Coming back to the Cyenfin framework, it’s very instructive to ask what sort of plan you might expect in the different quadrants.  Let’s start in the simple space.  What sorts of things happen in the simple space? Cake baking.  So what would a plan for cake-baking look like?  Well, it would probably look a lot like a recipe.  You assemble a bunch of resources, you go through a bunch of steps, you get a cake out of the end of it.  One really important thing to note here is a really straight-forward relationship between time, money and value.  If you’re someone who wants a cake.  You can go to someone who can make cakes and they will tell you how long and how much it will cost to make a cake.  At the end of it, you will reliably get a cake if you pay them what they ask.  Also, you won’t be in any doubt about the value of cake.  Everybody likes cake. So in the simple space, plans basically look like this:

Time + Resources [EQUALS] Understood Value

So a plan in the simple quadrant of the Cyenfin framework breaks down like this:

1)      There is thing that we all understand the value of e.g. Cake

2)      If we deploy certain amounts of time and resources (ingredients, a chef) we will get cake, this is pretty much guaranteed.

3)      Here is a break-down of all the time and resources that we will need to get the cake.

4)      At the end of this process, you will get cake.  And everybody likes cake.

 

What happens in the second quadrant of the Cynefin framework?  Well, this is where the problem is well-understood, but only by professionals. If you hire the right people then they will solve the problem for you.  In this space are people like mechanics repairing a car, architects  designing and managing the building of a house.  The interesting thing is that in this space, pretty much as in the simple space, there is a straight-forward relationship between the effort put in and the value that you get out of it.  If you pay an architect to build you a house.  Most of the time, you get a house out of the end of it.  If you pay someone to fix your car, most of the time you get a repaired car out of it. But sometimes things go wrong.  And we get really furious when they do go wrong because we have an expectation, as with baking a cake of a direct relationship between the time and resources that we put in and the value that we get out.  We understand moving into our new, specially-built house, or driving our car when it’s repaired.  So in the complicated quadrant of the Cynefin framework we can say:

Time + Resources [Sort of Equals, most of the time, or they’ll be trouble] Understood Value

So what happens in the third quadrant of the Cyenfin framework?  The complex.  Well, this is where the model breaks down.   Let’s look at our cake planning model.  And try it for some software e.g. a website:

1)      There’s this thing that we can’t really describe, that some senior people think might be a good idea.

2)      We can make our best guess at how long it’s going to take and what’s needed,  but we might be wrong.  In fact we probably are wrong.

3)      We’ve been given a budget and a deadline, so we’ve made up a detailed timeline that shows we’ll deliver this thing by a certain date.

4)      At the end of this process, you might get something, and somebody might like it, or they might not.

This is the source of the problem, this is the absolute root of the problem.  The planning model that works in the simple part of the Cynefin framework and that sort of works in the complicated part of the Cynefin framework hardly works at all when you move over to the complex space because in the complex space:

Time + Resources [Absolutely Does Not Equal] Understood Value

Rather in the complex space:

Time + Resources [Is roughly Equal to] Something which might be of value

But why? Why is the value of architecture and car repair mostly understood whilst the value of software is so elusive?  Well, for a start, architecture, and even car repair have been around for generations (let’s say 15 generations for architecture as a profession, 5 for car repair).  Software development has been around for perhaps 2, web development for less than 1. Cake? How long has cake been around? A long, long time.

Thinking about things in this way is very instructive because it explains a lot of the behaviour of people who are so focussed on the provision of detailed plans, and on tracking progress through a plan.  Such people are firmly of the view that software development is in the complicated space – like architecture or car repair, and that the value of the software that’s being development is well-understood.  This is why they focus on detailed plans and focus on delivery against a plan, because in that kind of situation, there is a direct relationship between time and resources spent, progress against the plan and value delivered.

Similarly, the lack of a straight-forward link between value and time and resources in the complex part of Cynefin framework is exactly why people working on software projects. People who understand the nature of the software projects they’re working on, insist of a large slew of what have come to be known as Agile practices.  They insist on early and frequent releases, vertical slices (where a little bit of the solution is developed end-to-end), minimum marketable features and regular review and reprioritisation of what’s left to do based on feedback from customers and users.

It also explains why people with a “complicated”view of the world, who assume that the relationship between time, resources and value is straight-forward, think such value-testing antics are a waste of time.  It is a waste of time to keep checking on the value of cake.  If the recipe is known to be reliable, and so are your staff, it would be a waste of time to do a small run before you do a large one.  It would be a waste of time to then go to a focus group of cake lovers and check that they like cake.  Everybody likes cake.  Software isn’t cake.

Posted via email from Agile Lab Blog

Software isn’t Cake or What the Cyenfin Framework says about the Kind of Plans you Should Make for Software Development

Coming back to the Cyenfin framework, it’s very instructive to ask what sort of plan you might expect in the different quadrants.  Let’s start in the simple space.  What sorts of things happen in the simple space? Cake baking.  So what would a plan for cake-baking look like?  Well, it would probably look a lot like a recipe.  You assemble a bunch of resources, you go through a bunch of steps, you get a cake out of the end of it.  One really important thing to note here is a really straight-forward relationship between time, money and value.  If you’re someone who wants a cake.  You can go to someone who can make cakes and they will tell you how long and how much it will cost to make a cake.  At the end of it, you will reliably get a cake if you pay them what they ask.  Also, you won’t be in any doubt about the value of cake.  Everybody likes cake. So in the simple space, plans basically look like this:

Time + Resources [EQUALS] Understood Value

So a plan in the simple quadrant of the Cyenfin framework breaks down like this:

1)      There is thing that we all understand the value of e.g. Cake

2)      If we deploy certain amounts of time and resources (ingredients, a chef) we will get cake, this is pretty much guaranteed.

3)      Here is a break-down of all the time and resources that we will need to get the cake.

4)      At the end of this process, you will get cake.  And everybody likes cake.

 

What happens in the second quadrant of the Cynefin framework?  Well, this is where the problem is well-understood, but only by professionals. If you hire the right people then they will solve the problem for you.  In this space are people like mechanics repairing a car, architects  designing and managing the building of a house.  The interesting thing is that in this space, pretty much as in the simple space, there is a straight-forward relationship between the effort put in and the value that you get out of it.  If you pay an architect to build you a house.  Most of the time, you get a house out of the end of it.  If you pay someone to fix your car, most of the time you get a repaired car out of it. But sometimes things go wrong.  And we get really furious when they do go wrong because we have an expectation, as with baking a cake of a direct relationship between the time and resources that we put in and the value that we get out.  We understand moving into our new, specially-built house, or driving our car when it’s repaired.  So in the complicated quadrant of the Cynefin framework we can say:

Time + Resources [Sort of Equals, most of the time, or they’ll be trouble] Understood Value

So what happens in the third quadrant of the Cyenfin framework?  The complex.  Well, this is where the model breaks down.   Let’s look at our cake planning model.  And try it for some software e.g. a website:

1)      There’s this thing that we can’t really describe, that some senior people think might be a good idea.

2)      We can make our best guess at how long it’s going to take and what’s needed,  but we might be wrong.  In fact we probably are wrong.

3)      We’ve been given a budget and a deadline, so we’ve made up a detailed timeline that shows we’ll deliver this thing by a certain date.

4)      At the end of this process, you might get something, and somebody might like it, or they might not.

This is the source of the problem, this is the absolute root of the problem.  The planning model that works in the simple part of the Cynefin framework and that sort of works in the complicated part of the Cynefin framework hardly works at all when you move over to the complex space because in the complex space:

Time + Resources [Absolutely Does Not Equal] Understood Value

Rather in the complex space:

Time + Resources [Is roughly Equal to] Something which might be of value

But why? Why is the value of architecture and car repair mostly understood whilst the value of software is so elusive?  Well, for a start, architecture, and even car repair have been around for generations (let’s say 15 generations for architecture as a profession, 5 for car repair).  Software development has been around for perhaps 2, web development for less than 1. Cake? How long has cake been around? A long, long time.

Thinking about things in this way is very instructive because it explains a lot of the behaviour of people who are so focussed on the provision of detailed plans, and on tracking progress through a plan.  Such people are firmly of the view that software development is in the complicated space – like architecture or car repair, and that the value of the software that’s being development is well-understood.  This is why they focus on detailed plans and focus on delivery against a plan, because in that kind of situation, there is a direct relationship between time and resources spent, progress against the plan and value delivered.

Similarly, the lack of a straight-forward link between value and time and resources in the complex part of Cynefin framework is exactly why people working on software projects. People who understand the nature of the software projects they’re working on, insist of a large slew of what have come to be known as Agile practices.  They insist on early and frequent releases, vertical slices (where a little bit of the solution is developed end-to-end), minimum marketable features and regular review and reprioritisation of what’s left to do based on feedback from customers and users.

It also explains why people with a “complicated”view of the world, who assume that the relationship between time, resources and value is straight-forward, think such value-testing antics are a waste of time.  It is a waste of time to keep checking on the value of cake.  If the recipe is known to be reliable, and so are your staff, it would be a waste of time to do a small run before you do a large one.  It would be a waste of time to then go to a focus group of cake lovers and check that they like cake.  Everybody likes cake.  Software isn’t cake.

Posted via email from The Ginger Mumbly

Keith Jones on Consciousness

The consciousness that we experience as "ourselves" is a defence system against the intrusions of other people but in life or death situations our good angel shoves us aside, slams things into slow motion and does its damnedest to rescue us.

If improvisers were content to be "Just average" and go with the flow this good angel could operate even when there wasn't a dire emergency.

Keith Johnstone - Impro for Beginners

http://www.amazon.co.uk/gp/product/0571190995?ie=UTF8&camp=3194&creative=21330&creativeASIN=0571190995&linkCode=shr&tag=theginmum-21&qid=1345884308&ref_=sr_1_1&sr=8-1

Posted via email from What Stringer's Reading

Keith Johnstone on Trying

If I gnawed my pencil and crunched up my face as if in agony my teachers would perceive me as trying.  This strategy kept me safe but it didn't teach me anything and it carried with it the risk that thinking might become a forced activity, never again to be experienced as effortless.

Keith Johnstone - Impro for Storytellers 

http://www.amazon.co.uk/gp/product/0571190995?ie=UTF8&camp=3194&creative=21330&creativeASIN=0571190995&linkCode=shr&tag=theginmum-21&qid=1345884308&ref_=sr_1_1&sr=8-1

Posted via email from What Stringer's Reading

Threads

The threads snap when we realize that the performer is no longer involved in anything except a sort of bluff, and that there'll be no rabbit coming out of that particular hat. Hence we're likely to leave when a player completes or repeats an activity.

Keith Johnstone - Impro for Storytellers
Sent from my BlackBerry® wireless device

Posted via email from What Stringer's Reading

Beginning

Yo-yoing between arrogance and humility when you're a beginner is as inevitable as falling off when you learn to ride a bike.

Keith Johnstone - Impro for Storytellers
Sent from my BlackBerry® wireless device

Posted via email from What Stringer's Reading

Late and Over-Budget Version 0.1

LateAndOverBudgetV0.1.pdf Download this file

Late and Over-Budget, very first version as a PDF, already with the front rubric, 18 pages.  I'm very interested to hear *any* feedback.

Posted via email from Agile Lab Blog

The Green Shepherd’s Bush 172 – 174 Uxbridge Road, W12 7JP London Wednesday 5th September 8pm

Posted via email from The Ginger Mumbly

Updated CV - cleaner format and honest interests

CVAugust2012.docx Download this file

Posted via email from Mark Stringer's Job Search Tumblog

You are here...

Sent from my BlackBerry® wireless device

Posted via email from The Ginger Mumbly

You are here

So many, I had not known death had undone so many...
Sent from my BlackBerry® wireless device

Posted via email from The Ginger Mumbly

Late and Over-Budget: Why is software in the complex part of the Cynefin framework?

Why is software development in the complex space of the Cynefin framework?  Why can’t you hire professionals who’ll do a good job and deliver it on time? There are a whole bunch of reasons.  We’ll just visit a few right now.

Shifting Sands

 Any software development isn’t going to happen on just one piece of technology.  It’s going to happen on a “stack” of technologies.  Any complicated piece of software is going to at least involve an operating system, a database solution a front-end programming language and a back-end programming language.  All of these are changing all the time.  Beyond this the hardware that runs this software is changing all the time.  As an example, I spent two years working on a web-based platform for academic publishing.  During that time the iPad came out.  This created an expectation on the part of the majority of our end-users – American undergraduate students - that everything they read should be available on the platform: today.  But reading on the iPad changed almost everything.  The licensing model, the required look and feel, the software capabilities that we needed in the team, the number of UI Designers we needed. This is really pedestrian, but it needed to be pointed out, and argued about a lot longer than you’d think. Developing on the iPad meant we needed iPads!!! And there was no organisational structure in place that could provide us with this kind of cool hardware.  For the first twelve months all development happened either on private iPads or iPads bought against regulations on company credit cards.

Nobody knows what they want

Expressing software requirements in natural language and pictures is a vague business fraught with difficulty.   What the people funding a project want aren’t the same as what the customers want.  What the customers and the people who are paying for it want might not be the same as what the regulators want and what is most sensible, maintainable and supportable from a technological point of view.  Collecting requirements is a bun fight.  What makes it even worse, the best know ways of collecting requirements – the good practices and approaches that you’d want to be tending towards if you were trying to be professional are completely the opposite of what people who don’t know much about developing software, and actually, a lot of people who do, think it should be.  Iterative methods work best. But intuitively, most people believe deep in their bones, that the best way is to try to detail absolutely everything that they want in a specification document right at the beginning of a project.

Few people know the value of what they want

The people who are initiating a project rarely know what the value is of what they’re asking for.  What about regulatory projects you might ask?  What about projects which meet a legal requirement?  Well first of all, these are a very small proportion of the projects that ever get undertake, secondly, even in these kinds of projects, what’s precise required to fit a regulation and what the cost of not meeting it will be is rarely understood.

Most projects get kicked off because of some perceived business value, because somebody manages to persuade someone who has control of the purse strings that a project might be a good idea.  But the exact nature of this value is rarely known.  This shouldn’t be a surprise because most businesses are skirting around the edge of the “chaotic” part of the Cynefin problem space, if they haven’t been pitched right into the middle of it.

Again, the intuition to deal with this is completely the opposite of what actually works.  If you’re exploring an unknown space, the best way to do this is a little bit at a time – iteratively.  The basic, basic, Agile approach, make a list of things that you want to do – do the most important ones from a business point of view, get something working, let everybody have a look at it, play with it and then decided what comes next.

Software development discovers value

One account of what designers are doing is that they are “discovering new value”.  In my experience this happens all the time with software development.  Once stakeholders and users see actual working software they see values and opportunities that they couldn’t or certainly didn’t imagine to be possible before they saw it working.  The weird thing is that this is very often perceived as a problem with a project.

We’re not Chinese

I don’t think this is racist.  Although some of my super right-on friends have suggested that it might be. If you can tell me how it is racist, then please write to me and tell me.  Even if it is racist, I’m not sure I care, because it’s still funny.  The “not Chinese” thing comes from this little exchange in a Goon show.

Bloodknock: You Chinese think of everything!

Eccles: But I’m not Chinese!

Bloodknock: Then you’ve forgotten something!

These are what might be described as “forehead slapping moments.”  The moment when you realise that making changes in one system is going to break almost everything that happens in another system.  If you’re not Chinese, you’ve probably forgotten something.  Actually if you are Chinese, you’ve probably forgotten something as well.  Small changes in one system can require huge changes in another system.  It’s in the nature of software systems that are being built on and built on that they get more and more fragile.  The new bit that you’re adding to them might, and actually very often does, push them over the edge.

Software is in the complex space because of the high level of Discovered Demand

In books like “Freedom from Command and Control” John Seddon draws a distinction between two kinds of work is done in the systems that he examines – Value Demand and Failure Demand.  Value demand is work that delivers the stuff that people want.  In the examples that John Seddon uses in his book this is stuff like having a plumber fixing the heating system in a council tenant’s flat.  Failure demand is fixing things that have gone wrong with the value demand.   Again in the example John Seddon gives, this is work like having to deal with calls from irate customers because the plumber didn’t turn up when he was supposed to, or did turn up, but was unable to fix the problem because he didn’t have the requisite part. I would argue that the work that Seddon is talking about is largely in either the simple space (arranging appointments) or the complicated space (fixing heating).  The big difference between this kind of work and software development is that in software development there is completely different kind of demand that consistently rears its head – discovered demand.  Stuff that the customer realises that they want half-way through the process – because as we’ve discussed above, they don’t really know what they want, nor the value of what they want until they see it. Stuff that the software developers realise they’re going to need half-way through the process.

Coming back to our central theme of “Late and Over-Budget” the weirdest thing about “discovered demand” is that it is almost always treated by developers and stakeholders as failure demand.

Posted via email from Agile Lab Blog

Late and Over Budget: The Cynefin Framework - We Are, After All, Not Professionals

Cynefin is a Welsh word meaning something a bit like environment.   But meaning environment in all the different ways that you could mean environment, not just the physical environment, but also the social environment, who you know, who you talk to.  Who you can rely on in a crisis.  All of that stuff.  The Cynefin framework is a pretty simple concept, but I think it leads to some really powerful understanding of why almost all software development projects are late and over-budget.  What the Cynefin framework maps out is four different kinds of problem space that we might be in in a work environment.  When I used to work in a research lab, I used to work for a guy who had an amazing talent for being annoying.  In any given situation, you could rely on him to be annoying.  This was actually a very useful talent for someone in a research lab.  One of the questions that he invariably would ask at the end of a presentation of some new-fangled idea would be – “what problem are you solving?” If you were the person presenting your new fabulous work which you were getting all excited about, you would probably find this annoying.

The Cynefin framework asks a similar kind of question.  It asks “what kind of problem” are you solving?  “What kind of answer are you looking for?”.  The Cyenfin framework puts these kinds of problems and answers in four buckets – simple, complicated, complex and chaotic. 

So what is a simple problem?  A simple problem is one where the problem is well-understood, then methods to solve it are well-understood, also they are easy to understand.  They work so reliably that almost anybody who is awake and moderately well-educated can follow them.  As an example of a simple problem-space you could talk about baking a cake.  If you have an oven that works and you have access to a recipe and the right ingredients and you follow the recipe, you’ll get a cake out of the end of it.  So a simple problem is one where there’s a recipe and anybody can follow it.  Sometime I think there are very few problems that are simple.  I’ve seen interviews with Delia Smith, the hugely successful TV cook, where she explains that the way that she gets her recipes to work reliably is that she tries them in lots of different ovens.  My suspicion is that genuinely idiot-proofing any problem space so that “anybody” can follow a set of instructions without fail, is harder than most people might think.  But anyway, on to complicated problems.

Complicated problems are problems that can be solved, but in order to solve them, you need a professional who has some come complicated training.  So a complicated problem is one where there is an answer, the problem can be solved, but not just anybody can solve it.  You need a professional. Lots of things fall into the category.  I’m always fascinated by the comment by Penn Jillette that the field of conjuring and magic is like accountancy – anybody could find out how to do it, it isn’t a secret, it’s in books.  They just can’t be bothered.  So I would categorise lots of problems as being in this space.  Anything where there is a course or a book or a master that you can go and sit at the feet of.  This is where the professions hang out in the Cynefin framework, but it’s also where the trades hang out.  Painters (the non-artistic kind) and decorators, plumbers and electricians, they hang out in this space.  It is important to remember that this is where the professionals hang out – in the space where you can go read a book, sign up for a course or sit at the feet of a master to learn. And what do you learn when you go on the course, read the book, sit at the feet of the master, turn up to a meeting of the magic circle or go to a professional conference?  You learn “good practice”, you learn the best way that people in your profession or trade know of to solve a problem.  So the complicated space is one where there is good practice.  There’s a way that a way of doing things that pretty much everyone is agreed is a good way.  The reason that I’m labouring this point is because we’re about to step over the line from the complicated world, into the complex world.

In the complex world, there aren’t any right answers like there are in the simple and complicated spaces.  In the complex problem space, the very best you can hope for are “approaches”.  In the complex problem space, you can’t follow a recipe that will solve your problems.  In the complex problem space, you can’t even do a length professional training program so that you can solve your problems or call a professional, someone in that’s done this kind of training.  What makes things even worse is that in this complex space, there is no shortage of people claiming that the problem space isn’t complex, but in fact either merely complicated (all you have to do hire one of their professionals, or sign up for one of their professional courses) or even simple! Buy our product, follow these steps and all your problems will be solved. For those of you who already know something about Agile methods, as I’m writing this I’m realising that this is what makes the whole Scrum Master Certification program (full disclosure, I did the course, but I’ve resisted paying up to “renew” my certification) so simultaneously shameful and successful.  There is clearly huge amounts of money in selling simple and complicated solutions to complex problems.  That’s one of the other features of the complex space.  As if the problems that you were dealing with weren’t bad enough, there a whole series of other difficulties that come from the complex space not being the simple or the complicated space, but many many people desperately wanting it to be.  The complex space is where well-meaning and genuinely useful consultants hang out,  it’s also where cult-leaders, psychics and other charlatans hang out who are prepared to prey on the desperate human need for certainty.

From that little aside, you might have guessed, yes, this is also where software development hangs out in the Cynefin framework.  Software development is done in a problem space where there are emerging approaches, but there are lots of them and none of them are anywhere near one hundred per cent effective.  It’s also done in a problem space where the people who are suffering from these problems desperately want to be told that there problems do have an answer.

Finally, on our way around the Cynefin framework, we come to the chaotic space.  This is the space where people aren’t even sure what the problems are.

Posted via email from Agile Lab Blog

Gig: Tuesday 18th September The Rhythm Factory, 16-18 Whitechapel Rd, E1 1EW 8pm - FREE!!!

Looking forward to this now that I'm an East End boy.  I'll be able to walk home from this gig!!!

Posted via email from The Ginger Mumbly

Gig: Tuesday 11th September The Horatia, 98 - 102 Holloway Road, London N7 8JE, FREE!!!

Come along - this should be an awesome gig.  Put it in your diaries.

Posted via email from The Ginger Mumbly

August 2012 CV

AugustCV.doc Download this file

Posted via email from Mark Stringer's Job Search Tumblog

Had enough #olympics ? I'm on here tonight - 8pm

Free Comedy!!!
The Ballyhoo Club
38 New Oxford Street
London

Nearest Tube - Tottenham Court Road or Holborn
Sent from my BlackBerry® wireless device

Posted via email from The Ginger Mumbly

People...

People have a natural tendency to bite off more than they can chew. We are naturally optimistic. But when people do this they easily become overwhelmed and then nothing is accomplished in the end.

Game Storming - Gray, Brown and Macanufo
Sent from my BlackBerry® wireless device

Posted via email from What Stringer's Reading

Business Meetings

Having a business meeting without artifacts and meaningful space is like meeting blindfold with your hands behind your back. Yes you can do it, but why would you want to?

Game Storming - Gray Brown and Macanufo Sent from my BlackBerry® wireless device

Posted via email from What Stringer's Reading

Losing sight of the big picture

A team can easily lose sight of the big picture when it is narrowly focused on a demanding task. The task itself becomes the big picture, crowding other considerations out of the frame. To counteract this tendency, smart managers supply reality checks by exposing their people to tbe perspectives and practices of other organizations.

Paul Levy - The Nut Island Effect http://amabilis.debating.net/content/resources/debaters/documents/nutisland.pdf

Posted via email from What Stringer's Reading

The Nut Island Effect

With no external input on practices and operating guidelines, the team begins to make up its own

rules. The team tells itself that the rules enable it to fulfil its mission. In fact, these rules mask the deterioration of the team's working environment and deficiencies in the team's performance.

Paul Levy - "The Nut Island Effect"

Posted via email from What Stringer's Reading