The following article is a guest post to Zephyr from Rodney West, Senior Consultant and the Editorial Director at Isos Technology. Isos Technology is a partner of Zephyr and is the market leader in solving complex enterprise challenges from Agile adoption and QA to DevOps and they help teams improve quality and speed delivery.
Momentum is a key feature of agile development. Momentum results from the velocity of task completion coupled with a growing mass of features and code. The nature of agile projects helps maintain momentum once projects really get going. This process is fault tolerant, encouraging rapid adjustments to changing requirements and blockers. The momentum of agile projects is self-sustaining when projects are run properly.
But what happens when your team supports a critical production application and you get that dreaded P1 call? What looked good in Sprint planning a week ago now looks like a loss. Or maybe you are using a Kanban board and those juicy tickets you were eyeing are going to have to be put on the backburner.
So is your agile momentum now lost? How much will the jarring context switch derail your development? Unfortunately, you can’t ignore the P1. It will impact your work, and there’s no way around that. Depending on your development environment setup, however, you may be able to make it preserve much of your agile momentum through the P1. Here are some tips I follow when dealing with P1s.
Write it down
The first thing to do is write notes about what you are currently working on. Capture research items, development strategies you were going to pursue and paths you had discounted. You want is a map back to the path back to where you hit pause. You may be thinking that this step isn’t necessary. You probably believe it will will be simple to remember where you left off. However, the P1 may be more complex than anticipated and your brain may be fried by the time it is resolved. Good notes will give you a jumpstart to getting back on track.
Commit, commit, commit
Before you do anything else, even look at P1 related emails, deal with your current code changes. I’m going to approach this from the standpoint of Git (I, like many others, shudder at the memories of Subversion and other version control systems I have used over the years). Whether your code is flawless or in a broken state, you need to retain the current state. Ideally you want to pick up where you left off after the P1. I normally create a new branch with a label denoting “paused for P1” in the title. It may also be worthwhile to add notes on the state of the branch to your pre-P1 notes. And, most importantly, save the new branch in a remote repository. It’s good practice in case something happens to your development machine while working through the P1.
Keep it virtual
I am a huge proponent of using virtualization software for development. Whether you use VirtualBox, VMWare or another virtualization tool, keeping your development sandboxed has many benefits. When faced with a P1, the biggest benefit is the ability to snapshot the virtual machine. Snapshotting the state of your development environment will go a long way towards helping you regain momentum once things settle down, especially if you have to implement significant system changes to work on the P1. Think of snapshotting as committing to version control on steroids.
An added benefit to virtualization is you can create production development snapshots. These are useful for working through P1s, buying you precious time throughout the process. I always maintain snapshots of the current production environment for this reason.
Even if you aren’t using a virtualized development environment, using a tool like Docker can help you quickly change software versions and stacks (and you can still use Docker even with virtualized environments).
These are just a few steps you can take to preserve agile momentum through a P1. Though these tips are focused primarily on individual development environments, they can be expanded to team strategies. Creating a space in Confluence for developer notes provides a central location for pre-P1 notes. Temporary branches in the group repository make it easier for team members not as comfortable with the version control system to back up their code for the duration of the P1. Standardized virtualized developer images can get team members up to speed quickly while working on the issue and help them get back to their pre-P1 state later.
With proper planning, a P1 doesn’t have to be a brick wall in the agile development process. Though momentum may be temporarily slowed, it can be preserved with forethought.
Author Rodney West: Rodney West is a Senior Consultant and the Editorial Director at Isos Technology. He has over 17 years of experience in Software Development, Software Architecture and Technical Leadership in a wide range of industries. His approach to software development focuses on the interaction between corporate culture and development processes in the delivery of software.