Do you have deadlines that you set for your staff or vendors when something needs to be done by a certain time? If no…. then this post may not be for you and we should be having a totally different conversation. I am going to assume you answered “Yes” or “Yes, sometimes,” because who hasn’t sent an email asking for an EOD response to something?
Let us imagine a scenario where you have a project, we don’t care what type or what is being worked on, it is just a project with an estimated timeline to completion of 6 months. You are a major stakeholder on this project, the primary customer or manager. A lot of the decisions fall on your shoulders.
We are a couple of weeks in and the project manager needs you to make a decision. He/she gives you a couple of days to think about it and has a set meeting to go over it, asking for a decision during the meeting at the latest. You are sent an email to remind you of the meeting and the need to make a decision.
You can A) Prepare to make a decision (Make arrangements with the needed people, etc,), B) Ignore him/her and not think about it again, or C) get offended about being told you have to make a decision by someone beneath you; you will make your decision whenever you feel like.
If you answered “A”, congratulations! You have a much higher likelihood of making your 6-month deadline on this project.
If you answered “B”, please re-think this and make some time. Delaying some decisions may cause a delay in the project. Lots of little delays can derail a project’s timeline.
If you answered “C”, please find a new job. You shouldn’t be a manager and your staff will suddenly appreciate you more when you quit.
Timeboxing in Agile
A lot of Agile frameworks use something called timeboxing. These are basically set amount of times to complete tasks or make decisions. The purpose is defined, and a limit or duration of time is set. You are not allowed to go over the set period of time. Now, you don’t have to use timeboxing, but it can provide a consistency that people will learn and adapt to. This is the time we have, do it and get it done within that time.
Timeboxing actually is the source of a lot of complaints in Agile, causing people to believe that Agile is not very agile as some of the methodologies require strict adherence to timeboxing. By complaining about this, you might as well be answering “C” to the question in the prior section. (“How dare you be told that you have to make a decision at this specific time!”)
One important part of timeboxing in Agile frameworks is that it creates a structured and repeatable system. You know in advance that the planning session is coming up in one week. You know in advance that it will last up to four hours and only four hours. If you cannot prepare for it, Agile isn’t the problem.
It is not inflexible for the sake of being inflexible. It is inflexible to help create decisiveness and propel the work forward. If you made the wrong decision, there is an opportunity to change in the future or in many cases have other components worked on while you investigate some decisions more for the next iteration. That is part of the adaptation process.
The point being, you have to be proactive. You have to think about things ahead of time and what you would like to cover in the planning session. This may require meetings and discussions with other people prior to the planning session. The beautiful part is, you already know the meeting is going to happen and you have time to prepare.
I get it, people are sometimes busy. You probably have other duties. Well, this is a duty that is just as important as those other duties. You may have to delegate out some decisions. You may have to negotiate what is being worked on next within the project. But you cannot ignore it, and you cannot be offended by being told you have to do something.
Flexibility, to a point
A gymnast, graceful and agile. They can move and flex in ways most ordinary people cannot. But there will be limits to how flexible they are. The muscles can only stretch so far, the bones cannot fold into each other.
If you take away the bones, it will make the gymnast pretty flexible. They may not be able to move forward or backward very fast and might resemble a blob on the ground, but you can pick them up and fold them a couple of times to show off their flexibility. They lack structure. The very thing preventing ultimate agility by the gymnast is the very thing that is allowing the gymnast to use the agility they do have.
The same goes for Agile frameworks. They need structure, they need bones. Many use timeboxing to help provide that structure. That isn’t the only way, but it is probably the most common way. If you take away that timeboxing, refuse to make or participate in set duration decisionmaking, you are taking away the bones. I hope you have something to replace it with.
Agile will bend for you. Agile will flex and be forgiving (perhaps to a fault). But it needs the structure to help propel it. Getting rid of structure in the hopes of making it more agile (agiler?), creates a whole bunch of other issues.
Too many problems arise when companies decide they don’t want to adhere to the “strict” timeboxing or other structure put in place. If it falls apart, you can’t blame the Agile methodology. You have to put limits in. Infinite flexibility just won’t work.
I get it though, my initial thoughts on Scrum when I first learned about it years ago were along the lines of, “that seems strict for something they call Agile.” It wasn’t until I got onto a project where every time I tried to get decisions and set deadlines for those decisions that I understood why. If this was your initial thinking, I would strongly suggest giving it a second thought. I know Scrum can be dogmatic, and it may not work for everything – but forcing decisiveness may just be what you need.
Images from https://www.pexels.com