Tue 24 Aug 2010
Five Reasons Why CIOs Should Consider Agile Development
Michael Hugos, principal at Center for Systems Innovation [c4si], writes, speaks and consults on strategies for IT and business agility and mentors development teams. He spent six years as CIO of a multibillion dollar distribution cooperative developing a suite of supply chain and business systems that transformed the company’s operations and revenue model. He won the CIO 100 Award and Premier 100 Award for his work. He’s author of several books and writes an online column for CIO magazine called “Doing Business in Real Time.” We recently met with Michael at the Agile 2010 conference, which resulted in “Agile is Ready for the Enterprise” and sparked the idea for this blog post.
Rally asks: What issues and trends are you seeing across technology departments, development teams and in discussions with CIOs?
Michael Hugos answers: The example set by companies such as Google, Facebook and Netflix shows how companies can use iterative development to continuously enhance products and grow market share. This is being noticed by business and technology leaders in other companies and they are asking if they can do the same thing to drive development in their own companies. People realize that IT is right down the middle of everything a company does, and that traditional software release cycles of once a year, or even once a quarter, are not able to keep up with the pace of change and innovation these days.
Just like the word “athlete,” the word “Agile” grabs your attention; it sounds great. But moving from desire to reality always tests peoples’ commitment. A lot of companies are struggling with the all-too-common reaction of, “That’s not the way we do things here…” Agile approaches are interesting and fascinating to companies, but then there is the tendency to immediately criticize new ideas – we’re all prone to it. As soon as someone suggests a new way of doing something, we all think of 10 reasons why that can’t be done or why it won’t work.
Rally: What is driving enterprise adoption of Agile?
MH: To begin with, agility is no longer just a good idea; it’s now backed by law – the law of probability. This law says if a company can’t keep up with rapid rates of change in the world then its probability of success is getting smaller and smaller every day. And since companies need IT infrastructure and applications to operate, just as our bodies need a nervous system and muscles to move, IT agility is critical for a company to achieve business agility.
In the last few years, software tools have enabled executives to measure and track progress on Agile projects and to see the performance of Agile teams in widely dispersed geographical locations. That makes Agile methods more feasible for large companies. A pervading feeling exists throughout business that just about everything else has been tried and IT groups are still not really keeping up with the backlog of user requests. Users are starting to go around IT and do their own things using SaaS, social media and mashups to put together systems. So why not give Agile a try?
Rally: How do Agile methodologies help large organizations foster, regain or accelerate the pace of innovation?
MH: Agile practices offer the best way to improve communication and collaboration between business and IT. Meaningful innovation always starts with communication and collaboration. Another thing that Agile practices enable is the ability to try out new ideas and explore opportunities quickly without investing a lot of money up front. With more traditional approaches, companies invest a lot of time and money planning up front before they start something new. This is expensive. And since most new ideas don’t pan out in the end, this traditional approach makes it difficult (if not impossible) for companies to try out enough new ideas in a year to find that small handful of ideas that do work out and deliver the profits they are looking for.
I like to say that in this high-change and unpredictable economic environment, companies need to: “Think big, start small and deliver quickly.” That’s the best way to keep up, adapt and respond to change, and find the opportunities they are looking for. Agility means letting go of slow, deliberate decision-making in favor of quick, repeatedly-tested decisions. That’s why Agile methods are so appropriate for energizing companies and helping them develop innovative products and services.
Rally: How do you make a case for Agile and address the fears of risk-averse CIOs, CTOs or CEOs?
MH: First, I remind executives of something that has become a fact in the last 10 years: business operations and technology are so tightly intertwined that there is no meaningful distinction left between the two; you can’t do business without technology. That might seem obvious to many but, executives who have been around for a while (like me) may still remember the days when IT was just a back office operation.
Once people acknowledge this reality then I point out that, over the last 10 years, Agile practices have been thoroughly field tested and have an impressive track record for delivering success. There are software tools now, like Rally and others, that address Agile project management and reporting, business and IT collaboration, software testing, and the continuous integration of new software with existing systems infrastructure. So going Agile is not just a leap of faith anymore.
Agile is actually a better way to manage risk versus using traditional waterfall approaches. With Agile practices, big projects are divided into lots of smaller projects that build on each other. This enables people to employ short feedback loops, learn quickly and change plans in light of new information. Two of the biggest causes for failure in business and failure in new development projects is that companies have no inexpensive way to investigate new opportunities, and they blindly follow predefined project plans without change – even as the world itself keeps changing.
The IT profession is at a turning point: one group of IT practitioners has learned that agility is the way to go, but more traditional practitioners still call it radical. Yet, the traditionalists continue to apply the same old ways of doing things that result in the same old horrendously expensive, multi-year projects that produce systems barely better than what was there before, if they even work at all. More and more business executives are coming to the conclusion that the effective support of business agility is the main reason for their company to have an internal IT group. Otherwise, there are options now to just outsource IT operations to cloud computing vendors and get new applications from SaaS providers and social media.
Rally: What does the future hold for Agile and Lean development practices?
MH: Probably the biggest change will be analogous to what happens when a company grows and transitions from an entrepreneurial startup to an established business. When this transition happens, there is a need to become more pragmatic and less idealistic. In the Agile world, this means that “Scrum-but” will actually be the best way for most companies to adopt Agile methods. Each company will customize versions of Agile that best fit their needs and it will be some combination of practices from Scrum, XP, Lean, Kanban, etc. Even waterfall practices have some benefits which should be incorporated where they make sense. Agile practices will not be set in concrete; they will continue to evolve over time as companies learn more and the world keeps changing.
Another big change for Agile is the realization that Agile development is not an end in itself. The value of IT agility is its ability to drive business agility. In the end, agility is more about business than about IT. Instead of co-locating business people with development teams, we will embed IT people in business operating units and co-locate development teams with business people.
I talk about this in my most recent book Business Agility: Sustainable Prosperity in a Relentlessly Competitive World. Agile companies will become real-time organizations that use IT to drive a process of continuous focusing on and responding to opportunities and threats. They will employ IT to drive three continuous feedback loops that make their real-time operations possible. The first feedback loop (I use the Yin-Yang symbol), provides awareness of a changing environment and identifies threats and opportunities. The second loop (I use a sunflower because of how it constantly adjusts itself to follow the sun across the sky), provides balance and continuously adjusts existing operations and processes to fit changing circumstances. And the third loop (I use the leaping panther), provides agility in the sense that it is how companies create new processes and products to seize new opportunities. The figure below illustrates this.



