Timelines and deadlines have always been tricky for software development. With the advent of Agile software development and Scrum, they may feel even trickier. In this post, I explore how you can move the conversation from time and deadlines to something that matters: delivering value to your customers faster.
Most organizations are still project-oriented and demand reports on delivery dates and timelines. This is necessary to allow various steering committees to make decisions. As a result, teams are spending more time crafting timeliness and writing reports than on delivering value to the customer faster. But to really help organizations embrace what it means to be Agile, you have to help them shift their mindset. In this article, I share my top 3 solutions on how I have helped make this possible.
One of the issues I often face is that projects are way too big. In addition, the corresponding project goals are also huge. As a rule of thumb, the bigger the project, the more complex, unpredictable and hard it becomes due to increasing dependencies. The more dependencies, the higher the need for alignment and therefore “correct” timelines and deadlines.
So, as a Product Owner, if you can help your stakeholders in making projects smaller, e.g. deliver smaller chunks of value more often, the need for alignment will be less. Consequently, the need for timeliness will decrease as well. Breaking down larger goals in intermittent goals helps create focus — for both teams and stakeholders. And this breakdown is likely to inform the Sprint Goals for your Sprints.
Story Mapping is a better way to work User Stories — Jeff Patton
I have used story mapping as a technique to make projects smaller. This technique helps you to slice the project to deliver business value and learn from customer feedback sooner. It also helps determine what to focus on now and what not to With Story Mapping, our team used sprint reviews to show the stakeholders the progress and demonstrate the value already delivered. Per sprint, we would set the sprint goal and investigate if and how much we needed to align with other teams.
Another challenge is that each department — from its own perspective — wants to help the customer. Steering committees are in place to make decisions about the overall strategy. Although most steering committees already challenge the business case and the overall organizational dependencies and benefits, once they approve a project, it then becomes a rat race to get the project done as per the promised timelines. Each project then puts pressure on individuals and teams to deliver functionality as the highest priority. Not meeting these deadlines means you have to stand in front of the steering committee and explain why you are not meeting the promised deadlines.
In these cases, mandate a strong Product Owner who can bring the values of the different stakeholders together. He/she can remind the various silos that the organizational benefit is more important than the benefit of one department. This requires stakeholders to become part of the decision-making process. What features are we building? In what order? By doing so, decisions are then made by people who are actually doing the work or facing the consequences.
I was in a situation with three stakeholders in which each provided 1/3 of the funding of the team, and therefore also requested 1/3 of the sprint backlog to be spent on their wishes. After a couple of stakeholder meetings, I urged the individual stakeholders to provide insight into the Cost of the Delay. Cost of Delay is an indicator of how much money you’re losing by not having a feature in production yet (source). Once explained and made transparently, they all agreed that the next sprint would be dedicated to one stakeholder for the benefit of the organization.
Agile Product Ownership is very difficult because it requires changing the culture. In a Value-driven organization, you want to focus on delivering value, rather than being on time. This means you have to continuously draw attention back to the value we’re creating. Whenever requests emerge for timelines and deadlines, you have to challenge the thinking by asking “How are we delivering value to customers more quickly by doing this?”. The point here is not to get a free pass and build whatever you want, whenever you want, but to accept on a deep level that all talk about timelines and deadlines is ultimately futile in the complex world of software development. No degree of planning, scheduling or setting deadlines is going to make the work predictable. So instead of fixing on dates, focus instead on delivering working software to customers every Sprint. It may take a while to land, but people will start to see that this ultimately reduces the risks of software development more strongly than any kind of planning can do.
You will receive valuable functionality within two to three sprints. Please help me in this proces by providing feedback during the Sprint Review.
And when you do, you can have discussions with the stakeholders on what is most important for a Sprint. What do they need right now?
Managing time and deadlines is tricky. However, as a Product Owner, I have used three techniques to cope with them and help organization unleash their full potential:
I hope these tips help you deal with timelines and deadlines in a more effective manner. If you have any tips or tricks you use to manage them, feel free to share them below.