Our Guest
Gary Straughan, the Founder of the YouTube channel Development That Pays is our today’s guest on the Agile on Board Show. Gary is a Senior Developer with more than 15 years of experience in software. Gary has extensive knowledge of Agile best practices and helps individuals, teams, and organizations unlock the full potential of Agile.
Video Transcript:
Gosia: Hi, I’m Gosia from Whiteboards and this is the Agile on board Show. Today, my guest is Gary Straughan, a Senior Developer with 15 years of experience in software, and the founder of an amazing YouTube channel called Development That Pays. If you don’t know this channel, I recommend you go and check it out. Gary explains Agile concepts in an easy-to-understand and visual way.
Hi, Gary, nice to have you on the show.
Gary: Thank you very much indeed for having me. Great to be here.
Gosia: As a software developer, I’m sure you’ve worked on many teams, with different setups, and you’ve attended loads of estimation sessions. I would like to know what your take is on ‘estimating vs not estimating?’ It seems to be a huge debate. What is your take on it? Should we estimate? Should we not estimate?
Gary: It’s a really good question. You’re right, it is kind of a controversial one. I’ve been asking that very question for the best part of six years when I first started doing that YouTube channel. When it started to take off a bit, I got to the point where I thought I should ask people, what they were struggling with or what kind of videos they might like to see.
I did a survey. The subject that came up more than any other was the thorny subject of estimating. I must admit, I was really disappointed that that was the biggest thing that came up. I had no idea what to do about estimating because, as you correctly said, every two weeks I would find myself in an estimating session, having a sneaking suspicion that this wasn’t possibly the best use of my time.
I couldn’t really say what the alternative would be at the time. Now I think I do have an idea of the answer.
Gosia: What is so tricky about estimating? Do you think it’s a waste of time, that this time could be spent in a more efficient way? Because it’s not accurate, is there a point?
Gary: As you quite rightly said, I have been in many estimating sessions, and I will probably be in many more. In the beginning, I was there because I had to be there, and I didn’t know any better. I thought this Agile thing was very strange, and estimating was particularly strange. It’s one of the ceremonies that I kind of have a problem with. What keeps me going, and what will keep me going to future sessions is that there is certainly a big part of it that is valuable. However, it’s not the estimate, it’s the process of estimating.
There is a difference between the noun, the output, and the discussions that happen, as we’re figuring out what a particular piece of work looks like, and what’s involved in building it.
The first realization I had was, ‘we have these estimates, I have a bit of a problem with them,’ but I could see the value in the process of estimating. That’s what keeps me going to the sessions.
Gosia: What’s valuable is discussing the complexity so that we can really get deep into deciding how complex the task is; if we need to split it into smaller tasks.
How to do estimating, just with a discussion, but not using story points. What would you say?
Gary: Coming from that realization that the discussion is useful, I’ve been on a mission to find alternative ways. Can we for example do without story points? If we don’t have story points, then we don’t have velocity. If we don’t have velocity, we can’t forecast, for example. Is there perhaps another way that we can forecast without velocity? That’s a really good question, and I think the answer to that is, yes, we kind of can.
Gosia: How do we do that?
Gary: In my quest to solve this thorny issue, I came across a few people who have been piecing together various bits of the picture. I think Neil Killick was the first person that I came across. He was talking about story slicing. Neil was talking about having a different kind of conversation. Instead of having an estimating conversation, we could have a conversation on how to split this piece of work. How can we find the stories within the big story? That seemed to me to have all of the benefits the estimating conversation would have, plus the benefit that your output would be smaller and smaller stories.
Small stories have all kinds of benefits. If all of your stories are small, do you really need to be estimating them?
Gosia: It’s easy to say when we can deliver them right? If the stakeholders are asking and we have smaller story points, it’s easier to estimate when we can release that.
Gary: Exactly. Neil is not the only one who talks about story slicing, but he was certainly the first one that I came across so I give him some credit for that.
The next person that I bumped into, in this mini-quest of mine, was a guy called Woody Zuill. I remember him talking about, ‘we do our estimates, and then, if we’re doing things right, we have a retrospective.’
What he noticed in the retrospective is, ‘we made a right mess of estimating during the last Sprint, how can we do better in the next Sprint?’ Then two weeks later, there’ll be another retrospective and it was on the list again.
The point he made is that not everything can be improved. Not everything lends itself to an inspect and adapt mentality. That’s a little bit of a trap that we fall into in Agile. ‘Inspect and adapt’ is a good thing, but we can’t apply it to everything.
Gosia: Especially as this differs, right? Every Sprint we come across problems that are different. I understand why that would be tricky, improving on that.
Gary: I’ll give you an example he uses where inspect and adapt wouldn’t always work.
If I’m eating all the wrong food, it’s no use me improving my chewing. If you’re really focusing on the chewing and you’re not focusing on the root of the problem, which is the kind of food and the volume of the food that you’re ingesting, then things are not going to get better on the belly line.
It felt to me that that was it. That was my divorce from estimating that when I realized it was probably one of those things that were never going to get better. I really wanted it to die. I didn’t want us to be doing estimating. Maybe we could keep some parts of the process but not the output of estimates.
Gosia: Throughout your career, how many times were you accurate with estimates? I don’t know if it’s easy to say percentage-wise. Did it work sometimes?
Gary: It did work, sometimes, but mostly it didn’t. Everyone who’s estimated will know this, sometimes by orders of magnitude wrong. Something that you thought was a massive problem turned out to be trivial, a configuration change, and we thought it was going to keep us busy. Those are quite rare, I have to admit.
Much more difficult are the ones that look easy and come back to kind of bite you. And that’s okay. In Agile, one of the things we like to do is, it’s picking important things that we should be working on right now. That’s really, really good. If we pick something that’s important that we really want to deliver, that’s going to build the product and we’re going to be headed in the right direction. Even if it takes twice as long as we thought it was going to, that shouldn’t really be a problem, because we’re still working on the right thing.
It’s not the end of the world if things take longer than we thought they were going to. Where things get a little bit evil around estimating is when people come and say,
– ‘Well, I thought you said this was a 3, and you’ve been working on it for a week?’
– ‘Well, yeah, I really did think it was a 3 and I really wish I hadn’t been working on it for a week.’
This conversation isn’t helping, it’s just making me really quite angry. That’s the evil side of the estimate. That meaning of estimate, the word has a lot of fluffiness built into it, but somehow, that becomes a commitment.
Gosia: Stakeholders think it’s like a deadline. It’s an estimate, but they think you should commit, if you say it’s easy to do. How to deal with this issue then, if people are asking for estimates? Would you recommend slicing big stories into smaller ones?
Gary: Neil Killick did change my world quite a lot. It took me quite a long time after I discovered Neil Killick and story slicing to realize that that was actually the answer to some of these estimates. It was the answer to my problems with not only the estimating conversation but also those pesky estimates. What story slicing I think gives you and why I hold it in quite a high regard, is that it’s always both bits. It makes for a better conversation, gives you everything that the estimating conversation gives you and more, and also leaves you with a bunch of small stories.
Not only does it allow you to cherry-pick value, but it also helps to deal with those estimates. If all the stories are small, why would they need to be estimable? If you slice them and then you estimate them anyway. If they tend to be 2s and 3s and 5s and 8s here, if they tend to be all that kind of size it’s going to be pretty easy to choose how many stories you put in the next Sprint rather than how many story points. You can then get rid of the use of story points for picking items to include in a Sprint backlog.
I have another name that I have to mention because he also completely changed my world. Vasco Duarte did a lot of research on completed projects, to figure out if there was a difference in forecasting, if you use story points, vs if you just used a count of stories. He discovered that there was very little difference. That’s a top tip for you out there. If the main reason you are currently estimating is to forecast, you’re probably really wasting your time.
Gosia: How to deal with stakeholders that really require those estimates? If you have those small stories, you can be confident that they will fit in the next Sprint. You can confidently say that this will be delivered on that date, right? It’s easier. Can you satisfy the stakeholders and tell them when approximately it will be live?
Gary: I think you can, but I think it depends on the context. I don’t think you should be promising particular stories within a particular Sprint. Remember, they’re quite small ones. Life happens. As we said earlier, things that appear to be simple can turn out to be hard, and they can get delayed, or people can be off sick.
There are many reasons why we might not hit a particular story in a particular Sprint. I wouldn’t like to be held quite to that level. If we’re building a product, there shouldn’t be too much emphasis from the stakeholder point of view of a particular story getting done in a particular Sprint especially if we are in the mindset of building a product that evolves slowly over time now.
Before I was a developer, I had a business background. I understand that the organization has different requirements. There’s a big sales meeting, or we’re doing a press release. It’s not like we are immune from answering these kinds of questions. What we should be aiming for is, that product development over time should never be dependent on one particular piece of work being done.
What I’d like to see is that, we’re confident that the product will be functional by this particular date, and that every date after that, it will be better. The more time we have, the better it will get, and it will never be dependent on a small piece of work getting done.
Gosia: Would you say that it’s worth talking with stakeholders and changing a little bit their approach? If they are pushing for those tight deadlines, maybe we should talk to them and explain that this is Agile, and with each iteration, we’re improving the experience for the user. And maybe then they change a little bit their mindset, not to push for those estimates that are not meant to be accurate anyway?
Gary: Exactly. I think there’s definitely that to a certain extent. We the developers, we’ve kind of shot ourselves a little bit in the foot, because we estimate on numbers, and now we have numbers and we can create velocity. We can do graphs, we can do burndown charts. That’s the language that the business understands. They love graphs and metrics. Unfortunately, they look at that kind of data a different way than we look at it.
We use it as an aid to our development process, that’s what it’s intended for. When they look at the same data they probably see commitment. It’s definitely a thing that we have to learn to understand each other’s requirements and needs. And also shouldn’t shoot ourselves in the foot, by publishing the kind of data that was never meant to be published. I’ve seen burndown charts in business weekly updates, and it frightened the life out of me, because that was never, ever intended for.
That’s the very reason that Development That Pays, the YouTube channel, came into existence. The intent of the name was the ‘development’ bit was the dev and the ‘pays’ bit was the business. And quite a lot of my videos hopefully help one side, understand the other. That was certainly my intention today. If we understood each other a little more, maybe things would run more smoothly.
It’s difficult to be a software developer. It’s hard, and we do get stuck, it can be miserable sometimes. When people come knocking on your door or leaning on your desk, you know they want to know why something isn’t finished.
Gosia: Just to wrap it up and summarize. The estimation sessions, should help software development, and not be a hurdle or a blocker, something that we get stuck in, and waste time on. It should be helpful. Let’s focus on the discussion that helps, and then maybe let’s work with stakeholders and get them on board, changing a little bit their mindset.
Gary: That’s, I think. That would really improve the world if we manage to do that. It’s hard, though. Well, almost like everything in Agile, it’s difficult. But we should definitely strive towards doing that.
Gosia: Improve as we go along. Thank you so much, Gary, for helping us understand this concept. Once again, go check out Gary’s YouTube channel Development That Pays. I absolutely love it. Thank you so much for listening to this episode of Agile on Board, check out our previous episodes, and see you next time. Bye.
