Stay Ahead of the Game: Handling Unplanned Work in OutSystems Projects
Show of hands… Who loves integrations, the gift that keeps on giving?... And do you know what surprises mean? That’s right, UNPLANNED WORK!!
Obviously, this is a very simplistic take on the matter. If only integrations were the only responsible factor that might lead to uncontrolled scenarios where we end up playing the firefighter role… In reality, I’ve come to discover that Unplanned Work is an established concept that gave a name to some situations that I’ve been going through, which in my case, became more apparent due to work related to a synchronization that needed to be developed in the project where I was working.
But first, we must give credit where credit is due, and it was another member of my team that pointed me in this direction since I’d never heard the term before. Sure enough, it startled my curiosity and made me start researching the subject.
One of the things I’ve stumbled upon was another way of naming it, so instead of Planned and Unplanned, the terms Proactive and Reactive seem more accurate since the word Unplanned makes you think that it’s something we had no idea that was coming.
“Plans are useless, but planning is indispensable.”
The Agile Methodology is a poster for this quote as its mindset sits on continuous change, continuous discovery, and continuous improvement.
Our short-term plan gives us something to work toward given the reality when we are planning it, but as we progress on it, the reality might change, and our understanding of it is bound to change as well.
I’m sure these concepts apply to a wide range of industries, from IT to marketing, as they relate to strategy and how we approach a business/customer need to reach the best possible outcome to address it. That said, when discussing building or supporting application software, the methodology is usually to work from a prioritized list of new features and improvements. We call it Product Backlog, which constitutes de proactive/planned work.
What is Reactive (Unplanned) Work, and Why Does it Matter?
As stated previously, things don’t always go as planned, and when this happens, we must decide how we react.
Reactive work can originate from several situations. People discover a piece of work isn’t as simple as they’d thought, urgent requests or tasks, mistakes made, changes in the team, and bugs reported by customers, to name a few.
What does matter regarding reactive work is how we deal with it and how it will affect the outcome of the product being developed. For example, unless Technical Debt is kept under control, a product will likely become unstable, and its defect rate will escalate.
How to Handle Reactive Work
The Agile Methodology assumes that it’s natural for things to change. The solution shifts and evolves as more and more is learned about the problem it means to address through feedback loops. Priorities change; stakeholders may discover new needs that hadn’t been considered before and discover other aspects that are not as important as they seemed initially. The result of continuous discovery and continuous improvement has to be continuous change.
Nonetheless, unplanned work popping up in the middle of a sprint always brings some level of frustration. And how do we handle it? There are actually quite a few approaches, each with pros and cons, so it depends. There is no single best approach to deal with it.
From the beginning…
The work involved in developing a product is the backlog, which needs to be refined, estimated, and planned into sprints. Each iteration adds or increments features to satisfy the ultimate goal’s requirements. Transparency is of the utmost importance as it’s the only way to determine whether or not the plans are realistic.
Agility is sometimes lost to a fire-fighting mode, and the work that is planned or in progress becomes a blur, and the notion of the amount of it which truly remains becomes indeterminate.
First and foremost, keep calm. Start by examining the team’s communication model. This may bring us a long way in preventing unpleasant surprises.
Some of the tactics to handle reactive work are to squeeze it into the current sprint, put it in the backlog, carry it into the next sprint, establish a planned buffer for it, or have it replace another item planned in the current iteration.
One approach I’ve found that made sense to me, looking back at what I’ve experienced, is the planned buffer strategy with the categorization of the work in terms of Must Have, Should Have, and Could Have. Must Have requirements are essential to the main goal and may only contribute to a certain proportion of the backlog. The remaining comprises Should Have requirements that add value to the goal but are not critical to it and Could Have requirements that may not be aligned with the goal but provide value to it. A 60% - Must Have -, 40% - Should Have, Could Have - is a typical setup. This technique allows for the sprint’s scope to be flexible to unforeseen situations, unessential work may be traded out of the scope, but the main goal remains achievable. Of course, something out of the plan and of all possible contingencies may arise and need to be handled immediately. If this is the case, we’ll need to shuffle to include it.
Picking up on the possible causes of reactive work, two scenarios pop into my mind:
An urgent request which ought to be developed right away
Defects or Bugs
Scenario 1 — An urgent request which ought to be developed right away
Right away means without being refined and planned into a future sprint. Knowing what this entails is crucial to take a moment and think about it.
As I’ve seen it pointed out in a webinar, when the unexpected happens, before we start cracking our heads figuring out how we will get the work done, it’s wise to ask why, thus, helping us prioritize unplanned work. Two questions are in order:
Is the unplanned work really urgent? Meaning, can’t it wait a few days and be considered in the next sprint?
Is the unplanned work valuable? Meaning, is it more beneficial than the work being done currently?
The answer to these two questions might actually be yes. If the work is urgent and valuable, it should be included in the sprint and done. However, this might not be the case, so at the end of the day, the project manager’s intuition will decide how to proceed. Going back to the person raising the so-called urgent work and ensuring they understand the disruption that will cause and that for this to be included, something else may not get done is a sensible way to go about it.
Scenario 2 — Defects or Bugs
Nobody makes mistakes intentionally, and no programmer develops a feature disregarding the specifications of its User Story. So, when defects or bugs are found outside the sprint, they’re almost always a result of miscommunication. This means a lack of transparency which will lead to faulty business analysis, and as a result, the Definition of Ready (DoR) and the Definition of Done (DoD) might be unclear.
So, it’s essential to understand where the defects are coming from and what we can do differently to avoid them. How do we prevent the same pattern from occurring again?
When working with the Outsystems Method, the DoR and the DoD criteria are part of the project initiation phase outputs.
The items on the DoR checklist are defined and agreed upon between the development team, Project Manager, and Product Owner or Business Analyst. This list determines if a User Story is ready to be a candidate to be part of an iteration. When a thorough job has been done describing and detailing the user stories, it’s much less likely that surprises will occur during iteration delivery.
The DoD checklist provides the activities that define the quality of a feature and must also be agreed upon before the development starts since no User Story can pass to User Acceptance Testing (UAT) without every single one of the activities on the list being accounted for.
OutSystems User Story Lifecycle
As depicted in the image above, the User Story Lifecycle evolves through the 3 stages of iteration development, Shape, Build, and Accept.
Outsystems has an online course on The OutSystems Method, helping teams to navigate through everything that building a software application entails minimizing the risk of unplanned work arising in the middle of a sprint.
Conclusion
When it comes to achieving business goals, an alignment between stakeholders and development teams on product vision is indispensable from the get-go. Without it, we’re most likely to be sidetracked with not-so-pleasant surprises and forced to cope with priorities shifting overnight. So the main focus when getting a project off the ground is to ensure that everyone is on the same page and that the team’s interpretation of the client’s vision is correct. Nonetheless, change is bound to happen, so it’s essential to recognize that urgent and unforeseen work may arise, and obviously, it needs to be taken into account.
Surely we can agree that “the best defense is a good offense,” or in this particular case, a proactive attitude towards minimizing the chances of unplanned work surprising us. Scrupulous attention to the DoR and DoD goes a long way in preventing it.
Of course, we understand that it’s not possible to eliminate the risk altogether. When necessary, the situation should be analyzed by all interested parties to devise the best strategy to deal with whatever surprises may arise.
Like this article? Share it:
