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.
And the number #1 Characteristic of an Agile Organization is…
“The Commitment to be Great”
The ability to make the commitment to be more than just good comes from the ability to drive a culture of discipline that balances the metrics of profitability and reputation. Hopefully you have seen and heard that message come through in the other items in our top 10 list; I applied these concepts from Jim Collins’ in “Good to Great.”
“Greatness is not a function of circumstance. Greatness is largely a matter of conscious choice and discipline.”
In the world of software development, an agile organization does not settle for having agile stuck in ghettos. An agile organization makes the commitment to go up the learning curve and blow past amateurism. As Jim describes this takes an organization that can increase the discipline to support increasing levels and scale of agility. Discipline to:
Regularly plan at the five levels (daily, iteration, release, roadmap and long-term vision)
Regularly make and meet the commitments you make based on a sustainable pace
Regularly inspect the progress & metrics and adapt the plans at each level
Make decisions based on the data, culture, and purpose
As Alan talks about at Amazon, it was just the OK from management that was needed. As Israel talks about at BMC, it was a Social Contract. You know what kind of commitment you need at your organization to scale agile. You need to get it to really improve and make your transition happen. Please, don’t settle for a weak commitment. It leads to isolated adoption, ghettos, and a slow, muddling adoption process. Scaling agility beyond just the development teams can be simple and rewarding, as long as you start with the commitment.
Here is a quick refresher of the complete Top 10 list:
At Rally, one of our core values is “Create your own reality.” In this 3 minute video, I talk about how successful Agile organizations embrace a practice of holding a corporate vision and yet encouraging people to find where they can best bring their talents to bear. In a traditional organization, a corporate vision may be the source of very strict, very detailed role descriptions and role assignments. The corporate vision in an Agile organization acts as a guide for how to help people contribute their best work for the overall corporate goals.
Watch my video for more about why I truly believe in both “Create your own reality” and Corporate Vision as key success factors in Agile organizations.
Ryan and I have been talking about quality and faster as necessary components of an Agile organization for awhile. A non-Agile view of a successful organization would have us believe that pushing more and more features into a release and to the market necessitates a loss, or at least reduction or great variance, in quality. In an Agile organization, the thinking is quite the opposite.
Curiously, when we speak of quality and faster inside Rally or with clients, we talk about each being indispensable to the other.
For a traditional, non-Agile case study, let’s look at the RCA case study Ralph Aguayo brings up in his book “Dr. Deming: The American Who Taught the Japanese About Quality.” At its height, RCA’s business model focused on getting as many televisions into the hands of consumers as possible. (Did your family have an RCA T.V. when you were growing up? Mine did!) Quality was secondary to the savings RCA could make from cheap components and speed of product to market. Cheap and fast meant greater profits. Well, as it turned out, no…
Nipper on RCA's first color tv set - the CT 100
Unfortunately for RCA, their model began to crumble when television sets started being returned due to defects, lots of them all still in the warranty period. The cost of attending to these faulty sets ended up being as much as 25% more than the cost of manufacturing the existing set.
Do you have a similar situation in your software product delivery? Are you trying to get profits by pushing features out with “defective parts” because they are “cheaper”?
And to throw another wrench into the works, are you taking so long to get these feature sets pushed out that you have too much of a delay in your feedback to find either the defects or the value of the features you pushed? In other words, is your emphasis on speed, at the expense of quality, coupled with very large feature-rich releases, exactly the wrong way to create greater value and fewer defects?
In an Agile organization, the entire organization concentrates on value delivery and quick feedback on that value.
That is, “are we delivering the right features to the market?” In turn, a real Agile organization understands, “there ain’t no such thing as a free lunch,” and they do increase throughput without the traditional expense of decreasing quality. Defects held in check through a “stop the line” mentality free-up the organization to always respond to value feedback information faster. Think about RCA. If your scarce resources are tied up in managing defects and “returns,” they can’t be working on new feature sets. Or the feature sets delivered are being pushed on defects not yet resolved.
And so, the notion of “quality and faster” is not so counterintuitive as we may have once thought.
We need faster and faster feedback loops in time-to-market in order to continuously improve our ability to deliver quality (defect-free and valuable) features back to the market. Symmetrically, we need higher and higher quality features that are not defect-ridden or dubious in value in order to respond ever faster and more innovatively to the market.
With regard to the video reference to Jim Collins, you can read the interview about his new book and his personal rhythm on the NYTimes site. Verne Harnish’s Gazelles.com teaches the Rockefeller Habits on business rhythm.
In this 4 minute video, I talk about how successful Agile organizations embrace a notion of the ‘knowledge-creating company.’ In Agile, knowledge-creation can use “5 Levels of Planning” to ensure they are engaging in this whole organization practice. In sum, the highest level of planning, the vision, feeds and is fed by all subsequent levels, down to the lowest level of planning, the detailed daily work.
Watch my video for more about why I truly believe in both Bottom-up and Top-down decision making as a key success factor.
I love talking about Agile Organizations with Ryan Martens. When we thought about our Top 10 characteristics of an Agile organization, we recognized the pivotal importance of collaboration. (Having written a book entitled Collaboration Explained may have prejudiced me slightly :- )
When I talk with teams, organizations, and CxOs about adopting a collaborative culture, I can be met with some resistance. Some of it is very direct; often it is passive-aggressive. The rub lies in deep assumptions and old wounds:
Collaboration means dumbed-down
Collaboration means group-think
Collaboration means bringing decision-making to a halt
When Ryan and I say “collaboration” this is the opposite of what we mean. We have a very different picture in mind. Here is a quick view of what WE believe:
Not only can collaborative and smart go together —
they must!
Command-and-control actually makes people stupider—we hire smart people. Don’t we want them to stay as smart and actually get smarter? Command-and-control has the effect of lowering people’s IQ. Collaborative environments improve people’s cognitive skills. They raise people’s IQ’s. Which statement would you like to go home and tell your family: “Hey! I lower people’s IQ’s as a living!” or, “Wow, I actually make people smarter!”
Whether you read “The Wisdom of Teams” or “The Wisdom of Crowds” the evidence is in: we make better decisions when we invite more insights. This aligns with the Lean principle about gathering as many insights as possible before making a decision. Think about set-based, concurrent design and concurrent engineering.
People who believe collaboration means group-think (or dumbing down of decisions) haven’t experienced the power of Storming. That means inviting open and safe conflict around decision-making in a high performance, high trust environment. A prejudice against collaboration is usually based on old wounds. Trust was low. Safety was low. People’s IQ’s had been lowered. In these contexts, an individual team member may only have one tool in their toolbox: a hammer of heroics. Taking that hammer away can look disempowering. In this context, collaboration has to prove that they have something to gain. That is, they are ADDING to their toolbox.
Finally, to make sure that collaboration isn’t a drag on an organization, we rely on extremely effective facilitation. (Collaboration Explained is a good guide!) We rely on effective processes to gather the insights, to seek conflict and dialogue, and to guide teams to take insights and turn them into consensus. This form of collaboration is NOT compromise or capitulation. It manages and then eliminates swirling down energy-draining ratholes. It ensures discussion around useful dialogue versus interesting debate. And, it prevents Loudest Voice Driven Decisions (LVDD) :- )
In this 3-minute video I explain that by (1) finding a sustainable pace and (2) delivering continuous innovation, organizations define a higher level purpose that goes beyond their economic bottom line.
In this 3-minute video, I share how organizations can achieve this balance through (1) stability, (2) sustainable pace, and (3) redefining success based on what the customer sees as most valuable, not just meeting the plan.
And why is this so important to a successful Agile organization?
Watch this 3-minute video for some of my ideas and 4 of the 10 characteristics of a Servant Leader from Robert Greenleaf. Or, see my full hour-long Servant Leadership webinar for a more in-depth look at this #9 characteristic of an Agile organization.
About the Author: Jean Tabakais a wine enthusiast, author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by emailor RSS.
RallyDev.com
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.
And the number #1 Characteristic of an Agile Organization is…
#3 in our list of the 
#4 in our list of the 
I love talking about Agile Organizations with Ryan Martens. When we thought about our 
#8 in our list of the 
#9 in our list of the 
