The Borland Agile Journey - An Executive Perspective on Enterprise Transformation
|
|
|
|
|
|
|
|
|
Written by Pete Morowski
|
|
Monday, 11 August 2008 |
|
 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. To
read the full paper, please email
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
.
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.
|
|
