Hi, my name is Chris Matts, I am kind of a business analyst- project manager- program manager- whatever you want to call it working in the Agile space. I’m slightly different in Agile in that I tend to use the Agile tools rather than sell them and in terms of recently, I’ve been working on a book with Olav Maassen and Chris Geary called Commitment.
2. We’ve heard you name mentioned in connection with BDD. Could you explain that?
Ok. So, many years ago Dan North had a stroke of genius when he applied neurolinguistic programming to test- driven development, and what he realized was that the language being used in test- driven development didn’t really work so well, it was assert that, this does this. So what Dan said was “instead of assert that, it should say the system should”, when he was explaining it to me I said “well, that’s really about business analysis and specification rather than testing”. Anyway, Dan was showing me how to do BDD with mock objects and as we were looking at it we realized there was no expression for the mock objects really in the language and he actually had the mock objects provide the context. And so what we did is then we came up with was this given-when-then syntax structure to help the communication between the people writing the tests and people writing the code.
Traditionally what happened is developers would be writing the test but they really wouldn’t know what test to write and the people that should be writing the tests, the domain experts, they could write the tests but they didn’t understand Java and C# so they couldn’t write them. So, what we did with given- when- then is to create a simple sentence structure that the business domain expert could write the test in a structure where the developers could then take that test and directly code it up without them having to reinterpret or understand or work out what was being said, they can literally copy the structure straight across and it would then fit with the TDD or BDD with mock objects structure of writing code. At this point Dan then went on to write JBehave and popularize BDD and I worked on the other problem which was basically, we say that the business people are going to write the tests, but how do they know what tests to write? What examples they should actually provide for the development team? So that’s where I worked on a thing called feature injection.
3. Talking about business analysis and feature injection, what is feature injection?
So, feature injection is very simple. The idea is that most of the time when business domain experts come and ask for something they very rarely tell you and express it in terms of the value they want, they often come up with a half-baked solution. What we actually want though is something which is a set of examples that can drive the Agile development process but driven by value.
Feature injection has three very simple steps, first step is find the value, second step is inject the features, as we call it, and the third step is break the model. What that means is a business person comes to you and says “I want a tea bag”, well, no one has ever wanted a tea bag, what they really want is a cup of tea, so when they ask for a tea bag, we say “why do you want a tea bag?”, “well, I want a cup of tea”, once they’ve asked for a cup of tea we can say “why do you want a cup of tea?”, and they go “well, because I’m thirsty”. We can now present them with a number of different options in terms of how to make them un-thirsty, how to quench their thirst and the value is in the quenching of the thirst. So we practically decide on the value is the quenching the thirst, we want to have a cup of tea which is the output of our system, once that we’ve done that, we’ve done the first step, we’ve identified the value.
The next step is to inject the features. This really is a case of rather than saying “let’s build the tea bag” and then when you deliver the tea bag the user says “well, now I need some hot water” and when you’ve delivered the hot water, they go “well, where is the cup to put it in?” What we do is say “right, we want a cup of tea, in order to get a cup of tea, what do we need?”, that’s a much easier question than simply just delivering the tea cup and going through that iterative steps. You go “right, I want a cup of tea, to make a cup of tea I need to have these features in my system: I need tea bags or perhaps tea leaves, I need hot water, I need a cup and I need milk”. That is injecting the features into the system; it’s the Kanban cards flowing backwards across the factory in order to pull the values out that we need.
That is the second step which is you start with the output and you work back to the input. If you ever do analysis and you start with the inputs, it’s a very painful process and you end up in analysis paralysis. If you start with the outputs and move towards the inputs, it’s a very simple process and you know at each stage what is needed.
The third step is you ask for a cup of tea, well, what if we ask for other things, what about a cup of coffee, is a cup of coffee similar to a cup of tea and it is, we don’t need anything new in the process; how about a hot chocolate, that’s the same; but then we get to things like a can of coke, is a can of coke the same as a cup of tea and what we’ve done is we’ve broken our model because in order to deliver a can of coke it needs to be cold, so we need a fridge or a chiller of some kind. And so that is the third step of feature injection, which is break the model, find different examples that actually break your processing model and as a result you can fix it and improve it.
Ok. I come from investment banking background and options is very popular in that world and when I first got into Agile, I noticed that Agile was a better methodology for managing the risk on projects to traditional methods and that is because there are a whole lot of options that exist within the framework. And so I tried to value them, as you would, and I failed. You can’t really value a lot of options, particularly in the real world. Whereas you’ve got equations like Black-Scholes for valuing financial options and that’s great, when you get to the real world, some of these things here just can’t value them, how do you value a kiss, and if you can’t value the kiss how can you value the option to have a kiss, it doesn’t work. What we did discover looking at this maths is that there were three things we could say about options:
The first is that options have value, we do not know necessarily what the value is and we can’t accurately calculate it, we just know they have value.
The second is options expire, by that what we mean is there is a period of time and after that period of time the option no longer exists, it just expired, so if I wanted to get here today to QCon by 9 o’clock, if I hadn’t set off from home by 8 o’clock my option to be there on time at nine would have expired.
And the third one is we never commit early unless we know why.
What these three things do is, the first one, that options have value and never commit early unless you know why really tell us about the behavior we should have when it comes to making decisions - which is we should defer our commitments as long as possible. However, the second one is the really important one which is options expire, because this says we can put things off, put things off, however there is a point at which that option expires. So, when I got up this morning at seven I could pot around the house and decide am I going to go to QCon or not for the interview, I am going to be there for nine, and as I was pottering around I was fine until I got to 8 o’clock, now if after 8 o’clock I’d said “you know what, I am just going to potter around a little bit more”, I would have lost that option of being there for nine. But before that I don’t need to make any option, so it’s a case of understanding this option expiry and the key thing is to understand that is not just a date or a time, quite often that is conditional, it’s “my option to talk to Roxana expires when she goes back to America and I won’t get to have the opportunity to discuss her wonderful paper on software that I read in 2006”. In terms of how you apply them to software projects, real options are actually build in to a lot of the Agile practices and methodologies, such as for example test-driven development. Test-driven development has got built in real options, because if you think about what it is, we don’t make commitments unless we know why, so we don’t write the code and then try and test it, we say “no, we want to know why we are writing the code first, so we write the test first and then we write the code”. And that is an expression of real options because you put the commitment after the decision and getting all the information you need.
Ok. Real options is a very rational process for making decisions and it upsets some people because they don’t make decisions this way, and when we say this, they go “oh, right, we don’t like it”.
One of the things we’ve discovered is that people are not always necessarily rational in the way they make decisions; if you were being entirely rational your preference for making decisions would be first, you’d want to be right, then if you are not right you would like to be uncertain, and if you’re not uncertain you’d like to be wrong. But if you actually observe the way people make decisions their true preference is they’d rather be right, if they are not right, they’d rather be wrong, and if they are not wrong they would rather be uncertain.
We see this all the while in software development, we often see managers when someone is saying “we don’t have enough information now, we shouldn’t make a commitment now, we should defer that commitment, we should make the decision later”, the manager says “no, no, we’ve got to simplify the situation, we’ve got to reduce complexity, we’ve got to make a decision now”. And a lot of it is down to this uncertainty problem, where people would rather be wrong than be uncertain. The way you manage this is instead of having total uncertainty around a situation, you create bounded uncertainty by saying “ok, the option to do this is going to expire at this point, so why don’t we make the decision then rather than now”. So you are not saying “let’s make a decision later”, which is what we often approach this subject with managers, instead what we’re saying is we’ll make a decision here and it means that we are not going to lose any options, we still have all of our choices up to that point, but at that point we are losing that choice so we will make the decision then as to the way we should do it. And from my experience it’s a very effective way of getting people to defer those commitments that cause a lot of pain because we don’t have enough information now to make them. And it also means that we’ve then got the time, now we know what information we’ve got to gather, to actually go find that information before that point.
6. You mentioned your book, why is your book different from other books?
I am working on a book with Olav Maassen and Chris Geary. Olav and I have been working sort of, we’ve been talking about it since 2006, we’ve been working on it seriously for about two or three years now. What is different is that a few years ago I did a comic strip on explaining real options and Olav and I decided “you know what, we are going to do a full graphic novel’ and we’ve applied all the stuff that we talk about in the book into the production of the book and rather than write a book that is easy for us to write, which would be basically the two of us just siting down writing a normal standard business book, we’ve actually written a book which makes it easier for the reader to understand, because some of these subjects are a little bit difficult to get or they might be challenging to the way people think about things.
What we discovered with the graphic novel format is that if we write a normal book, the author almost has this voice of God where they’re telling the reader what they should be doing or thinking and the reader is then forced to think about what is going on as they are reading it. What you can do to get away from that is you can actually take the reader out of the conversation and have the conversation going on between two different parties. Steve "Doc" List is doing some great plays and stories where he’s got two characters talking through the ideas.
The reason we went one step further and had the graphic novel format is because in a graphic novel format it’s very easy to see who is right, who is actually doing the talking. If you are doing a smaller piece, it’s easy to keep up with what is going on, but if you are reading a full book it’s very hard to read a play, and I think that anyone who’s read through plays at school understands this. Normally, the way you read through a play at school is two of you have to read different parts and you are reading in the class, very difficult to actually just read it yourself. So by doing it as a graphic novel format we make it very easy for the reader because the reader doesn’t have to be part of that conversation, they can just observe the conversation, makes it a lot easier for them. But also it makes it easy for us to introduce graphics and to show things that are going on, whereas in a normal book if you’ve got a graphic you then have to spend a lot of words describing and explaining to the reader where to look on the graphic.
7. Talking about readers, who is the book intended for?
Olav and I have made a great deal of effort to try and not to make it an Agile or an IT book, we are hoping that it would be relevant beyond that group. We have actually gone through it time after time and tried to remove those very specific terms that link it to a particular community. We are kind of hoping it could be for anyone that gets engaged in projects and needs to manage risk on projects.
A couple of months ago, when you’re writing a book, your energy levels drop, I kind of reached one of those points when my energy level dropped and I read through the graphic novel on the plane on the way back from a foreign trip and what I discovered is you can read it in just over an hour, and that really opened things up for me because it’s like “hey, wait a minute, here is a book on Agile principles, on real options, on Lean and it’s in a format that an executive can read or a senior manager can read in just over an hour, whereas if we give them a lot of the existing books, it might take them 20 hours to read a book and they are not going to read them”. So, we have now created a book that they can read in an hour or so, and the other thing is it’s a story as well, so that also makes it easy for people to read.
Now, in terms of the demographic, there is an interesting thing that happened which is we’ve used the real options principles so every stage rather than make a commitment we tried to get feedback from our target audience as to what they like and dislike and one of the things we did when choosing the artist for the book was we took samples of two pages and it was exactly the same story on the page but it was drawn by two different artists and we asked people at the ALE conference in Berlin what do you think, which is the best one, and then we did actual A/B testing on the actual artists, which one we should use.
The most amazing feedback we got was from Ivana, because she said “you know what, I am sick of reading a book where the mentor is always a middle class man” and as a result we decided that the mentor would be the main character’s younger sister, so we have a book where the two main characters are women and as a result women respond really favorably towards the story because they see two really strong role models in the story in female role in a project or IT setting. So, it’s for everyone, but we are getting a positive vibe from the women.
Roxana: Thank you, Chris Matts, for doing this interview today.