No Questions – No issues

I came in a project of some 70 people, with 3 Scrum teams of some 12 people each. We know 12 is too many, but that’s another story.
At a Sprint Planning meeting I asked one of the teams: “What would be the measure of success for this Sprint?” They looked at me: “What a strange question. We’re Agile, so we deliver working software. Don’t you know?”

noquestionsI asked: “Shouldn’t we have a measure of success, to know that we really did a good job?”, and I suggested: “No questions, No Issues“.
That’s easy to measure: one question or one issue and we know we failed. No question and no issue and we know we were successful.
The first reaction was: That’s impossible! Surely they have some questions when we deliver and they always may be some issues. I suggested: “You find out how to do it. It’s just a simple requirement: “No Questions, No Issues“.
Interestingly, they immediately started thinking how they could deliver according to this requirement.
For example, someone thought: “Ah. Perhaps halfway the Sprint we ask someone to check it out and to see whether he would have any questions?”
I said: “You’re on the right track. Just find out how to do it. The requirement is simple
Actually, I didn’t expect them to be successful in this first Sprint, perhaps after a few. Surprisingly, they were successful.No-questions-no-issues_new
Until now, they always made a ‘demo’: they showed something and the users watching the demo only could watch. That’s boring, causing them to ask boring questions, like: “Why did you use this color?”, or: “Can’t you add this or that?” The ‘Product Owner’ immediately recorded the ‘new requirement’ and the project cauliflower-ed happily on. Other projects call this ‘requirements creep’. It causes the project to drag on way beyond the budget, and makes people easily forget what the project actually was about.

This time however, they asked the watching users to take the mouse and add a record. A rush of excitement was felt by the users: this was the first time in two years that they were allowed to do something themselves. The demonstrator said: “Now you do this and then you do that, and then you see that this happens.” (Sorry, I cannot tell you the actual details of the project).

The users did it a few times and said: “OK. That’s exactly what we expected.”
No Questions – No issues. For the first time in this project.

Is this also your experience?

Niels Malotaux


Share This:

2 Responses

  1. Ray

    I expect there are 2 levels to this.
    1. Worst case, stakeholders have no idea what you are doing. If they are ashamed of this, or they don’t care, there will be no questions, a very bad sign indeed. The confirmation “OK. That’s exactly what we expected.” is however far above this level.
    2. Best case, stakeholders love the idea of your product, and keep thinking of whole new ways to improve it. When starting to reach this phase, the more questions, the better the involvement is. But if you can manage these comments to be given mainly during the sprint, and mainly directed a the product owner, you would be in a sweet spot.

    In our case, last sprint retrospective, we complained about about stakeholders not giving feedback, and started a process you could phrase as “more questions, more issues”.

    1. Interesting to see how my words are interpreted, indicating that what I thought was clear (to me) isn’t that unambiguous for others. Thanks. A learning point for me.

      Incremental delivery is delivering small steps towards something useful. The increment on its own cannot be used yet, only after many increments we may hope to have something useful. This is waterfall in small steps.

      Iterative delivery means that what we deliver can immediately be used or at least checked for usefulness in a real situation, so that we get feedback on the fitness for purpose. We badly need that feedback, as we admit that our perception of their perception of what is needed may be incorrect, so we better check regularly. This calls for short iterations, so that, if we are not at the right track, we have to redo a little as possible.

      I the case I described, the project claimed to “be Agile” and “doing Scrum”. During some two years they had shown a lot of increments, but the users hadn’t touched anything yet. So this was clearly incremental waterfall.
      Their demos until now were just demos: the stakeholders could only observe. I can imagine that being boring, and boring demos lead to boring questions. This made me suggest the “No questions, no issues” requirement for the next delivery, to tease the team to deliver not just a next increment, but to think about what they actually should deliver and how they should present it, to get better stakeholder involvement.

      In my mind , “no questions, no issues” means: you give the delivery to the stakeholders, keep your hands handcuffed on your back, keep your mouth shut, and o-b-s-e-r-v-e what happens. Seeing what the stakeholders actually do provides so much better feedback. After all, when our software is delivered, we’re not there to help them, so we must learn what and how to deliver so that the users can simply use it and don’t need to ask us questions or file issues.

      I agree fully that we should actively be seeking feedback from the stakeholders, but that’s the next step (if we haven’t done this during the sprint already). First we (do our utmost best to) deliver something that doesn’t cause questions to start using, and doesn’t cause issues, because it works flawlessly. Then the stakeholders can say: “Exactly as we said, but not exactly what we need.” That is feedback triggered by what they see, and what we badly need before we’ve done too much into the wrong direction.

      You mention “complaining about stakeholders not giving feedback”. That happens often, and there is no point of delivering something to stakeholders who are not interested or too shy to give feedback. If we don’t get the feedback we so badly need, we have to think of ways to make them “eagerly waiting” for our delivery. We call this “Giving them Juicy bits, to make them eagerly waiting”, see http://malotaux.nl/timeline at ‘DeliveryCycles’.

      For delivery cycles I use the following checks:
      1. What will generate the optimum feedback
      (“What do we have to deliver to whom and why at this moment”)
      2. We deliver only to eagerly waiting stakeholders
      (if they’re not eagerly waiting, we don’t get the feedback we so badly need)
      3. Delivering the juiciest, most important stakeholder values that can be made in the least time
      (to make them eagerly waiting)
      4. What will make Stakeholders more productive now

      We have to make sure that what we deliver is useful for the stakeholders, not wasting their time. Then, I found, they love our deliveries and the communication starts flowing.

Leave a Reply