Perspectives: Agile Expert Israel Gat Explores the Evolution of Agile and Why “Big Agile” is Critical to Scale

When Israel Gat joined BMC Software as a systems management executive in 2004, the technology giant had a grand total of zero Scrum users.

But that didn’t keep Gat, who holds a Ph.D. in computer science, from seeing the potential benefits of building an agile software organization for the technology giant.

So he started from scratch, implementing a large-scale agile deployment that would change the way the business looked at product development. By the time he left BMC in 2008, the company had more than 1,000 certified Scrum users, boasted a 300 percent improvement in time to market, and experienced a 50 percent boost in team productivity.

Needless to say, Gat knows agile. Since moving on from BMC to pursue a consulting career, he has helped both multinational corporations and smaller startups transition to the next generation of software and software methods, allowing companies of all sizes to take advantage of appropriate agile methods.

Recently, the Israeli-born director of Cutter Consortium’s Agile practice and founder and lead writer of The Agile Executive sat down with OpenView to talk about how agile has changed over the last 10 years, and why understanding and adapting to “Big Agile” is critical for scaling technology companies.

In a recent webinar, you said that Agile in 2012 is completely different from agile in 2001. What’s caused that evolution?

In my opinion, an agile process is the product of its era. It reflects the needs and the constraints of a certain period of time. As a result, it needs to change as the characteristics of an era change.

The change in the business environment between 2001 and 2012 has been immense, and it has been fundamentally driven by two key factors:

1. Markets have become hyper-segmented and contextually dependent, making them transient and fleeting. It’s no longer a matter of creating products for and marketing to white males above the age of 40 who earn more than $75,000 a year. Today, companies need to address granular markets in real time. Agile, or any software method, must enable the effective pursuit of such markets.
2. Value chains have become value webs. They are neither linear nor stable. Moreover, value is realized within the value web in an unpredictable manner. Unlike a car, which can be assigned a value when it leaves the production line, the creation of a software product is very different from the realization of value through the software product. Agile needs to take into account these new realities of value realization.

For agile, those changes have affected the velocity of both software development and deployment. Today, the environment we work in is much more unpredictable. The linear days of software development have quickly become outdated, which has paved the way for a very dynamic continuous feedback-driven era. Companies now need to leverage speed and real-time customer data to drive product development processes.

You use Facebook as evidence of that evolution. Why is it a good example?

I do not think anybody in this solar system envisioned a world in which, within seven short years, a start-up would become the largest ‘directory’ on earth. It is the kind of change that is best described by the quip, “Change is changing.” If the change in change eludes you, your products (and, your go-to-market strategies, etc.) will fall behind. Agile nowadays needs to enable your company to cope with this kind of on-going change.

Which leads us to the concept of “Big Agile.” How is it different than traditional Agile and in what circumstances should it be used?

It’s really a matter of scale on two dimensions. As a business grows and begins to apply software processes that span sites, countries, and continents, the simplistic, team-level approach to agile does not suffice. Likewise, the team-level agile process has to be expanded to apply end-to-end. The questions companies must ask themselves include: How do you get other functions — marketing, sales, etc. — to benefit from agile? And is your current agile approach capable of meeting your evolving corporate structure and processes?

The basic tenants of agile apply at both the early stage and enterprise levels. But there are certain things about agile at scale that need to be addressed as your company evolves from a promising start-up to a larger scale organization.

For example, you need to think carefully about agile metrics. You need to be intentional about governance of the agile process. Ultimately, scale transforms the nature of agile.

Without going too deep into the process of implementing “Big Agile,” the core idea is that it enables companies to stay ahead of the game in terms of software deliverability. It interacts with marketing, sales, product development, and customer service, allowing scaling businesses to maintain their level of responsiveness to inevitable changes in the market.

Any additional agile advice you’d give to software companies as they begin to scale?

I think one of the most important things to remember is that agile is not about predictable execution. Rather, it is about reliable execution. Software development is a form of knowledge work, it isn’t an industrial process that functions with predictable values to the n-th degree. In fact, if you treat agile that way, you’re actually going against one of the most basic tenants of it: things always change. It’s critical for executives of growing companies to convey that the goal of agile is to respond to change and provide reliable execution, not total predictability. If they do that, agile — or “Big Agile,” for that matter — will serve them very well.

 

Dr. Israel Gat has served as Director, Agile Product & Project Management at Cutter Consortium since 2010. In addition to his tenure with BMC Software, Israel Gat’s executive career included positions with IBM, Microsoft, and EMC. He holds a Ph.D. in Computer Science from the Israeli Institute of Technology and an MBA from Clark University. He is currently focused on enterprise level Lean/Agile deployments; measurement, reduction and prevention of technical debt; and, devops.