Article summary
I recently worked with a client who was extremely frustrated with deadlines that seemed to come from nowhere, made no sense to him, and didn’t fit with his idea of Scrum as a methodology. He believed that according to Agile/Scrum, “the business” was not allowed to give deadlines to development teams. Scrum, he believed, allowed for developers to decide when work would be completed–and business people would just have to deal with it.
Does this experience sound familiar? It doesn’t have to be this way! Two important concepts guide this conversation:
- First, Scrum doesn’t say anything about communicating deadlines. Instead, the Scrum Guide describes a way of working to accomplish valuable work for an organization.
- Second, a team working on delivering code (or any other output) is only a part of the picture. Business objectives have to be met, and they often come with constraints that need to be recognized.
If you find yourself leading a team that uses Scrum to argue about deadlines, here are a few things that might help.
1. Don’t make it an “us vs. them” situation.
Avoid the tendency to fall into this kind of mindset. It usually puts groups at odds and sets up conflict that leads to political battles and poor working relationships. In the big picture, we are all a part of “the business” working for the same goals. Instead, keep your team focused on the outcome you are trying to achieve.
2. Figure out what you can do by the requested deadline.
Focus on understanding more about why the deadline exists and what your team can contribute to reaching it. Look for ways to make compromises that are appealing and that make sense for the way your organization works.
3. Consider that software development is only one part of the company’s big picture.
Constraints are real. Sometimes they are deadlines, sometimes they are budgetary, and sometimes they are legal (among others). Development teams have to recognize the constraints of their organizational partners, company, and industry and determine how to work within them. Your job will be to understand those constraints and communicate their importance to your team.
Remember, the Scrum Guide Is Just a Guide
People sometimes want to follow the Scrum Guide exactly as written or strictly adhere to the process and roles they learn in Scrum training. However, I’ve found that teams and organizations get the best results when everyone involved feels responsible for success and molds Scrum to help them do just that.
Ready for more? Read Agile Misconception #2: We Don’t Need Documentation.