NO and YES are two simple words, yet practice shows that professionals often have difficulties in using them. Actually it’s very easy, certainly when you want to work in an agile way. Dare to say NO when you are unsure if you can do what’s requested. When you say YES it means that you will deliver the product, on time with the right quality.
In the book The Clean Coder Bob Martin makes clear that YES and NO are often not used correctly when agreeing upon delivering software. The book describes many examples on (mis)communication between managers and programmers, on the estimation, planning and development of software.
A professional must dare to say NO. Say NO, when (s)he cannot guarantee that a deadline can be met, or when a proposed solution for a problem is not doable. As Bob states in his book:
Professionals speak truth to power. Professionals have the courage to say no to their managers.
Giving hope by saying “I’ll try” is not an acceptable answer. Bob gives a nice example of this:
When your manager tells you that the login page has to be ready by tomorrow, he is pursuing and defending one of his objectives. He’s doing his job. If you know full well that getting the login page done by tomorrow is impossible, then you are not doing your job if you say “OK, I’ll try.” The only way to do your job, at that point, is to say “No, that’s impossible.”
This is how a manager that I worked with would react to me when I would use the word “hope”:
When I would say to my manager that I would hope to get something done he would say “hope is postponing disappointment” (in Dutch: Hoop is uitstel van teleurstelling”).
He wanted to know if a delivery date could or could not be met. YES or NO. Not maybe, trying or hoping. And he expected to hear about any delays as soon as the first signals were there.
If you came to him late in the project announcing a delay, then his first answer would be that he assumed that you had already cancelled all of your plans for the coming evenings and weekend to keep your commitment.
If you informed him early, meaning as soon as you knew that there was a problem, then there was always a solution to be found.
Saying YES means commitment, also in agile. It means that you will deliver on time, or that your software will not have defects, no matter what. You say it, you mean it and you do it. Sounds simple, but it’s not always easy.
Of course you have already said NO to the things that you can’t do, so when you say YES you should be convinced that it is doable. Which means that it is within your control. And that you will do everything that is needed to keep your commitments.
If it turns out along the way that you cannot do it, take action. Don’t wait, take action once you find out by saying NO and making clear that you can’t keep your commitment. And then look for a solution on how to deal with that.
One last thing: If the test team finds a defects in your software, then you haven’t lived up to your commitment to deliver software without defects. My advice: apologize, solve the issue, and learn from it.
Always enjoy your Blog, but what happened in Agile to the standard processes in traditional project management of Probabilistic Confidence estimates – that can be produced in VERY simple ways all the way up to Monte Carlo Simulation at the system of systems level. We’re actually not allowed in our tradition software intensive systems to provide a Point Number. As well to say YES or NO, without a confidence interval.
“yes we can deliver those needed capabilities ‘on or before mid-Oct with 80% confidence, and ‘at or ‘ below your target cost with 80% confidence.”
This ten establish the range of confidence, the needed management reserve, schedule and cost margins, along with the margins on the Measures of Effectiveness, Performance, and Key Performance Parameters.
With our Agile At Scale processes now entering service these same guidelines are still in effect.
As Tim Lister says “Risk Management is How Adults Manage Projects.” What happened to that advice in the Agile world, since all risk comes from uncertainty, what happened to “managing in the presence of uncertainty?”
Thanks for your comment Glen, food for thought!
I did some work on using ranges in stead of point estimates, and also used Monte Carlo to estimate product quality (see Steering Product Quality in Agile Teams and Building Process Improvement Business Cases Using Bayesian Belief Networks and Monte Carlo Simulation). I know the benefits that these approaches can bring. But I’ve also experienced that many managers don’t know how to use this stuff. They actually ask for point estimates. So I never saw this taking off in project management. Maybe you’ve had a different experience?
Risk management in agile is very different from waterfall. It’s about embracing change and being prepared for unknown things to happen. It’s more about antifragility, not being worried for and even exploiting uncertainty. I’m unsure how range estimates could be helpful here.
But, I’d like to hear from you Glen and from others. Can we be as digital with a yes and no as I described in my blog? Or do we live in an analog world, where there’s things between no and yes?
Please share your thoughts!
Hello Ben,
First time I comment one of your blog posts.
Yes, saying yes means commitment.
Yes, being able to say “no” is important but it is really more constructive to say “yes, but …” (or “no, but I/we can…”). As usual with Agile, the scope is the prefered thing to be adjusted but it can also be the delivery date.
Also, developers need a safe environment where it’s ok to -sometimes- fail. If it is not the case, experiments are removed from the options list : developers will stick to what they know and to what they can estimate accurately. How do you manage situations where developers have a technical solutions which looks good but that they are not able to estimate because of a lack of knowledge/practice?
I like the yes, but and no, but, because it opens a discussion. Which can help to increase understanding and collaboration.
I fully agree that it should be ok to fail. When teams are forced to commit, that isn’t possible. That is why I want to give teams the option to say “no, we cannot commit”. Where the team will do the best they can, and deliver the most value.
If things are so unsure that the team cannot estimate, there are several options. Maybe there is no real need for an estimate, where the team will start to work and do whatever is possible. If an estimate is needed, the team can do a spike to increase their knowledge and become more able to estimate. Third solution is to keep options open, by using a “real options” approach. Which actually suggests that “you should never commit, unless you know why”.
Does this help?