How One CIO Was Converted to Agile

The real-life story of a skeptic won over.

Coming home from the office one night I found my son, at that time a third-year computer science student, madly coding something on his computer. I looked over his shoulder and said, "You know, cutting and pasting is not the best way to write code." He muttered something like, "Yeah, thank you for teaching me basics." I continued, quite logically, "If you are familiar with these basics, why are you violating them?" He turned to me and said, "Dad! I have an urgent assignment to deliver. I am doing my best to meet my deadline. And YOU are not helping!" I quickly thought of several reply options... And then-I shut up. It suddenly appeared to me: "Isn't this a lesson that I can learn from my kid?"

Don't get me wrong, I am not advocating poor quality of code. Cutting and pasting is a poor practice that may represent sufficient grounds for dismissal. But... where is the line between perfection and reality? This question remains unanswered, and the argument continues. So, when faced with my son's tirade, I shut up because at that exact time I was trying to find the answers to similar questions.

The Situation, Outside View: A Mess

At that time I was a CIO of a company with revenues growing at a staggering rate of 30 to 40 percent a year. As every CIO knows, supporting such growth is quite a challenge. We did our job well in IT operations, and the CEO told me once: "Thank you for making sure that the wheels didn't come off." But the operations challenge was dwarfed by the problem the development team was faced with precisely because of our success!

For a variety of reasons, our competitors were in disarray at that time. The product we had recently built from scratch was head and shoulders above anything else on the market, and was enjoying enormous success. Suddenly the company found itself sitting on a virtual goldmine. The market was just waiting to be conquered. The money was everywhere. We just had to have the right software to pick it. And we needed this software fast-before the competition woke up and before our back-end systems blew under the growing load from the customer-facing applications. Naturally, sales went ballistic, and the list of projects grew to keep my developers busy for the next five years. Isn't that great?

Yeah, except no one wanted to wait five years. Or even one. Senior execs started to push their projects through any crack they could find, so IT governance mechanisms got overloaded and practically failed. I was asked to hire more developers-many, many more. I bought a few copies of The Mythical Man-Month for my peers and argued that hiring more developers would only slow down the delivery, but in vain. Even the CEO could not help me: He too experienced brutal pressure from every side. It was a mess.

The Situation, Inside View: A Mess

My frustration was exacerbated by knowing that my development arm was not as fast as it could have been. As with most entrepreneurial companies, the business vision changed as the company grew, and we had to significantly adjust the foundation of our breakthrough application in order to meet the new vision. I knew what can happen to a company if the core of a mission-critical application is weak. So even with a gun to my head I would not allow cutting more corners than the architecture could afford.

Therefore, there were objective reasons for us to be "slow," but this was a lame excuse in the eyes of business clients. I sympathized with my desperate peers: Without adequate software they saw the money flowing away between their fingers. The problem I had to resolve was typical: increase the responsiveness of the development team without breaking the neck of the system architecture. What's new?

We tried to develop projects in parallel, but every team would have to touch the foundation, so "parallel" failed back to "sequential." We tried to shorten the development cycle and failed again: Massive regression testing became the stumbling block. We were blessed with Boris, probably the strongest QA manager in town. The flip side of Boris's strength was that he successfully fought against every branch in repository if he thought that a subsequent merge would not be affordable considering the schedule. We tried a few other techniques with mediocre results. As an outcome, the system was architecturally solid and financially successful, but project requests were piling up.

I found myself in the middle of a war on three fronts. My peers desperately needed IT solutions. My development team desperately tried and failed to deliver them fast enough. My operational team was frustrated dealing with a set of bootstraps that developers were forced to create in order to speed up the delivery. The frustration grew on all sides. It was a mess.

The Uneasy Way Out

Stage One: the Uncertainty and the Decision MakingAt this time my system architect came up with a new idea. Alex was a very experienced architect, satisfied with his job only when his software delivered business value. He suggested trying the Agile approach. Being a "sane" CIO with development background, I replied: "XP? Developing software without design and documentation? Over my dead body." Like many a development manager, I "knew" that Agile means "developing without design or documentation." Apparently, I was repeating all the fallacies that were built up around Agile. In fact, the Agile techniques suggest coming back to modesty and developing small, doable and useful pieces of software working together with business stakeholders.

Alex had already tested out a few Agile techniques with some success. Thus, the implementation of continuous integration technique had cut the system integration time to virtually zero. Building a Wiki instantly catalyzed real communication within the team. A few articles from Agile evangelists that he brought to the team offered practical solutions to some other problems. Finally, he summoned heavy artillery: Eric Evans and Joshua Kerievsky appeared in our office. Eric recommended re-architecting the core in order to empower parallel development. Joshua suggested pair programming together with a few "noninvasive" Agile techniques. I started asking myself: "If I trust my senior architect, why am I stifling his passion? Should I let him experiment more?"

One more argument in favor of the Agile approach was that we already applied one key component of it early on. Indeed, the main reason for the financial success of our breakthrough application was the decision to release it in stages. Our sales team was very much in tune with the market, and thus the underlying business model and, correspondingly, the required feature set had to be changed twice within 24 months. This called for massive changes in the core of the system. Moreover, the first set of requirements was aimed at the wrong type of customer! Had we chosen the "regular" way and stuck to the signed off requirements, the team would still be working on Release 1.0.

