An article touting the business benefits of adopting the Agile methodology for product development.

1. Functional Business Advantages to Adopting Agile
By Chris Marocchi
About 15 years ago, I had my first introduction to Agile Methodology in product development. At the
time I was the Director over a technology portal team at CB Richard Ellis called Axis Portal. Axis was
the brainchild of the division president I reported to, and my predecessor had led the team’s efforts in
developing the platform and selling it to a number of CBRE’s commercial office building owner
clients. I was tasked to take the portal to the next level, both in functionality as well as in market
penetration. So we set out to conquer the world of commercial real estate property management
services by selling the “new and improved” version of Axis Portal to existing clients as well as new
prospects and competitors.
The Unknown Challenges with Waterfall
In full transparency, I was not much of a “tech” guy back at that time. My background in product
development was limited to my experience in the CPG and commercial pumps industries. CBRE’s
legacy methodology used throughout our division of commercial property management services was
the Waterfall methodology. This is the methodology that we used for product development for the
portal, and honestly, I didn’t know any better because I had not been exposed to anything but the
Waterfall methodology prior to my time at CBRE.
Due to our use of the Waterfall methodology, I was facing the following challenges that were holding
back my team from more effectively responding to our clients’ needs:

2. 1. Inflexible to changing priorities.
In the world of technology, things change fast. And our customers expect us to keep pace. We
were doing a good job of collecting customer requirements and monitoring the “Voice of the
Customer” in our market research and conversations with customers. For the most part, we
knew what the industry wanted, and were working furiously toward the goal of developing as
many features and functionality as we could and as quickly as we could. But then one our
largest customers would throw us a curve ball – they’d demand a certain functionality be made
available to them ASAP – or they would leave our services and move to a competitive product.
Introducing a new requirement into our current development cycle was not possible, and was
met with significant resistance from our development team, which often led to conflict
internally.
2. The Trade-Off Inefficiencies
Sometimes I would get my way, but the price I paid was the loss of progress and momentum in
the development of other features that we had previously prioritized and communicated to the
development team. This caused us significant delays and at times undermined commitments or
marketing messages that we had previously communicated in terms of the availability of new
functionality. Interrupting the development process within the Waterfall methodology was
extremely inefficient and disruptive to our development process and release timing of
previously identified feature requirements.
3. Cost
Last, but certainly not least, were the costs associated with the disruptions to the development
process and schedule. The coordination and time required to communicate and reach agreement
to changes in the Waterfall methodology were excessive, and as the mantra goes: “Time is
Money.” I had a budget to manage, and sometimes the cost associated with a significant change
was more than the budget would allow. During those times, I had the uncomfortable task of
informing our largest customers that we could not honor their request. As a consequence of
these decisions, we did eventually lose some of our largest customers.
The Conversation That Led to Change
One day, our project manager Lenny (a shared resource among many CBRE departments that
coordinated projects among the various stakeholders: onsite developers, third party developers, our
product team, and myself), requested a meeting with me. Despite some of the friction that I had created
with the development teams due to my change requests, Lenny and I had a very good working
relationship. Lenny was good at his job, and I felt that he understood the needs I had as a business unit
leader.
Lenny had seen the challenges that our ever-evolving product requirements had created, and took the
initiative to discuss it with the development teams. These individuals, whom I would describe as the
true technology subject matter experts, made the recommendation to Lenny that we adopt the Agile
Methodology framework for our future product development needs. Lenny then approached me with
this recommendation, and asked for my buy-in for the adoption of agile.

