Hi, very good, thanks.
Craig: So Neil you're from Melbourne?
Originally from London, UK actually, I moved over to Melbourne about fifteen years ago.
Craig: Excellent, so you're almost a local?
Absolutely, I’ve made it my home, so yes, it's home to me now.
Craig: And you're from your own company called Iterative?
Yes, I’m basically an independent consultant and that's my brand – Iterative.
Craig: And as an Agile coach?
Yes, Agile coach, Agile Lean consultant.
I guess I discovered Agile quite late I suppose, later than a lot of the practitioners that would be here today. You mentioned my background is in development, mostly in Java for about fifteen years. It was only probably about five or six years ago or so where I started getting interested in the whole Agile movement. It was actually I took a Scrum developer role with EDS at the time, and actually I wasn’t a big fan of it at first, I didn’t like pair programming, I didn’t like TDD, anything like that. So it was actually an interesting journey because I was kind of a bit rebellious against it. I would like to previously sit in the corner and just do my coding and then I guess because of that I got interested in it, because I had a reaction to it. I started learning more about Scrum and sort of went off and got certified as a Scrum Master and started to learn a little bit more about it and actually I guess see the bigger picture.
And then I started to get more and more interested in I guess the people side of software development. So I’d always kind of enjoyed tech leading, team leading side of things, and decided to sort of move away from the development side. So in recent years I’ve sort of taken more business analysis, product manager roles, so essentially helping teams to deliver rather than actually getting in there and doing the coding and that’s kind of where I’ve found my place at the moment. I enjoy doing that and then started doing it more at the organizational level, helping senior managers and executives understand this Agile thing and how it can actually be effective in their companies. So that’s essentially my story I guess in Agile.
Craig: So it’s a journey all the way through the entire life cycle, which is very interesting.
Yes, it looks like somehow it just kind of skipped me by sort of early 2000’s, but yes it looks like it was once I was embedded in a Scrum team, I got interested in it.
I think it was, when I started researching about Agile and Scrum, obviously came across the Agile Manifesto and reading the Manifesto and the principles it actually struck a lot of chords with the way I think about things. So I guess a lot of the work situations that I’ve been in sort of seen the way things work, you’re kind of thinking “This doesn’t sit right with me, surely there are better ways of doing things” and so I’ve always had that kind of questioning-what-I-do approach. When I saw that there was this movement of people doing Agile, it kind of really hit home to me that this sort of Agile mind set and sort of principles and values very much align with my personal principles and values. It’s interesting: I’d speak to some people who I guess follow Agile and the Manifesto is their basis, their guiding principle. But for me, it just married with my personal principles, so it wasn’t like I had to shift my mindset to anything, it was just like “Yes, this is it!”
I now get this Scrum thing and why we’re doing these things, whereas before it was just like “Just do it, because we are a Scrum team and we’re Agile.” Once I actually learnt more about it, I started to want to do these things and then want to share the knowledge and when you see these things are effective, it’s infectious and you want to share that with other people.
I guess there wasn’t one particular “light bulb” moment, but it was more a kind of a journey of just realizing that there are ways of working out there that aren’t the traditional constrained ways of working that I’d been used to as a developer in big consultancies and corporations where you’re sort of just boxed in a corner with a team and you’re just kind of told what to do and given specifications. It’s now a completely different world where what’s expected of you as a software developer and it’s really interesting. Hopefully, because I’ve come from that background I can try and help developers with that journey, because a lot of developers are quite insular and it’s difficult for them to suddenly have to work in this collaborative environment and work with business people daily, so I try and help them with that the best I can, given that I’ve come from that background.
Given that really I wasn’t involved in the Agile scene at all in London, so before I’d moved over here I’d never even really heard of Agile, to be honest, so the Melbourne Agile community is my first real exposure to an Agile community and what I would say is I’ve been really impressed with the level of passion and enthusiasm that’s out there. Often, in our day-to-day work we get very frustrated and bored with the way things happen and sometimes you think that there is no way out with that and then you go out in the community and you got these meet-up groups and there is people out there who are not necessarily all agreeing with each other, but actually recognizing that they want to get better and they trying to make their workplaces better and it’s that sort of common unifying thing that goes on that makes it quite special.
I’ve really embraced that and gone out and tried to contribute to the community rather than just go to these meet-up groups so I started to try involve myself and get to know the community leaders like Craig Brown and he was wonderful in embracing me and allowing me to run meet-up groups and talk at the LAST conference last year and things like that which have helped me contribute what I’ve seen as effective principles and practices in the way I do my work and try and build the culture of the teams around me and trying to share that with other people and show that if we are aligned in our principles, then the other stuff falls into place. We’re never all going to agree on ways of doing things, but as long as we are all in agreement that we should be questioning the way we do things, then that’s a good common purpose.
I can’t compare it to the London scene or any other big cities, but Melbourne’s got a thriving Agile community, there’s hundreds of people come out and share their experiences and want to learn more. To be honest I can’t even really speak about Sydney or anywhere else in Australia but Melbourne certainly got a good thing going and it’s getting better. So I’m extremely impressed and happy to be part of it.
Craig's full question: Actually this is the first time we’ve met in person, although I think we’ve been avid followers of each other on Twitter for a little while and I would consider you one of the more vocal people in the Agile community in Australia who, when you say something, usually it’s something that people stand up and listen to. Most recently, I was sitting at home one night following my Twitter stream when next thing this eruption erode from a meet-up you did at an Agile Melbourne earlier in the year about this whole movement called “No Estimates”. Now, before we get into that, can you explain to people who maybe haven’t heard the term what that’s about and where the whole thinking came from of no estimates?
In some ways it’s amusing that’s become a movement because essentially it’s a Twitter hashtag. As you know, Twitter hashtags are about generating a conversation around a particular topic. We’re not quite sure who came up with the original “no estimates” tag, it’s been going on for a couple of years now and there’s are a couple of other people who regularly contribute to that. Woody Zuill and Vasco Duarte are two prominent ones. So it’s probably one of those guys started it and it was around the same time I joined Twitter because I wanted to start learning more about people in the Agile community and learning things from people and I got interested in that actually because I was a very big advocate of story points and actually I recently learnt about these and really understood them and I was using them and actually thought they were great, a great way of doing things and so much better than the way we were doing things before, so actually I was vocally arguing with Vasco about, because he wrote a blog post about story points are harmful and I was actually arguing the case for story points saying “but what about this, what about that?” and I guess from that conversation it started, again I started thinking about it because my thinking is being challenged and I went off and rather than just changing my belief system I was what I will do is I’ll measure data in the same way that Vasco suggests and I will do that alongside story points and from that I started to realize he’s actually got a point and started to get more interested in the whole topic of estimation.
Craig's full question: So just before we go on there, can you just explain briefly what that measurement was? Obviously anybody who does Agile 101, gets the idea of relative estimation, story points, Mike Cohn and that’s a massive mind shift, at least we’re not talking about days or hours or minutes and those types of things, but this type of measurement that Vasco talked about in that blog post, I really recommend viewers of this video if they haven’t seen that go read it, can you just explain to people who haven’t seen that what were you measuring, so you were measuring story points, what are you measuring alongside of that?
Actually just on that point, there are actually a couple of really good blog posts about story points but essentially the algorithm was around the fact that we can actually count stories rather than use story points, so by actually using good story slicing practices whereby we get stories to be small enough that they are actually on average roughly the same size, when you are talking about a number of stories it doesn’t matter that some are bigger than others, so rather than looking individually how big things are, just worry about how many things actually get done, so you end up with this normalized approach which allows you to actually just count stories. You even see this in the teams I’ve worked with with story points what simply happens is if it’s a brand new team, after three or four sprints this kind of normalization happens where teams are now used to breaking work down into small chunks because they work in two week chunks and what you find is that when they are doing the story points estimates almost every story is a three.
Craig: Or worse, because they get a nice minted fresh deck of cards they sit there and actually try to put things that are almost of logical size “oh, I’ve got a 1, 3, 5, 8, 13 and 20” or even more if they use the rest of the cards in the deck, they almost feel obliged to go use it.
Exactly right. So, once you start to see that normalization and you start realizing you are actually getting five or six or seven stories done every sprint, you start to think “hang on, what’s the point of actually estimating these because that’s pretty predictable”. As unpredictable a domain as software is, to have that kind of predictability, you are not going to get any better than that.
Craig: So, the key is the breaking down of the stories.
Absolutely. So that’s the key for your velocity to become your throughput if you like, it’s actually similarly sized things going through the system, but I guess it’s also the realization that your product backlog isn’t a representation of everything you are going to build, because story point velocity only becomes useful if you are looking at what you are going to build in its entirety, so you’ve got a backlog of 200 points and you are doing 10 points per sprint, it’s going to be 20 weeks, 20 sprints. So, when you realize though that you are not going to be building the entire product backlog, you’re actually working in an Agile way, which means things are going to emerge and things are going to drop off and you are going to be constantly prioritizing and changing things then actually you start to think “what use is it for me to know that we get 20 stories done every sprint if we are not actually going to be building this thing that we’ve predefined”. Then you start actually talking about what you are delivering and value and this is another thing I like about just dealing with stories rather than points is that you are talking about real things, you are talking about business value, you can talk to execs and managers about these things, what have we actually delivered and why we have delivered it rather than we did 30 points this sprint or why didn’t we do 30 points this sprint, why has our velocity gone down, the conversation is around the wrong thing in my opinion.
Craig's full question: So, to sum up what you are saying is, you have stories split down into equal size and you count the cards then which actually gives you some sort of measure of throughput about, using yesterdays weather, about what you have done but also so you can look forward about what you are going to do. So, one of the arguments that always comes up in this is “oh, but my manager wants to know when this project is going to finish” before we’ve even done anything, so how can I possibly do that without estimating, because you are saying we do no estimates, which is kind of a little untrue, but how do you get that information to people who might need it?
So I guess, first off the “no estimates” hashtag has generated conversation around that we are basically saying that you should never estimate. I don’t know how that’s quite come about, but I guess it’s inevitable given the name of the hashtag, and people have said “well, why don’t you call it something else?”, well my response is it’s a twitter hashtag, it’s generated conversation which is ultimately what I wanted, regardless of whether people are going to continue estimating in particular situations, I wanted people to be questioning the biases they are using for these estimates and what information they are actually using.
Craig: I think the nice thing from sitting on the side is that people see that “no estimates” hashtag and its almost like they go read it because they go “surely not!” It’s almost that reverse psychology of we won’t do any estimates and hang on a second I’ve got something up my sleeve.
And the way I would describe it is an investigation of whether we can do software with no estimates, rather than saying don’t estimate, it certainly it’s not the intention for people to be rebelling against what their managers are asking for. But the thing that we can do though is when managers ask for these kind of estimates, we can give them to them but what we can also do is actually measure what we are doing and this is fundamentally what it’s all about, it’s about “let’s actually see what we get done and use that as information to make our future decisions”, whereas story points are always based around a sort of deterministic approach, how long we think this is going to take. Aside from all the biases that go on in your head when you estimate, software isn’t predictable, we can’t make things equally sized and predictable in a sort of manufacturing widgets kind of way.
So by actually using good practices like I mentioned slicing stories down and limiting our work in progress, that actually gives us a level of predictability where we can actually say “look, we get through between seven and nine cards every week”, that is good enough to then project forward and make estimates about when we are going to get done or what we can get done. What I would say though is that I still wouldn’t advocate, even though data based estimates are obviously much better than guesses, I still wouldn’t advocate making any kind of medium to long term decision based on them and this is really fundamentally what “no estimates” is about, is about why are we making big business decisions based on estimates where we all know that the cone of uncertainty basically tells us that anything beyond a few weeks is highly, highly uncertain and it just gets worse and worse and worse yet we make these upfront decisions about big projects and based on these estimates.
So, really it’s about the big upfront thinking rather than the concept of estimating being bad. If you can actually estimate and you’ve got real data to back it up, I used that myself, so say we’ve got a release coming up in four weeks’ time and we’ve got a certain number of cards that the Product Owner wanted done for that release, using cycle times and throughput because we are actually counting these things I can show the product owner and I can say “you know what, this story down here which you were talking about the other day based on our current throughput there is a very good chance that’s not going to get done in that four week release. So if you want it done you might want to move it up the queue”.
So it’s using probability to make short or near-term decisions rather than going “wow, this is now going to take us three months so we better push out release date.” We can delay that decision, there is no need to make that decision now. So, for making short term decisions I would use these estimates, I prefer to call them measurements or forecasts based on real data rather than an estimate which we typically think of as asking someone how long something is going to take and they have to use their experience and knowledge to make that decision. So, whilst it’s technically an estimate, I tend not to call it that, to differentiate I suppose.
8. [...]So, why do think firstly people find this such a hard thing to comprehend?
Craig's full question: The interesting thing is that if you’ve done any reading of Don Reinertsen or David J. Andersonon Kanban these are all the concepts that these guys are thinking about, so as you said there is nothing new in here, but why do you think this has created such a storm, because in the last few months the angst around this topic has amped up and one of the reasons I think it is interesting to talk to you is, what I really admire, is you haven’t backed down on it, you’ve kind of picked this up and went no I am just going to keep trying honing the message. So, why do think firstly people find this such a hard thing to comprehend?
I think its touched a nerve because basically it touches everyone in software and all software projects or certainly most of which I’ve been involved in have been driven by this estimate approach, so it’s not so much a problem with estimates, the concept of estimating, actually in my talks I don’t really talk about those things, Mary [Poppendieck] earlier touched on cognitive biases and what have you with estimation and the cone of uncertainty, I don’t actually talk about those things, that’s not the most important part of my argument, it’s actually more this culture of estimation that is created, the first question we ask is how long is this thing going to take, what are we going to do and how long is this going to take and that basically drives the whole thing then because then you set expectations and promises that then filter down into the whole way you do things and it affects your behaviour.
Estimates are fine, for what they’re worth, to have a gut feel about what might happen in two or three months, but when they start influencing your behaviour, and this is what happens, this project is going to take us six months you are four months down the line and you realize you are off track but yet this thing has become a deadline and a promise, your behaviour is going to change. And similarly, if you’ve actually underestimated and you’re lucky enough that you are well ahead of schedule, again it’s going to affect your behaviour because then you’ll start saying well, we are can now do some features, we’ve got more money to spend and then you might start building things you don’t need. So, either way this estimate driven approach affects us all in the software industry and that’s why I think there is so much debate about it and I think it’s controversial because it’s obviously very different from the traditional mindset, to think about other decision making models other than what are we going to build and how long is it going to take, I think it’s more the mindset of trying to nail down what we are going to deliver and therefore we have to estimate it.
We are trying to create predictability in an uncertain world and it’s kind of ironic because we try to create predictability in situations of higher uncertainty because it’s scary and it’s ironic because by trying to create that predictability we are actually creating even more uncertainty because we are putting uncertainty around the delivery date and the delivery costs, because we are just basing it on people’s guess essentially, whereas in some ways the approach I am advocating gives us more predictability and is less risky because we are actually putting a line in the sand and we’re saying this is how much we are going to spend, we are going to do it in small increments but the cost becomes certain rather than uncertain. And all the cultural aspects, dysfunctions that are caused by estimates disappear as well. I completely get why it’s controversial and it’s interesting to people.
Craig's full question: So, if my manager in my organization and I decide, maybe I’ve already made the leap, or maybe I haven’t, but maybe I’ve already made the leap to at least story points, maybe they at least get that, maybe they don’t, I don’t know, but I want to change someone’s perception on estimation, any hints for how you attack people who are outside our community because I think even though there still is some debate in the Agile community, I’ll get to that in a moment, I think most people at least get the whole relative estimation which is still what this falls into the bucket of, so how do you make that argument to a project manager or to a CIO who is so engrained into that “but I need my estimates”?
The first thing I do is I don’t even try to make that argument, I’m not about arguing with people who think in a certain way and want things done in a certain way, that’s absolutely fine but what I can do though is I can go away I can use my own data, I can use the budgetary constraint that I know we have to work in the way that I think is going to be effective whilst also delivering predictability, so in the case of projects where I am asked to make an estimate upfront, it’s not like I’m saying no, we are not going to do that, we’ll go ahead and do that, it’s almost like we forget about that now, now we are going to work in an effective way, we are going to focus on what is the most valuable thing to do next and we are truly going to iterate over that idea, so we are not going to try to come up with a backlog of all these things which we are going to then just knock off in iterations, just increment through them, we are actually going to go what is the problem we are trying to solve, what is the goal of this project, if we’ve got six months let’s try and do something in a month, let’s try and solve this in a month, not let’t think let’s do a sixth of what we are doing. So, I guess a big part of what I am advocating is to put the iterate back into iterations, iterations in companies have become just time-boxed, incrementing of a product backlog and we’ve lost.
10. Let’s just make it through the next two weeks of the project?
Yes, we’ve lost sight of the fact that we are actually supposed to be actually looking holistically at a solution every two weeks and if we can’t do that, let’s do that every month but we need to be iterating over that so we that can actually do the best thing and the right thing for our customer and for ourselves rather than get fixated on this solution that we’ve come up with and end up delivering that, which might be what the customer or the stakeholders wanted at the beginning but it’s not necessarily what they wanted at the end. And the concept of on time on budget being a success measure I find really curious because if that’s success we could deliver anything in six months and be on time and on budget and call it successful but if it’s not being used and it’s not actually valuable, it’s not the right thing then I would say that’s not success. So, I guess the no estimates thing all stems around these kind of ideas and I have come to that realization over the last few weeks that it’s not so much about estimating, it’s about big upfront project thinking, it’s about the mindset and cultural aspects of estimating.
11. [...]Is that just in the mechanics or is everybody at least singing from the same hymnbook?
Craig's full question: So, others in the community andyou mentioned before, people like Woody Zuill and Ron Jeffries and Alistair Cockburn, have all delved into this debate along with others like Vasco and myself and others, Craig Brown, you mentioned earlier, everybody’s put their little two cents in, but there seems to be at least in some of those people I mentioned before, some slight difference in opinion. Is that just in the mechanics or is everybody at least singing from the same hymnbook?
Well, I think this is it, because no estimates isn’t actually a process and we are saying you can go ahead and do this, that there is natural differences because it’s just the point of the no estimates hashtag was to discuss different ways that we can actually approach software that don’t involve estimating or that don’t rely on estimating. Woody’s approach I think is probably purer and simpler than mine, basically what he is saying is that if you follow the Agile Manifesto principles and values then you are actually not going to need to estimate because you are going to continuously be delivering value which becomes predictable in its own right. And I wholeheartedly agree with him on principle, I think where the differences are is the practical application where there are questions like, Ron will keep coming back and saying but what if I am an investor and I want to know I am going to get what I want in six months, so I want to know if am I going to get a result for my money, and it kind of really all boils down back to this, so I guess I am trying to add some nuances to what I talk about around systems thinking and traditional projects and traditional management in that I recognize that there are these questions, people need answers to these questions, it’s perfectly natural to want to know what are you going to get for your money, but if you flip it on its head and rather than say what am I going to get for my money and when, if we actually look at it from a budgetary constraint point of view and say this is how much money I’ve got, what can we do for this amount of money.
It actually sets us off on a much better foot because it means we that we can work together with the customer to come up with the best solution for them iteratively. That is against the agile principles, if you know welcoming change for the customer’s competitive advantage, it’s like can we truly welcome that change if we’ve got these fixed promises and we’ve kind of set in stone what we are going to do, even if we think we haven’t, I still see in supposedly Agile projects when big changes are suggested people are coming up “we can’t really do that we are only a couple of months away from the delivery date”. So this concept of having a delivery date is fine as long as you are actually willing to actually completely change direction at any point and that’s what we have to be willing to do if we are going to iterate. So, I think there is probably common ground in that, I would say Ron, Woody, Vasco, we all agree on these principles, it’s just I guess the minor nuances of how we would deal with particular contexts.
And I find that really encouraging that people are coming back and giving quite specific examples, or what about here, or how could we do no estimates in this example and that’s great because obviously depending on the context it’s going to be completely dependent on the approach that you are going to take but really as long as we are focused on doing the right thing by the customer and ourselves, then if we do use estimates in the right way, then there is no reason why we shouldn’t do that. But, what I see in the industry, they are not being used in the right way and they are destructive because of that, it’s not the concept of estimates that is destructive, it’s the way they are used.
If there was one realistic goal that I would like out of this is that we start actually talking about these things. When the seed of a new project comes into fruition in a company rather than this clandestine, putting together a business case and guess what team we are going to need, what is going to cost and then it’s all ends up filtering down to a team at some point and then of course the whole gaming thing begins, if we actually just get in a room at the beginning, all of us, the teams, the managers, whoever is involved in making this thing come to fruition and create a culture of honesty about this, I’d like people to understand the dysfunctions of estimating, so understand when they are making estimates, they are not promises and they are not deadlines and understand things like Lean StartIp, Beyond Budgeting, Real Options, these are all great theories and practical advice for how we can actually manage our projects in this way where it seems really kind of gung-ho where we are making decisions fortnightly or monthly but actually it creates, Mary touched on it earlier again, it creates better predictability because we are actually delivering things constantly and then we are questioning what should we do next, is this right, should we ditch this, should we do something else. So, having that culture of honesty would be the thing that I would like to see out of it, it’s not that I want to see people not estimate, I want us to be able to go to work and do the right thing by ourselves and our customers without the fear that we are not going to meet some deadline and get hauled over the coals for it, let’s do the right thing for our customers and ourselves essentially.
So, my website neilkillick.com it’s got various posts on no estimates stuff and some earlier stuff which talked about breaking down stories, it’s kind of a nice lead in really. Woody Zuill has got lots and lots of blogs about this, same with Vasco Duarte, even if you just google “story points are harmful” I think you are going to get a whole bunch of results for that and of course the “no estimates” hashtag is still ongoing debate, it’s probably getting irritating for some people now, but it’s still there so you can come on and join in there as well.
Craig: Excellent. Well, it’s been great talking to you Neil, thanks for your time.
Yes, thanks Craig. Cheers.