I completely agree with your points about agile adoption in that Scrum-but or Agile-but is the way that many big organizations take on adopting agile. It’s a process. There are still some very useful waterfall methods that just make sense for specific projects!
Hi Peter,
As you say, it’s a process. The transition from idealistic to pragmatic as Agile goes mainstream will be a balancing act. We don’t want to lose the enthusiasm of the people who adopted Agile early on and proved its value. They will be the very people that we need to lead the transition and share their hard won wisdom.
Yet pragmatism is what we need now; dogmatic rejection of good ideas from waterfall methods or any other method that a particular company has found useful won’t advance the cause of bringing Agile to the mainstream. What’s an idea from the waterfall world that you’ve found to be useful?
You are very correct. It is a balancing act and per organization, we need to leverage what existing processes still work and are good for the projects.
Waterfall is heavy in up-front loading, often requirements. Where a CCB is in place, this project proposal and signoff pieces of the process are valuable even before we throw it over the wall to a development team to “agile” it up.
Waterfall techniques can be very good for post release processes, including project sign off, independent validation and verification, audit, etc.
Wow,
Great interview.
I think the awareness, balancen agility loop is fascinating, I wasn’t aware of Michael hugs before, but I am now and I’m definitely paying attention.
Jeff
[...] What Changes in Agile? Agile development differs from its waterfall predecessors by dividing big projects into small deliverables that deliver value more quickly. Risk is mitigated as large projects are broken into smaller, more immediately evaluable increments. Funding is incremental. Software assets are built incrementally. As a system, software development is more responsive to changing market conditions. (For more insights on the rationale behind agile development, see http://www.rallydev.com/agileblog/2010/08/five-reasons-why-cios-should-consider-agile-development/). [...]
I guess it’s hard to argue with Mr. Hugos’ apparent track record of success, but I’m afraid that the view of Agile from the trenches is not as rosy as the Agile consultants the the CEOs using the methodology claim.
Any enterprise software system is an extremely complex object requiring an enormous amount of careful up-front design on the part of very experienced people. This is because the slightest errors and oversights in a project design can lead to catastrophic failure. This aspect of software development is no different from other types of engineering (quick: how many automotive recalls have you heard about in the past year?). Rushing forward with implementation before thinking things through very carefully is a recipe for almost certain disaster.
I don’t know what the original idea behind Agile was supposed to be, but I do know what I’ve seen over the past few years and it isn’t pretty. Projects mostly engage in a process of “code now, fix forever”. Basically you hire a group of developers, hand them a feature list and a time line, and expect that they will create something rational by simply writing code in two-week bursts with little or no forethought. I don’t know why corporate managers have become enamoured with this line of thinking. Nobody would imagine that you could build a house or a car this way, but somehow the invisible nature of software makes it possible to imagine that you can build an enterprise software system this way. I can see where a lot of people like the idea though: Agile means that you can manage a software project with essentially no hands-on experience or knowledge. All you need (from what I’ve seen) is a feature list and a schedule. Oh yes and then later on a huge, endless bug list and a schedule.
After 34 years writing software professionally and I can tell you without reservation that the most significant thing affecting any software project is the quality of the underlying design. All the methodology in the world won’t compensate for a bad design. But Agile can make you swallow the bitter pill more easily: when your poor-design project goes into overtime with a huge bug list, you can congratulate yourself on how efficiently your team is able to chase after the bugs. And since you’ve never seen a project that doesn’t end with a perpetual series of bugs to fix, you can keep congratulating yourself on the number of bug-fix “sprints” you’ve completed.
For many years I successfully delivered very complex systems using a practice that I call “schedule-driven Waterfall”. Every quarter the business agrees to the requirements for the coming quarter’s development. After locking in something that can be reasonably designed and implemented in 3 months, developers proceed to build what was specified. The business may request changes during this time, but it is understood that no such changes will be implemented until the following quarter.
This process works but it requires discipline on the part of the business – i.e. the understanding that you simply cannot conduct a successful software development in an environment of continually changing requirements. It is an adult, real-world view based upon real-world limitations on what can actaully be done, and it requires the presence of grownups on both sides of the IT table. Which is perhaps why it will never be the fad du jour.
Is Agile the magic bullet that enterprises have been seeking out for the past six decades? My guess is that if you were to count the enormous costs of the bad designs that are produced with the Agile code-it-now, think-later mindset, Agile would be revealed to be one of the most expensive ways of doing things.
Dave,
Sorry to hear about you poor results with agile process. Dean Leffingwell, Philipe Kruchen and I recently spoke at the SigArch meeting here in Boulder. It was clear that agile methods were making a big and positive difference on all sizes of projects. It was also clear that different contexts require different amounts of design. At the same time, it was clear that getting to code quickly to help develop the solution and the customer problem/need in parallel is working very well too. This customer development/lean start-up approach lets the design emerge, but it requires a disciplined team to manage the design and refactor well. I think the complex systems we are building now, require this kind of emergent design, as it is too hard to guess as to how the system will behave without probing, sensing and then responding.
My take-aways – agile only scales well when the team’s level of discipline scales too; emergent design approaches work great in complex systems, agile is systemic change not just a method.
I recommend coaching to all large customers when they adopt. It is too easy to miss the take-aways that I mentioned. Glad to talk more @RallyOn.
Ryan