Trial and error and why it’s OK to be wrong
In a previous role, I was in a group that managed on-premises infrastructure projects. We followed a traditional yearly financial view: a project would start with a spring plan, receive funding in a fall plan, and be assigned a project manager the following January. The project would finally be delivered in December, 21 months after the first discussions. While projects were generally delivered on time, they rarely met the needs of our application teams, and the 21-month development cycle was too long. I remember one project that ultimately supported its two applications for only six months. Another time, we delivered a project only to learn one week later that the product it supported was being discontinued. The problem was that these projects were delivered around specific products, not capabilities.
Four years ago, I was fortunate to co-lead the transformation of an infrastructure group into an agile organization. Our focus was the delivery of the private cloud capabilities of the IBM CIO Hybrid Cloud. While delivering new technologies was exciting, we realized we needed to change our culture in order to actually be successful. We needed to be better, faster, and happier. To achieve this, we set out to simplify the service structure with a new design based on agile principles. This would enable each part of our group to deliver a complete service to its customers, while delivering value incrementally.
Agile in IT infrastructure
Agile is not something usually associated with IT infrastructure, but we looked at it as an opportunity to align our process with those of our CIO organization colleagues. Our new agile process emphasized learning and knowledge-sharing, with vertically integrated teams delivering an end-to-end service. Within our group, we focused on fostering autonomy, mastery, and purpose in our team members. Externally, we aligned our priorities with our application partners and delivered innovation as service capabilities, not as solutions tied to specific products.
The greatest challenge was delivering capabilities in two-to-four-week sprints. To meet it, we restructured our organization to drastically reduce handoffs and to break down tasks into modular pieces. We also now measure our success together with our application teams, not separately as provider and consumer.
One of my favorite parts of this way of working is our end-of-sprint retrospectives. An honest review of what went well, what didn’t, and what still puzzles us dispels the notion that we must be 100% successful in each sprint. Learning from frequent retrospectives has made us much more aggressive in our delivery. Agile calls this failing fast.
Are failing fast and failing often accurate terms?
Failing fast isn’t about accepting failure or literally failing quickly. Rather, failing fast is about opening the creative juices of our group members, being iterative in our approach, and most importantly, promoting learning and continuous improvement. We learn not only what works, but also what doesn’t work.
In my current group, we no longer have 21-month-long projects. We instead have quarterly objectives and key results (OKR’s), which allows us to be much more aggressive in our deliverables. We challenge ourselves to meet these goals every day, and monthly we recognize the things that slowed us down, not as negatives, but as challenges to circumvent. Limiting the failures to two-to-four-week sprints provides a very early chance to correct course without lots of re-planning. Leveraging our learning helps us think differently for the next sprint and to avoid running into the same barriers. We certainly have iterations that don’t go very well, but we also have ambitious ideas that become very successful and accelerate the pace at which we deliver capabilities. We also have a very tight alignment with our consumers, who get to provide feedback and see the benefits of our work in a matter of weeks or months, not years.
How well does failing fast work?
Recently, we started a large redeployment project to our new hybrid cloud platform. In the past, we would have had a four-year plan, but our newfound agile vision has us redeploying more per quarter this year than in any year of our history.
Our fail-fast view put the aspirational goal to our technical leaders. They established a very aggressive plan with some new ideas in place. Our iteration planning reduced this nine-month project into five weeks. We ensured we had very safe fallback plans, and then we started. The first attempt never got off the ground due to some technical items not being delivered. We had no negative impact to our consumers; remember, they are brought into our plans with us. We used the next two-week sprint to pull in lessons learned, address the things that didn’t work, and enhance the things that did work. We went for our next attempt two weeks after the first. Success! Fifty applications were redeployed to the new platform in a single weekend.
We didn’t simply rubber-stamp the plan. Failing fast says that you do your retrospectives and learn. In the next iteration, two weeks later, with another group of colleagues we implemented some processes changes and a couple of new capabilities. Better success! No repeated issues, faster migration, less problems. Two weeks later, again, some more changes and even better results. What historically would have been three distinctive projects over 21 months was done in less than three months with progressively better results.
The agile practice of failing fast does not mean to continue to try different things, it’s to be iterative and learn in short time periods with continuous improvement. It’s an excellent practice when leaders focus their teams on the right things and expectations. You can be wrong as long as you have the right practice to continuously improve.
Kevin Ingwersen is a Senior Manager and Leader of the Private Cloud Compute Platform for CIO Hybrid Cloud Platforms at IBM based in Southbury, CT. The above article is personal and does not necessarily represent IBM’s positions, strategies or opinions.
