I begin this story by declaring up front that I am not an "Agilist" or process evangelist. I am the senior software development executive in a company responsible for delivering products to the marketplace. Like my peers across industries, I am fundamentally held accountable by my company for consistently delivering business results. Process and methodologies are important in delivering this value, but in the eyes of the company they are secondary to meeting the needs of the business.
When I joined Borland 2 years ago, we had two Agile "pilot teams" in place; today 60 percent (and growing) of the organization delivers our products to the market through an Agile approach. This is the story of our journey into Agile, chronicling the decisions and observations of our ongoing transformation from the eyes of a senior software executive.
Situation Analysis: Snapshot of a Traditional Software Delivery Organization
Borland's product organization consists of over 350 personnel in five primary geographic locations, including development sites in Asia and Europe. It is a development shop organized into teams of 12-35 engineers delivering a very broad portfolio of products, which contain the typical mix of new and sustaining work projects that are consistent with both ISVs and corporate IT shops.
As a 25-year-old company, Borland has gone through a number of changes throughout its lifetime. In the process, it has acquired a number of companies in many different locations throughout the globe. My charter was to introduce stronger operational oversight, reduce costs and boost the organization's efficiency and quality. I decided to overhaul the organization, and one of the components of this effort would be to broaden our use of Agile.
The First Step: From Grassroots Movement to Disciplined Implementation
In my investigation and observation of the usage of Agile within Borland, I soon discovered that we had multiple Agile cultures emerging. The teams that were experimenting with Agile all varied in their states of maturity and level of commitment.
As a result of these fractured efforts, each of the locations was undergoing a separate transformation and this meant that we were developing several independent Agile cultures. What became obvious was that if we were going to expand the use of Agile throughout the organization, we would have to transition it from a grassroots effort to a more disciplined and structured rollout.
In shifting from an adhoc to a more structured adoption of Agile, we made three key decisions. The first was to make our executive commitment much more visible. We had to show the teams through our actions and words that we were going to be enablers of this transformation.
Next, we decided to appoint a single Scrum Master/Agile Process Specialist who would be responsible for driving the overall definition of "Borland Agile." The third decision we made was to take a stepwise and iterative rollout approach. There would be no hollow mandated Agile "light switch" in which everyone would begin transforming immediately. We realized that we had to face the reality of making a major process transformation while still executing on a pretty aggressive product roadmap.
Sold on Agile: Successful Pilot Paves the Way for Organizational Transformation
One of the first projects we designated as an official "Borland Agile" project was the development of a high-priority new product that would be a key part of Borland's next-generation suite of products. In December of 2006, this project was divided across multiple locations and teams. While the release date was only eight months away, progress on the project was stalled. I made the decision to consolidate the project into one location - the location we had designated as our "flagship" for the Borland Agile transformation.
We successfully made the transition, released the product 10 days early with more features than originally planned, and established one of the closest customer relationships I have witnessed in my career. This is the point at which I became hooked on the potential of Agile and Scrum.
Once we had achieved success with a few pilot projects, the next step was to expand our use of Scrum, completing our rollout at the first site and then transitioning the other geographic locations. We decided to make our original Scrum Master an "Agile Evangelist" responsible for overseeing the process transition and serving as a mentor to the entire organization. A second, more controversial, decision was around the Scrum Master role for the individual teams. After quite a bit of debate, we decided to transition that role to the development managers.
I know there are Agile purists out there who are cringing, so let me explain. One of the most challenging issues involved in transitioning a traditional software development organization to Agile is to reconcile the reality of existing hierarchies, roles and responsibilities with the "flat" team structure of the Agile approach. An executive has two choices: ignore the cultural implications and just move forward - risking alienation, passive-aggressive behavior, and even the departure of some of the most talented and experienced team members. Or "adapt the rules," and structure a transition that leverages and involves this talent without compromising the basic tenets that Agile promotes. The key is to be creative in how you manage inclusion and the buy-in process that is associated with any change.
The Benefits of Agile in the Enterprise
While there is much that I learned through this effort, I would like to highlight three areas in which Agile can yield benefits I feel have the potential to provide a tremendous advantage in delivering software: its model of self-directing teams, its ability to enable organizations to manage change, and the way it changes interactions with customers.
Self-Directing Teams are Productive Teams
My guess is that many of you may be a little skeptical of the self-directing teams concept. Can you really let the teams decide what they will work on and how they will accomplish it? The answer is yes. In fact, correctly implemented, this is extremely powerful. The power comes from the fact that in this environment team members begin to take a great deal of personal responsibility for their work.
The only way to achieve this is to make a leap and "let go" - you have to allow the teams to truly own their projects. While this underscores the importance of good hiring and it requires a certain level of trust, by giving those closest to the problem the power to act you remove overhead and speed delivery. We have found that shifting to Agile has resulted in improved morale across the organization. Teams have improved their abilities to communicate, coordinate, prioritize and focus. They are constantly evaluating their performance through the Sprint Review process, identifying ways to improve their efficiency, reduce their errors and refine their processes. This has all resulted in considerable increase in the organization's productivity and ability to deliver the "right" product to the customer.
Agility Truly is the Ability to Adapt to Change
Change is the uncontrollable factor that has been the undoing of man a software delivery project. Its inevitable, but something that a traditional, linear delivery process doesn't handle very well. If (when) you discover a new requirement or significantly change an existing one, there is no way to predictably inject change. You must always interrupt the current activities and go "back" to a previous phase.
Agile does away with the traditional phases of delivery. I like to say you are always moving forward in a Scrum environment. In our case, sprints are two to three weeks long. This allows us to inject change in an orderly manner on the two or three week borders without interrupting forward progress on a release. I say "borders" because once a sprint is started the train has left the station. The work cannot be interrupted and no changes can be made.
The benefits of this approach in terms of our ability to rapidly respond to changes in the market or customer needs cannot be overstated. In one instance, a market event caused us to shift priorities around several key features of one of our products mid-stream. We were four months into development, and were facing significant changes that were key to deliver the "right" product. If this had happened in a traditional delivery environment, we would have been "back to the drawing board" and quite likely would have needed to add another six months to the project schedule. Instead, we were able to adjust course, shift the remaining sprint priorities and cut that additional time in half.
Transformed Customer Relationships
The Agile approach to delivery involves a material change in the way the delivery organization interacts with customers. At a time when many companies are seeking to be more customer-focused, Agile provides a model for development organizations to collaborate with their customers to drive greater levels of satisfaction. Customer relationships under Agile can - and should - evolve into outright partnerships.
This is extremely powerful, but can be potentially dangerous if it is not managed correctly. In an Agile environment, customers have near complete visibility into the development process. They participate in sprint reviews and have access to early versions of the code. Throughout the process, they provide input as to whether you are meeting their needs or not. For these reasons, it is critical that you ensure customer profiling is a part of your evaluation when choosing projects to transition to Agile. Selecting customers who are willing to participate in the process is extremely important.
We were fortunate, in that the customer in our first Agile project was clearly a partner, and as the process unfolded, the benefits exceeded our expectations. Once the customer became used to frequent releases, they no longer felt the need to try to get every possible request into the next release. They knew the schedules, they understood how work was being prioritized, and they could see the impact of changes. This created the opportunity for us to have real discussions on priorities, since releases could be staged in terms of weeks - not years.
Conclusion
Crafting the conclusion of this article was somewhat difficult because the story of our transformation continues. We still have a lot to learn. And that is part of the beauty of Agile. As an empirical process, it leaves room for continual discovery, growth and improvement. Will Borland ever be 100 percent Agile? It is possible, but unlikely. And, I believe that most enterprises that begin to shift to more agile approaches will find themselves in similar situations.
My job is to maximize my resources in order to efficiently and predictably deliver results - in the form of high-quality software - to my business. So, as we continue our Agile transition, I also continue to learn what types of projects, and frankly more importantly, what types of teams deliver the most return from transitioning to Agile. Managing a broad portfolio of products in different stages of their life cycle and investment priorities is just a fact of the business.
Thanks to the visibility that Agile methods automatically encourage, we are a much more transparent organization and we have achieved much stronger operational oversight. Our teams are happy and productive, and we have increased our number of releases per year by 100 percent. Finally, we have driven down costs, especially in the area of "reporting overhead" - those days (or weeks) every month where management is gathering reports and meeting with teams to assess status for operational review meetings.
Will Agile work this well for every enterprise? Perhaps not, but I think that evidence is building that the approach can yield transformational results.
This article is excerpted from a more comprehensive executive paper that explores the management and cultural issues involved in an enterprise Agile transformation.
About the Author
Peter Morowski is the senior vice president of research and development at Borland Software Corporation. In this role, Mr. Morowski is responsible for evolving Borland's products and technology investments.
Prior to joining Borland, Mr. Morowski served as the vice president of software at Dell Inc. In this role, he was responsible for creating Dell's first enterprise software organization, where he set product strategy, developed organizational structure and established all internal software practices for the company. Before Dell, he served as vice president and chief technology officer at IBM/Tivoli Systems Inc. At IBM/Tivoli, he was charged with setting technical direction, recommending investment strategies and serving as a technical advisor to the CEO and senior business unit managers.
Mr. Morowski has also held management positions at top companies such as Novell, Inc. where he was vice president and director of development and at Saber Software, Inc. leading up to its acquisition by McAffee Associates. He holds a B.S. in Engineering from Illinois Institute of Technology.
