Is Timeline Still Important in Agile?

I'll offer this disclaimer before I begin - I think Agile is great. I think in many cases, the traditional way of managing waterfall projects on a strict timeline, planning out 2 years' worth of tasks in advance for a detailed project, or strictly following dependencies, is going the way of the dodo. This is not going to be true in all situations (there is a pretty good case for dependencies when building a skyscraper, so you don't end up starting from the top and working your way down), but in a world of constant change and uncertainty your average program benefits from a healthy dose of agile.

That being said, whatever happened to care about the timeline? All too often in agile, the work gets broken down into 2-week sprints. Anything outside of that 2 week time bucket is in this nebulous other dimension called the backlog. With experience, we can try and ballpark when certain milestones might happen, or when features might be delivered. But time stands still in the backlog. Other things come up that pull our attention away from those initial ballpark delivery timelines. What started as a 60-90 day estimate becomes much longer, because we lose sight of how our sprints align with the bigger picture and schedule of when things need to be delivered. The reality is that we still have to deliver things on time, and business leaders are held accountable to whether their business unit delivers things that advance a company objective, are complete, on time, and on budget. Imagine your team is planning to sponsor a tradeshow (or actually planning a tradeshow), and delivers everything in two-week sprints with a ballpark estimate on when everything should complete. That tradeshow has a specific deadline, and if you miss that, all the work leading up to it is for nothing. Telling the attendees that your team is agile, and it will take another 2-week sprint to have the event ready for them is not going to result in many happy customers (especially when they get hit with the airline ticket change fees). Even in software development where agile is most common, the timeline is still a huge factor in measuring success. You may have analysts and shareholders anticipating product delivery. If the Q1 deadline isn't met, which leads to underwhelming earnings, you will have unhappy shareholders and unhappy leadership.

So what should we do? Well, it is important to recognize that there needs to be a balance. Sometimes this will skew a bit more in favor of the agile method, and sometimes we will need more strict adherence to schedule. But ultimately most will have some degree of a hybrid approach to delivering. At times these two opposing methods can feel a bit like 2 pieces of a puzzle that don't really fit together, but there are a few things we can do to smooth over the gaps where agile and waterfall meet.

1) Create a roadmap, a timeline, or a plan. Well duh, you're probably thinking -- that was in the title of the article. But it's easy to get so caught up in "doing" that we cease to be strategic. The plan doesn't have to be detailed with tasks down to the minute, but having a basic framework to work against is important. Having a clear roadmap to success and a basic schedule helps keep everyone on track, and you can measure your progress against the deadlines.

2) Pause to take inventory of the work you are doing. Keep in mind that there is a difference between being busy and being productive, and we should be taking measures to ensure that the things we do are helping advance a roadmap item on time. Refer back to your plan, and ask yourself "is what I am doing contributing to milestone X?" and "what are some measures I can take to make sure milestone X happens on time". If what you are currently doing doesn't line up, this is likely the point at which you should change direction and pick something that does meet those criteria.

3)Try breaking down your sprints into smaller time chunks. At CORAS we like to break down the items in our sprint by day, which seems to help with execution. Even in a time span of 2 weeks, it can be easy for items to become the defacto "backlogged", as some of the items take up more time than others. Before you know it, you are at the end of the sprint and have a bunch of smaller outstanding tasks you had hoped to accomplish. Taking all the items you would like to do in a sprint, and trying to allocate them by day not only helps keep you on task but helps with sprint planning as well. If you have included too many items in a sprint and don't have available days/resources, planning by day helps make those sprint objectives more realistic.

4) Hold your teams accountable. If teams sign on to deliver an item in a certain amount of time, hold them accountable to that delivery date. Honoring time and delivery commitments keeps everyone happy - especially the customer. Can you imagine if Amazon suddenly started missing its 2-day Prime shipping commitments on a regular basis? Obviously, I'm not saying every project can be done on a 2-day delivery cycle, but the important piece is setting a goal, sticking to it, and holding your teams and team members accountable to the SLA they've set.

5) Keep your eye on the prize. After you truck along with steps 1-4, it's important to not slip back into old habits. A good way to do this is by keeping a goal-oriented focus, staying aligned with those goals. In your morning standup meeting, the question should not be "what are we doing today", the question should be what are we doing today that advances Goal/Roadmap Item/Deadline X. Keeping that big picture focus and eye on the horizon helps align your steps on the smaller things.

In conclusion, the timeline and schedule are not dead - far from it. If you are making some Agile program soup, you are going to need a sprinkling of some of the traditional practices to be successful. Create your plan, but don't obsess over every detail of it to the point where it becomes inflexible. Hold teams accountable and measure success against your milestones and timeline.