Agile Infrastructure Projects - Lessons Learned
by Mishkin Berteig
I’ve worked as an agile coach on three infrastructure/maintenance projects in a row. One was a software/hardware upgrade, one was implementing agile for a defects/enhancements team, and my most recent was a data warehouse decommissioning project. In all cases, the interesting part for me was taking the basic principles of agile and applying them in a way that works when not doing new product development. Here are some lessons I’ve learned:
1. Figure out what is going to deliver value (usually cost savings). In the case of infrastructure projects, one is usually focused on cost savings. Find a way to tie your work items directly to cost savings. You need a good financial model to do this. Mary and Tom Poppendieck talk about this a little in their Lean Software Development book. In the decommissioning program, there was a very explicit dollar cost associated with disk space and cpu utilization. Every user/MB decommissioned saved a measurable amount of money. As well, it allowed us to easily prioritize our backlog.
2. Focus project/program organization more on Lean principles than agile. A good understanding of queuing theory will go a long way to helping with throughput. In a team doing defects/enhancements work, the small pieces lend themselves well to certain types of streaming through the team. Iterations are not necessary to chunck work. Instead, iterations become checkpoints solely for process reflection.
3. Technical infrastructure projects can benefit greatly from automation. Test automation including test generation can sometimes be possible. Automating parts of a regularly repeated process that is used for every work item can be extremely beneficial for increasing speed. In the case of the decommissioning effort where every database table needs to be considered separately and where they all go through the same process for decommisioning, there are many opportunities for automation. The project/program/team can invest in doing this automation to great benefit to NPV.
4. The basic axioms (We are Creators, Reality is Perceived, Change is Natural) and disciplines (Empower the Team, Amplify Learning, Eliminate Waste) still apply. Even though it is not “new” product development, the creativity of people is essential for problem solving, and finding ways to do the work faster. Stakeholders still need to have their perception of reality acknowledged, and the teams still has to do constant checking to make sure they are on track with that perception. And of course, things are always changing including priorities, our understanding of the work, resource availability etc. Having an empowered team makes short work of many obstacles, but that wouldn’t happen without an explicit acknowledgement that we have to constantly be learning and eliminating waste. Teams get better and better at these disciplines over time.
I would be very interested to hear other peoples experiences with infractructural/operational projects.