But we realized our newness to this market niche, and did not believe that we knew everything. We made a humble decision to quickly deliver the first version of the system with only the basic features, and later correct the course based on market reaction.

The first release was in production within just four months, and the product earned the company its money back almost instantly. The break-even point was achieved in just a few months. Since then, even with several course corrections and severe changes in the system, it earned money and customers steadily, demonstrating two- to- three digit annual growth rates.

If we had embarked upon grandiose plans to deliver the entire system we wouldn't have earned all this money and all these customers. More importantly, we would have lost the opportunity to occupy the market niche. The implementation of the humble Agile approach had resulted in our financial success. This led me finally to succumb to Alex's pressure, and I gave the green light to a massive implementation of Agile methods.

Stage Two: A Slow Start

Almost right away I saw that my team became stronger, and the system more solid, but we still could not resolve the main problem-speed of delivery. It wasn't easy to experiment on-the-fly in a company with a huge demand for software. The battles between development and QA continued, as did my battles at the senior exec meetings.

The situation grew increasingly chaotic.

One day the director of development came to my office and said, "You must see that this Agile approach is not working. Why are we still trying? We don't have time to experiment, we need to deliver!" Today Heather is a passionate believer in Agile. But then, being an experienced manager responsible for the tight if not unrealistic schedule, she had a point. It was very tempting to call off the troops and revert to the "normal" practices. At that turning point the biggest counterargument for me was knowing that the light in the eyes of my developers would dim if we were to give up. Every CIO knows what I am talking about. You have this light and your team can do miracles. You don't, and any plan is doomed. I said: "Let's give it one more try."

Stage Three: A SuccessSometimes you know that the battle is won even without any apparent indication. This is how I started to feel shortly after the above conversation. More importantly, this is how the team felt. The key reason for this was cooperation with Owen Rogers from ThoughtWorks. Working as our Agile coach, he attacked the most critical part of the project lifecycle-its inception. Methodically and without pomp he implemented story cards and velocity charts, involving key stakeholders, analysts, developers and the QA department. This produced results almost instantly.

Little by little, we achieved critical mass. Pair programming boosted cohesiveness, improved resource maneuvering and provided collective ownership of code (no more nightmares about losing a key developer, although our employee turnover stayed at 0). Velocity charts delivered transparency for the team and for the business. "Test first" approach and early involvement of the QA cut the testing time and improved the quality of the product since the bugs were fixed right away.

Shortly afterward we attained our first unquestionable success. A significant- sized release progressed nicely despite the skepticism expressed by a few authorities, and was issued one week before the deadline after only two months of development and testing. All this was achieved with the project scope increased by almost 40 percent during the implementation! During these two months everyone watched the velocity charts with bated breath. But the team, empowered with the right methodology, steadily went forward on the path to success.

This helps to demonstrate that the Agile approach produces better, more accurate plans by making the decisions on-the-fly. Indeed, all the necessary information is rarely available at the beginning of the project, so making an educated decision early is impractical.

Another advantage of Agile: You don't need expensive tools. A digital camera and a video camera are useful, but these will be the most advanced technological miracles you will buy. Besides these you will need whiteboards, flipcharts and a few sets of index cards.

If you ask me what the most important outcome of this release was, it was not the software. Rather, it was the feeling of pride that every team member now radiated. Never during my 30 years in IT have I seen the team that happy and that mighty.

This pride, however, did not protect us from the failure that was just around the corner.

Stage Four: A Failure after SuccessThe lion's share of our first success should be attributed to our business stakeholder. Jason was a dream client: smart, knowledgeable and with sufficient power in the company. He knew what he wanted and time after time was bang-on with market projections. In addition, Jason was reasonable with requests since he knew that the development team was doing everything it could. Participating in scope sessions, he made "time vs. scope" decisions then and there. But the main winning factor was that he spent significant time with the development team during the entire project. From the very beginning of the development, the system was deployed as often as once a week to a special environment available to Jason. This gave him an option to clarify the requirements and correct the course. Moreover, working in close cooperation with the team during the entire release, Jason knew what was involved in scope changes and did not abuse his power.

However, the next release was planned for a different client; actually, for clients in two different business units. They had different underlying business models in mind, and nobody wanted to make a binding decision and reconcile with the other side.

We lost six weeks going back and forth, and the schedule was destroyed. I consider this to be entirely my fault. After the first one or two weeks I should have called the parties into the room and said: "Guys, come to terms now or I will kill the release and reallocate the resources." I didn't do this, being preoccupied with other things that probably could have waited.

The lesson rang loud and clear:

1. No success protects you from a subsequent failure.

2. If you are not certain who your client is, or if he is not willing to make decisions and to work alongside your guys, kill the project as early as you can for it will fail anyway.

1 2 Page 1
Page 1 of 2
Discover what your peers are reading. Sign up for our FREE email newsletters today!