Project Deliverables or KTLO: Planning for the Unplannable

We failed to meet our commitments again. We started off our sprint with a well-intentioned and well-thought-out goal of getting the requested project work completed. Unexpectedly, though, that darn website went down and we found ourselves shelving project work for the sake of keeping the lights on.

By the way, it happened in the last sprint too. Our burn-down chart looks more like a T-square and we can't seem to get a solid read on any sort of team velocity.

How much can we commit to you ask? Don't ask; we don't know. It varies from week to week.

Why isn't the project getting completed in the timeframe expected? Well, what would you rather have; a new feature created or current production up and running? And yes, we switched from Scrum to Kanban and that didn't solve anything. We just don't do retrospectives or demos anymore.

Do these conversations sound familiar? In a perfect world, we have a dedicated and conscious separation between development work and operational support. In a perfect world, there are more formalized hand-offs involved and well-staffed (and paid) support environments. And in the 'rainbow and lollipop' world of delivery, developers are never, EVER asked to provide continuous KTLO support to a delivered product.

Does anyone else NOT live in that world?

From a purely Agile perspective, one could argue that it's more adaptive and lean to bypass the varied levels and stage-gates of ITSM support and go straight to the maker to get quick issue resolution. Trim the ITIL fat so to speak.

Ask the developer and see if that's his ideal scenario.

Reality is that many people live in an increasingly blurred line between development and support. You don't have to dwell within a self-defined DevOps team to feel it. Sometimes due to financial constraints, project size, project type and even personal preference, teams will find themselves performing ongoing live product support while balancing prioritized project deliverables. Uptime predominantly trumps new feature releases.

So how does a team successfully achieve that balance between support work that comes in by the hour/minute/second and delivering value on committed project work?

First, let's assume that every organization, project, team and individual is different. Not too far of a stretch, right? Also understand that 'value', while not a financial capitalization item, INCLUDES the support work taking place. Far too many teams report their time as of little or no value because they are providing uptime support. Keeping it working is important too.

That being said, below are three suggestions that could help teams plan for the unplannable.

1. Have a good read on who all of your project requestors are and create a strong, open line of communication.

There is nothing worse for a project sponsor than to get last-minute indicators that their deliverables were placed on the back burner days or weeks ago due to someone else's differing priorities (aka KTLO). This involves a dedication from the team to be highly open and collaborative with everything. Ceremonies such as daily standup become increasingly more critical because change takes place so rapidly. Some teams have gone to two standups a day because mid-day the work landscape understood at 8:30 AM could completely reverse by 1 PM or sooner. The work getting shoved aside needs to be communicated quickly and openly to both the team and the stakeholders.

As a team, make a dedication to a highly visible and communicated body of work. Don't be afraid to be innovative with when and how it's communicated. Then adapt as needed.

2. Know where your time goes.

Embrace that when you're considering taking on project work, you don't really have 8-9 hours a day, 5 days a week. It's the reality of the world you live in. Don't ignore it hoping support work will never happen to you this time around; embrace it! Get real about your actual available time and be agile with how you use it.

For example, get to know the velocity of your support work. Start by dedicating 3-4 hours a day to nothing but support work. As a team, agree to it. If you don't have support work during that time, do project work, but start somewhere. From an individual standpoint (or team if agreed upon), track your unplanned support time. After iterating that scenario, over time you should start to get an average (velocity) of what your support hours really look like against project hours and can adapt your availability accordingly. Now you have real information available to you that will assist with communicating what your project deliverable opportunity is to the people who need to know.

Now I know, something could come up in support that pulls ALL of your project availability consistently. If that happens sprint to sprint, release to release, you have larger issues. Perhaps we should start talking about code reviews and architecture at that point.

3. Quality (code reviews and architecture)!

If you tell executives that you can't complete their high-priority project work because you're so busy supporting the work you did before, they will inevitably ask why there are so many bugs in your own work since you are in constant support mode. Now, there's a comfortable conversation!

Sure, you can tell them (if you are brave enough) that no software is perfect and it will always need support. The paramount to agility though is quality. You're not agile if you regularly waste time supporting poorly written (or poorly tested) products. Everything should be testable and tested. After testing, it should be approved by someone who actually cares if it's right. This includes periodic code reviews, architecture reviews and making sure we are providing high-quality products. The reality is that if we are in constant support mode on our own product, time spent on support isn't the (only) problem. Quality is. Measure twice; cut once, as the saying goes. Don't have time for thorough QA? Then set aside 5-6 hours a day for support...you're gonna need it!

Wrap this all up and we see that quality of work, knowing and quantifying where time is getting spent, and communicating openly and honestly with the people who need to know helps create a much more manageable atmosphere when it comes to development and operational support coexistence. Sure, you can spend time talking about how you visualize your workflow and address support ticket prioritization. Those things will help short-term, but don't address larger concerns related to setting expectations while creating actual working software.

Executives need information to make strategic decisions. Knowing that agreed-upon priorities are getting shoved aside every couple of weeks is just enough info to set an executive off.

Openly identifying and communicating roadblocks and reality checks gives leaders insight into your availability and the reality of the world you live in. Maybe they can help. Knowing and tracking where your time is spent gives the team the fodder it needs to have open and honest communication on project-level availability. It also helps us to see if we are spending too much time in support and need to increase our attention to quality work. That too can be prioritized.

Everyone would like to be more proactive than reactive. However, development teams providing production support live in a reactive world. By focusing on these three items, you will help your team to be as proactive in this mostly reactive environment as possible.

It's true, you can plan for the unplannable.