#NoEstimates
I’ve been reading and writing about #NoEstimates for over a year… Along the way, I’ve found some great people with some great thoughts with opinions and experience both for, and against. I’ve worked on projects which have been estimated and planned up front, projects which have been estimated but no detail plan completed up front, and projects where the work has just started. I’ve had successful projects delivered in all of those contexts (on time, on scope, on budget, to the satisfaction of all stakeholders – NPS > 80, for example).
What strikes me is that throughout all of the discussions, primarily on Twitter (which is possibly the worst place to have a complex discussion of ideas), is that there remains an Us-vs-Them mentality. Both by those in the #NoEstimates camp, and by those in the No #NoEstimates camp.
In my experience which I’m sure won’t apply in every situation, when the business and engineering teams work together — and really mean together — I’ve seen the need for estimates diminish very quickly. The need for up-front planning diminishes. The opportunity to find solutions to problems is amplified, and the solutions are beyond what was asked for, or imagined, when the project started and there was minimal knowledge.
One of the arguments that bothers me the most is when I hear “you’re being irresponsible with other people’s money”. Or something along those lines. I don’t view it that way. It’s not us and them. It’s all our money, and we need to figure out how to spend it together. We need to be working together, with a shared understanding from all perspectives, instead of being responsible for simply implementing what someone else decides we’re going to do. My point is that it’s not your money and we deliver something. We’re all in it together. The developers, testers, release engineers, DevOps, BAs, CIOs. And everyone else.
When teams eliminate the Us & Them way of thinking, collaboration happens, trust develops, and new ways of thinking about projects, products, and problem solving can emerge. The way we’ve done things for decades no longer applies.
If, ten years ago, I told you that we could release to production on an hourly, daily, weekly basis, there are those who would have screamed bloody murder! How could you possibly release without a month of hardening? Where’s the smoke testing? What about time for UAT – how could we be sure the business would accept what had been developed? How irresponsible would this be? How could you be such a cowboy with other people’s money, putting that code into production? Hell, it used to take days or weeks, if not months in some cases, just to get the hardware up and running. That’s no longer the case. In ten years from now, I wonder if we’ll look back on estimates the same way.
I’m not sure if estimates can be eliminated entirely. But either way, I’m not going to stop exploring options and discussing alternatives.
Just as an aside, one of the projects I’d say was my most successful, personally, was a small ~$450K fixed-price, variable-scope project. We delivered it with significantly more functionality that had originally been discussed, about 20% under budget, and about 22% ahead of schedule. The client who paid for it was beyond thrilled. We worked our asses off, but never really put in any overtime – yeah, an hour here or there, but then we also took time off along the way. We understood the objective. We worked together to achieve that objective. And, we estimated nothing.
We’re Agile!
I hear a lot of organizations, departments, and teams talking about how Agile they are. As I talk to them more, I find there’s often a gap.
But before I begin, it’s important to know why you’re trying to be Agile. What are you trying to solve? I hear a lot of different reasons.
Sometimes I hear is because Agile allows things to get to market sooner. Okay…
Sometimes I hear that it allows for faster customer feedback. Yep… For sure.
Sometimes I hear that Agile can reduce risk. Well, it can certainly make things more visible, and allow risks to surface sooner, so sure.
Sometimes I hear that it costs less. I’m not so sure about that, but maybe.
Sometimes I hear other things, too.
When something looks simple (like Agile, Scrum, or Kanban), we do things without really understanding why we’re doing them. We emulate what we’ve seen, or heard.
We have daily standups. Do you know why?
We post information on whiteboards. Again, what are we hoping to achieve with this?
If we change some of what we do, we might not be getting all of the benefits of Agile.
I had a conversation recently with a team that is working on a new project. Doesn’t matter what. They’re working in an Agile way, and finding that they didn’t have a lot of structure, so there was lots of activity, but not a lot of progress. This isn’t uncommon. They were going to start with an understanding of our current process, mapping out all of the ways the thing they’re working on is currently done. Then, their plan was to move into a Design Thinking workshop, to identify the problems and come up with possible solutions. After determining the solutions, they’d design a new system. And finally, after all of this was done, they’d launch it with a pilot group to see if their improvements made a difference. Assuming they had, they’d then launch it globally.
The team was going to do this by working in two-week sprints. A few project team members had other responsibilities, so the team agreed to work together, in a collocated project room, every afternoon. They’d hold a stand-up and make their progress visible, to get the benefits out of Agile.
If you draw these steps out, it might look something like this:
Requirements Sprint
Design Sprint
Solution Sprint
Testing Sprint
Deployment Sprint
Operational Sprint
That looks eerily familiar with another process, which looks a bit like this:
Initiation Phase
Requirements Phase
Execution Phase
Testing Phase
Closing Phase
A couple of things come to mind. First, this group (and actually, the scenario I described above is a combination of at least three groups I’ve spoken with), is trying to emulate what they’ve seen, or heard, they’re supposed to do as an Agile team.
Our highest priority is to satisfy our customer through early and continuous delivery.
That means we want to find ways to get something to our customer as soon as possible. The sooner the better. Even if it’s not perfect, we can learn from our customers and find improvements.
In fact, that’s what we want to do! Rather than going through a discovery phase, let’s find something and fix it within our time boxed iteration, be that one, two, three, or even four weeks. That means taking something – one little thing – through all of the phases outlined above, and getting it into our customer’s hands. In the mostly-made-up example above, that would mean getting one idea through to our customers one week from now. What would it take to make that happen? What learning could we gain if we could get real-live customers to provide us feedback? Maybe it’s not a week. Maybe it’s two weeks. Or a month…
Speaking of time frames: one, two, three, four week sprints? If our goal is to satisfy our customers, we should “deliver frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale”. The sooner we can get something in our customers hands, the sooner we can start to get their feedback, allowing us to learn. The object is, at the end of whatever time frame you’re working with, you have something done (which means: launched) at the end of it.
In an Agile environment, what’s the most important thing for us to know we’re being successful? Our “primary measure of progress is working functionality”. (And yes, I slightly cheated with the wording on that; not everyone I interact with happens to be building software). As with the previous point, this means that until it’s in our customer’s hands, we’re not really making progress. We might think we are, but until we get customers to use whatever it is we’re looking to deliver to them, it’s only our best guess – a hypothesis.
And we need to validate our hypothesis by getting that working functionality to our customers.
In fact, from a lean perspective, anything created that our customer’s aren’t using is inventory. Inventory isn’t something we want, since there’s a cost to us, but is delivering no value.
But, perhaps my second favourite principle from the Agile Manifesto is that “simplicity – the art of maximizing the amount of work not done – is essential”. It’s possible that I’m going to find the best solution for my customers with the first thing I offer them, be it a new credit application, making a bill payment, or redeeming my rewards points. But what’s more important is that by making something available for my customer’s, I can learn and iterate on what I’ve done. This means I don’t need to build every costly feature I can think of, until there’s a business need for that feature.
By maximizing the amount of work I don’t do, I’ll actually be able to get more things that add value to my customers & my business done.
And if maximizing the amount of work not done is my second favourite, the most important thing about working in an Agile way, at least from my perspective, is that “at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly”.
More than anything else, Agile, specifically the Scrum and Kanban frameworks, are continuous improvement frameworks. That’s it. Agile won’t solve any of your problems for you. What it will do is help highlight them. It’s up to you what you want to do about it. And it’s up to you to figure out ways of working better as a team, to deliver more value of higher quality to your customers.
What are some things you can do? This is a tough one. This really requires us to think about what we do, and how we do it, differently. But more importantly, we should start with understanding why we’re about to do something. Not only why we want to deliver something new to our customer, be they internal or external, but why we want to do it in an Agile way.
The Agile values & principles are really simple, but they’re not easy to bring to life.
Thanks for the advice. It makes me feel even more useless.
Collaboration is a great thing. Helping a peer, or a colleague, is wonderful.
It helps us both get better at whatever it is we’re doing.
When someone is doing a job and others from the outside offer advice, tips, suggestions, or whatever, it’s meant to help. Sure. We all get that. But when someone is doing a job, and sees a seemingly insurmountable multitude of areas for improvement, and someone else keeps offering them ideas and suggestions, it can have the opposite effect. Instead of being taken as good advice or a welcome suggestion, it sometimes feels like there’s just another thing that you’re doing wrong, or are doing as well as you could.
Choose your battles, go for little wins.
I’ve seen teams that have such major issues in their code, their teamwork, their organization. And it’s impossible to fix everything at the same time. As an outsider to the team, trust that the team is improving, and find out what’s going on before you offer suggestions to fix something. It’s likely the team already knows. Offering your suggestion, while likely intended to help, can have the opposite impact, in pointing out yet another thing that isn’t going well.
Instead, find something that is going well. Instead of offering suggestions, find a way to congratulate the team on what they’ve managed to accomplish. Find out what the team is working on now to improve. If there’s nothing, sure, offer a suggestion. If there are already things being worked on, shut up. Seriously. Don’t point out yet another thing that’s not working. It’s not possible to fix everything at the same time. And your suggestion, while likely valid, can impact those who are trying to make thing better – when all you do is offer ways to make things better, you’re pointing out things that aren’t working the way you’d like them to, and I’ll bet they’re things the team also knows isn’t working the way they want them to be working.
It’s a great way to help people feel even more useless and depressed that they’re not fixing everything. It’s a great way to point out that people aren’t contributing as much as you think they should. It’s not meant to be a negative thing – I get it. You’re genuinely trying to help make things better. Be aware of how others might perceive your suggestions.
As I’ve been writing this, I’m reminded of a time I took my car in for servicing. One day, my car wasn’t working. At all. I couldn’t even start it. It turns out, something in the engine had locked up, or so the tech thought. But, my window wash pump was also broken. And a belt was looking a little worn, so needed to be replaced.
But until the tech could get my car started, the belt wasn’t an issue. The window washer pump didn’t matter. The car wouldn’t start. So replacing the belt isn’t the fix I needed. At least not at this exact moment.
Thanks for the suggestion, car service consultant. But you need to make my car go. That’s the only issue we should be talking about.
When there’s disfunction on a team, or when code quality isn’t where it should be, or when there are dependencies on other teams for systems, or when the daily stand-up isn’t being done the way the book says it should be, or when the stories are written cleanly… None of this matters if you can’t check out code. None of this matters when your local environment crashes every four hours.
Suggesting that the team should do a code review (or whatever suggestion you might have) doesn’t really help. At least not now.
Thanks for your suggestion. Thanks for your advice. I know you mean well. But it makes me feel like you don’t think I’m doing my job. It makes me feel even more useless because I can’t fix everything. You’ve just pointed out yet another thing I know isn’t working the way it should be. If you want to be helpful, have a look at the action items the team has identified from their last retrospective and help us fix those. We’ll get to whatever you might want to suggest today when it’s really our most pressing opportunity.