Let's be honest, being a stakeholder around an Agile team is hard, especially when Agile is unfamiliar to you and/or your organisation. That's a situation we see a lot - which is why we've developed a practice to train the executives who have to cultivate an Agile culture and work with Agile teams.
(We won't rehearse the benefits of Agile here, if you're not on board with that you might want to start here).
Here's one quick thought from that practice that might help: asking different questions.
Typically the questions you might ask to give yourself confidence that something good is going to be delivered would be something like these:
What Am I Going To Get?
Expressed as a functional spec or wireframes or often, these days, a working prototype built in something like Marvel.
When Am I Going To Get It?
Expressed as a fixed date when 'it' - the finished product is going to be perfect and 'launched'.
How Much Is It Going To Cost?
Expressed as a line on a budget.
All of these supplemented by regular sessions asking:
How Complete Are We?
What percentage is the product complete? How are we doing against schedule? How are we doing against budget?
These are not stupid questions. They're entirely reasonable. In many circumstances they're good ways of managing a project. It's just that Software Is Different (which is why Agile exists in the first place) and if you make an Agile team answer these questions you'll stop them being Agile. You'll undermine the very thing you're trying to develop. Your questions pull in the wrong direction. It's not just the delivery team that has to change, it's the team around the team. It’s you.
Just these four questions will make you (a bit) better at agile
1. What Does It Have To Do?
Instead of asking What You're Going To Get and looking for every detail to be decided upfront, come up with a small set of things a successful product will have to be able to do. Ideally it'll be a set of genuine user needs. When we worked with Sky on Sky Kids we boiled it down to about 10 things - you'll have to be able to log-in, it'll have to play video, and so on.
Leave all the detail for later. Leave that to be solved by the team, working with users, making the real thing.
2. When Will We Have Something In People's Hands?
Instead of asking When Am I Going To Get It, concentrate on encouraging the team to get something in front of users really, really quickly. In a few days or a few weeks. You need to steer them (and yourself) away from the binary idea that there's an 'it' that will be delivered on a magical day. It won't exist the day before and then suddenly it'll arrive. What you want is for them to get something into the world really quickly and then iterate towards a successful product.
3. Does This Make Financial Sense?
Frankly, asking How Much Is It Going To Cost is not an unreasonable question. You have budgets. You have accountabilities. But, because Software Is Different you have to build more tolerance into your process and you have to make sure your business case works to those tolerances. If your business case makes sense if the product costs £1m but doesn't if it costs £1.2m then don't build it.
4. What Can You Show Me That We've Done?
Building software is not like running a bath. If you've half filled it in 2 minutes you can't expect it to be full in 4. Knowing that you're '50% complete' does not tell you whether you've been making the right stuff or that the last 2% of the project is going to take twice as long as the first 98%. The best question you can ask is 'What Can You Show Me?'.
Ask to see a working thing. If there's no working thing yet, ask to see the insights that will inform the working thing. Don't be satisfied with insights for very long. Those working things will give you so much more confidence than a percentage on a dashboard. And then you can apply some judgement and common sense. If you know the answers to What Does It Have To Do? and you've got five out of the six of them working then you're in good shape. (We have more thoughts on this aspect of things, but that's another post for another day)
If you ask those questions of your team, if you show them that's the stuff you care about, if you can get your stakeholders caring about those things then you'll give Agile a chance to work for you. And, frankly, if you're leading a team that way then, just between us, you'll find that they probably have pretty good answers to those questions you were burning to ask at the start. They'll know, roughly, what it'll be, how much it'll cost, when you'll get it and how it's going. Just don't make those the questions that rule their lives.