Common questions teams ask
Agile Team’s FAQ
Quick answers to some of the most pressing questions in agile product development teams
In this post, I’m going to answer questions that have been raised by agile (product development) teams that I have been working with within the last couple of years. Since the questions seem to come up over and over again, let me record some of my answers.
In a complex world, all the answers depend on the context in which the preceding question has been raised. So, feel free to take my answers as an impulse and not as the one and only definitive answer.
The questions I am dealing with follow no particular order. I think I am going along with what intrigues me. If you want to raise a question yourself, feel free to drop a line.
Question: What is the right process for us?
Answer: There is no universally “right” process. A “right” process is foremost an effective process. Which means it delivers value. So, what value does the team want to deliver, and to whom?
After you’ve got this clear, keep your current process but alter it slightly.
First, make the work visible. Meaning, make the work flowing through the process visible (e.g. by using a board).
Secondly, make the moment at which you start work as explicit as possible. It’s the teams’ decision to start work. When is this decision being made?
Thirdly, make waiting times explicit. When do you add value to the work item and when is it waiting for someone or something. Since waiting time is bad for value-generation you might want to keep an eye out for those non-value-adding times.
That’s it. Now collaborate, deliver, reflect, and improve.
Question: What is the first thing we should aim for if we want to improve?
Answer: Of course “it depends” and often teams have a quite good hunch about what needs to be improved. However, there is one thing that teams always need to strive for: Speed!
Teams always need to be fast, act fast, deliver fast, and learn fast. That’s why teams need to monitor and improve their speed.
I’ve often argued with colleagues if “building the right things” should not be the first priority. I doubt it.
First, it is almost impossible to find “the right thing” in the first attempt. Which inevitably leads to several approaches and trials if you will.
Secondly, even if you are super lucky finding the right thing to deliver does not include that your team is capable of delivering in an appropriate amount of time. This yields the risk of having the right thing but too late — which basically is the wrong thing.
Moreover, you usually need the right thing more than once which again makes fast delivery and fast learning necessary.
Being fast leads to fast feedback which enables fast learning. This is powerful. On top of that, only fast feedback allows you and your team to feel the flow, a sense of accomplishment, and meaning that what you do is valuable.
Speed matters most. Full stop.
Trying to move fast will make a lot of impediments visible that stifle your progress. That is something to aim at when your team wants to focus their improvement effort.
So, what is speed and how to measure it?
Try to systematically measure the time it takes to get something done.
How long does it take on average …
- to deliver functionality?
- to close a ticket?
- to make a decision and act on it?
- to find the right thing to build?
and so on.
Then analyze why it takes so long, find ways to speed up, change a tiny bit, and follow up on your measurements. Making those numbers explicit also helps to change things that are not entirely under the teams' control.
By looking at the questions above you realize that I encourage every team to broaden the perspective on speed beyond just “closing tickets”. If you are in doing the wrong things fast, you are obviously still doing the wrong things. Being fast in finding out what to do in the first place in that sense is also “speed”.
Question: How do we prioritize our backlog properly?
Answer: The best way to prioritize is to avoid it. Only prioritize when you can deliver the started work item in one fell swoop from start to end. This includes taking all the dependencies into account. Done means done! If you don’t have the capacity to start new work, don’t waste what you don’t have on prioritization. As soon as you can start work pick, don’t prioritize! Pick the tiniest work item of value from the backlog and deliver it. Only after you are done, pick the next work item that is by the time of the decision the tiniest thing of value in your backlog.
This is easy, fast, and fun. And it generates a lot of healthy side-effects as described above.
That’s the only reasonable way to prioritize product development work where uncertainty is your everyday companion.
If you want to read a more elaborate explanation of why I would give this answer read here a longer answer to this common question.
Question: Scrum or Kanban?
Answer: Honestly, it doesn’t matter.
This is a commonly asked question and I understand that the lure of an answer sparks the hope of ‘doing it right’ the first time. And I know, the discussion about whether Kanban or Scrum is the right approach for a team can result in pseudo-religious fanaticism. Since it’s not worth adding fuel to the fire I like to gently direct the teams’ attention towards the similarities of both management frameworks and what both aim to achieve.
Kanban and Scrum support teams getting things done. They both aim to limit work in progress, separate the reflection and planning from the execution, and install frequent feedback and learning cycles.
I say “it doesn’t matter” because there are so many biases, hopes, and implicit assumptions involved when trying to find a definitive answer to this seemingly straight forward binary question that it can’t lead to a satisfying answer. Especially not when the team members asking this question have experience with one of the management frameworks. Because at this very moment you don’t talk about Kanban or Scrum anymore but about the team members' individual experience on Kanban and Scrum. I genuinely don’t believe that exposing all those experiences (often loaded with frustration and anxiety) adds value to the attempt of helping teams starting their collaboration.
Every team needs a phase of scouting and refinement on what they want to work on next. They need a deliberate decision about which work items they start working on and on which work items not. They have to plan and break down the work items into tiny chunks. Moreover, every team needs to work together collaboratively in order to deliver value. After that, every team needs to generate resonance and feedback on that particular deliverable and on their overall ‘product’. When the defined amount of work is done teams need to inspect, reflect, and improve both the product itself as well as the process and the way of collaboration that led to that product deliverable.
This is like the meta-process of empirical product development work. Teams need to find their own interpretation and translation of that meta-process into their working environment. Agile Coaches can support the team on that interpretation and translation.
Management frameworks like Scrum and Kanban collect principles and practices which can be a good source of inspiration. But they don’t take out the necessity of the collaborate-deliver-reflect-improve cycle every team has to run through constantly.
Underlying Assumptions
- We are talking about the team level, not about the whole organization
- The team knows what they are responsible for and what they want to achieve together
- The team knows who their users and their customers are (maybe those roles merge together) and how they can get in touch with people in those roles to gain feedback
Question: How do we estimate the items in our backlog best?
Answer: Clarify why you want to use estimations in the first place and then avoid estimations in almost every case. :)
Teams tend to ask “how” questions before the “why” is answered satisfyingly. It’s human to assume that the solution to a problem is already crystal-clear and it’s only a matter of how to bring the solution to life. However, often teams value when they are brought back gently to the problem they aim to solve — especially if this ‘step back’ saves them an awful lot of unnecessary and wasteful time spent.
When it comes to the estimation of product backlog items there is a massive amount of time and energy to be saved. With all the experience in agile product development out there it became more and more common to avoid estimations. The #noestimates movement collected all the good reasons why backlog item estimations are of no value most of the time. This is true for every form of estimation (story points, people days, complexity, …).
Despite the common expectations, estimations don’t provide substantial benefits when it comes to solving common problems like
- Accurately determine when a certain amount of complex work will be done
- Avoid overloading a team of product developers
- Project the delivery capacity of a team in the future to anticipate what they can deliver in the future
- …
There are better ways to deal with these problems and I will only drop some references here, to get you started on a path that leads you away from the dysfunctional practice of product backlog item estimation.
- Increase overall predictability
- Answer “When will we finish?” with data
- Dive deeper into “no estimates”
- Make visible what amount of work needs to be done
- Managing backlogs of several teams and keep them aligned
The only immediate benefit I can see in estimations is that they create dissent and that’s good if the team yields trust and can use the dissent to develop a shared understanding of the backlog item (What are we aiming at? What do we think we need to do? What do we have to learn to get it done?). If you are looking for a lightweight way to create this kind of positive dissent you can take a look at the ‘magic estimation’ technique [the link is in German only, sorry].
I know that quite often it’s not the team itself that wants to estimate all the items in a backlog but rather stakeholders or managers that shape the working environment of the team. Although not being easy, it’s helpful to talk to those people and understand what problems they try to solve by requesting estimations. Odds are good that you can provide a solution that is more appropriate than estimations.