3. Of course, I had no frame of reference for this new methodology, so I asked Lenny to elaborate. Lenny
went on to explain the framework for Agile, and its advantages over the Waterfall methodology. It
sounded like a better way to approach our product development process, but I was still a bit uncertain
because of my lack of experience with Agile. I asked Lenny what his personal opinion was. He stated
that he was in favor of it, as was our lead in-house developer. I told him that I trusted his opinion, and
to move ahead. This ended up being a pivotal decision that worked out far better than I had ever
imagined.
The Business Benefits of Agile
As our team quickly began the process of implementing Agile into our product development process, it
naturally took center stage in our weekly project meetings. Our lead developer expressed his gratitude
for my open-mindedness, and assured me that things would move ahead more smoothly going forward.
He also provided a more specific explanation about how Agile would benefit our team specifically,
starting with the concept of smaller sprint cycles, each with its own set of requirements, and the
flexibility that we’d have to change the priority of requirements prior to each sprint cycle, which would
last no longer than 2-3 weeks. This was music to my ears!
Here's a summary of the immediate benefits we realized after Agile was fully implemented for our
department at CBRE:
1. The flexibility and framework to allow the re-prioritization of requirements with each sprint
cycle.
Now, if a large client demanded the addition of a new feature, instead of responding with a
“no” or a “yes, but it will take x months to implement” we could respond with a resounding
“yes” with assurance that the time for implementation would only be a matter of weeks.
2. The general feeling of customer collaboration over internal policy negotiation.
The feelings of conflict were virtually eliminated once we made the change to Agile, as now,
any change requests could be facilitated during our team’s weekly project meeting, at which
time the request would be made, and the start time identified as the new sprint cycle. This
helped our internal teams feel a sense of pride about their ability to more positively respond to
a customer request, and our clients were no longer left with the feeling that our internal policies
took precedence over their requests.
3. Responding to Change over Following a Plan
Other requirements would be placed on the back burner, but with minimal time loss or added
costs. Development tasks would not need to be placed on pause mid-development cycle, thus
avoiding unnecessary delays and added costs.
The Unknown Benefits of Agile
The business benefits that resulted from our team’s adoption of Agile were almost immediately
realized. But many long-term benefits came about later. Perhaps the biggest benefit came about
because of the change of thinking that Agile inspired among my team members. Later on, when the
Great Recession began and started to have an impact on our business growth, I met with my team to
discuss a pivot in our business development and product strategy to address the growing concerns and

4. emerging needs among our client prospects. The current product was robust, somewhat of an “all or
nothing” type of offering. Because of the flexibility that Agile had brought into our ability to pivot and
implement changes in bite-sized pieces from a programming and development standpoint, one of our
product managers suggested a similar approach with our portal. “What if we were to make each of our
features optional, so that a potential customer could pick and choose which features were of most value
to them, and avoid the feeling that they were paying for something that they didn’t need?”
What had never been considered before was now underway to become a reality. Not only did this
“agile” thinking provide the flexibility that our future customers desired, this change in product
literally saved our business from failing. Soon thereafter, our existing customers, who were also
suffering from the effects of the recession, contacted us with requests to cancel the service. We offered
the menu-priced, more flexible product option to them, along with a price reduction for the reduced
functionality. Almost every one of our customers agreed to this approach, and kept the portal in place.
We didn’t have the most profitable year that year, but managed to grow our revenue by 15% in a year
when we could have lost at least 50% of our subscription business.
Conclusion
Today, I am absolutely convinced that Agile methodology is the best way to go as far as product
development, project management, and change management are concerned. Not only does Agile work
as a more efficient process methodology, it helps to increase agile thinking throughout the
organization, thus inspiring employees to think in a more agile, or lean way in their problem solving
approach. It can also incorporate the client’s input into our process thinking.
According to Wrike, the work management platform software company, Agile is “a process for
managing a project that involves constant collaboration and working in iterations. Agile project
management works off the basis that a project can be continuously improved upon throughout its life
cycle, with changes being made quickly and responsively.
Agile is one of the most popular approaches to project management due to its flexibility, adaptability
to change, and high level of customer input.”
1
I highly recommend that companies consider migrating
to the Agile methodology (if they haven’t already) in order to keep up with the quickly changing trends
and customer demands within industries.
Sources
1. ‘What is Agile Methodology in Project Management?’; www.wrike.com