If you could only ask one question from your Scrum Team, which one would be the most powerful?
You may ask this powerful question next time you wonder if your Scrum Team will be able to deliver value in each Sprint.
I often ask one particular question to Scrum Teams who are in trouble. And often the outcome has turned out to be a game-changer.
The first time I realized the power of that simple open question (which I will reveal in a second) was in the early days of ‘agile’. Scrum was not yet considered a de-facto framework for agile ways of working.
I have used the question regularly ever since. In this article, I will highlight two real-life stories that show the huge impact it had on the teams.
Story #1
I felt inspired to get some hands-on experience with Extreme Programming [1] and Ken Schwaber’s first book Agile Software Development with Scrum [2]. I deliberately aimed to combine the best from all worlds — not just conform to one agile ‘bible’.
I combined the misc. methodologies/frameworks in a small Start-up where they hired me as their first agile project manager.
We had a group of 10 developers and a business analyst.
The company was pretty successful in terms of financial growth.
But there was one huge problem that puzzled the formally authorized development manager, and he no longer had sufficient trust in the team:
He couldn’t see any progress of the Development Team on the execution of their new digital strategy.
The development manager was eager to implement the new strategy as soon as possible since this small Start-up had a huge potential to become a world-class leader in what we today know as cloud technology. We knew we had to upgrade and optimize parts of the infrastructure to be able to adapt to a new technology platform and the next generation of code. And we planned to scale from ten thousand end-users to millions.
The Powerful Question?
Hang on…
I was new to the company.
To be honest, I could not figure out either what they were doing and why they were doing it. It felt a bit weird because I have a technical background.
Then — and here it comes… I curiously asked the Development Team one day after the Daily Scrum [3]:
“What will you be able to demonstrate to the Product Owner in a few weeks from now?”
….
Silence.
…
Then they replied: “Nothing.”
I appreciated their honest answer.
Working Software — especially to show progress
We agreed that I should work with the team to find out what it would take to show at least something in a few weeks. We asked ourselves: How can we regularly show our results to the Product Owner and the Development Manager? Preferably some executable software.
To maximize learning, we did daily Retrospectives.
We learned the hard way that we sometimes needed a certain kind of output from a feedback loop that we can only achieve by a team producing and showing working, integrated software or products.
The Scrum Guide and the Agile Manifesto for Software Development’s principles recommend to “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”
Over the years, I have experienced how powerful that principle is!
Some teams can deliver Potentially Shippable Increments [5] in every Sprint. But new Scrum Teams often struggle with learning how and why to do that. Their architecture stack is apparently not suited for this, or the legacy code is considered too complicated, or their test environment sucks, or the Product Owner does not find it feasible to release the product with so few features, or… [insert more excuses yourself].
Many obstacles are real and can be fixed to enable the team to deliver every sprint. This is one example illustrating that Scrum is difficult to master.
But also some perceived obstacles can block a Scrum Team’s ability to deliver — or at least to demonstrate — value to stakeholders often in a development cycle.
Getting back to the team in my story:
We needed to rebuild the stakeholders’ trust in the Scrum Team.
So, you may also try to ask this powerful question next time you wonder if you will be able to deliver value in each Sprint.
The Game Changer
It turned out in our case that our Development Team was ‘off-roading’ and not working on the new infrastructure and platform renewal (i.e. the digital strategy), as most of us thought we had agreed.
- A few developers were developing a key component at the OS (Operating System) level that was already available as a commercial solution
- The slow progress of that component was blocking the work for the rest of the team
- But no one had wished to convey that out in the open
Our external architecture Advisor gently and respectfully worked with the team. They soon acknowledged that a person’s own preferences should not be an obstacle for the rest of the team’s ability to work and deliver.
So, the game was quickly changed and a software development strategy based on commercially available key components was agreed upon instead of a few persons ‘re-inventing the wheel’.
The bottleneck had been identified and the team removed it themselves. We could soon show working software that demonstrated a visible increment of the new platform.
Today that small Start-up has emerged into a very successful full-grown company producing cloud solutions that delight their customers.
The success of the company was 100% owned by the team’s ability to learn and adjust.
Story #2
Fast forward 10 years. As said, I have used the question regularly ever since.
Why I ask it again and again
I recently asked the same question to another newly formed Scrum Team in another context, because it puzzled me and the Product Owner that it seemed difficult to ascertain what the external supplier (part of the Development team) was actually working on.
“What do you think we can demonstrate to the end-users or stakeholders in a few weeks from now?”, I asked.
…
“Hmmm.. it will take three months before we can show anything that works”, they replied.
…
As always, I appreciated their honesty.
After a short dialogue, it became clear that they were developing something quite different from what the Product Owner expected.
To our big surprise, it turned out once again, that a Development Team (including the external supplier) wanted to re-invent what already existed as a commercially available solution.
But in this particular case, the Product Owner changed her mind. She accepted their suggested solution as it could be customized more easily, compared to the standard solution.
It was also agreed that the supplier would not demo any ‘executable software’ early on, but that they instead would show intermediate results such as diagrams.
However, the point was that…
…it became an informed decision by the Product Owner to decide the type of product that had to be delivered (see e.g. the Scrum Product Owner pattern here).
The Development Team is responsible for how to develop (see Scrum Pattern Autonomous Team). The Product Owner decides what Product is needed and prioritizes the Product Backlog in Delivery Order.
Learning
A Scrum Team struggling to deliver what stakeholders are expecting might be working in a complex environment without being able to determine a correlation between cause and effect [4].
But in general, a simple OPEN question — such as the one covered in this article — can turn out to be all it takes to find out how to proceed with problem-solving within a Scrum Team.
Ask for example “When can you show something that is working and fully integrated?”.
And maybe also ask when we as a team can deliver a potentially shippable increment [5]. Ask, and be prepared to be surprised. Everything can happen:
Open questions like this are powerful because they invite people to think and re-think in a positive and constructive way. People are free to opt-in, no enforcement. Most often teams get motivated and inspired to accept the challenge and get ideas of what it takes to make it happen.
Further, this question emphasizes the huge impact of a feedback loop that is only achieved by showing working software to the Product Owner and stakeholders frequently.
Summary
In this article, I highlighted two very different teams in very different companies who had for some reason chosen to go their own way without the Product Owner’s knowledge. We can often manage to get out in the open the many different causes as to why teams are unable to deliver software — or products — in an iterative and incremental way.
Just by asking that same question.
It directs us to the real cause that can then be fixed.
“We can’t solve symptoms” (Woody Zuill)
References
[1] Beck, Kent, “Extreme Programming Explained”, 2010
[2] Schwaber, Ken, “Agile Software Development with Scrum”, 2001.
[3] Scrum Pattern: ‘Daily Scrum’, http://scrumbook.org/value-stream/sprint/daily-scrum.html, accessed 26-Sep-2020
[4] Snowden, David J. & Mary E. Boone, A Leaders Framework for Decision Making, 2007. https://hbr.org/2007/11/a-leaders-framework-for-decision-making, accessed 26-Sep-2020
[5] Scrum Pattern: Regular Product Increment, http://scrumbook.org/value-stream/regular-product-increment.html, accessed 26-Sep-2020
