As Borland evolved over the last 25 years, acquiring companies and shifting business strategies, the delivery organization had become a collection of teams with different cultures, processes, release cycles and levels of performance. The cost structure of the organization wasn't aligned with the strategic objectives of the company, and the teams were struggling to consistently meet delivery goals.
In 2006, Borland's leadership made the decision to transition this development organization—more than 350 engineers, working on a broad portfolio of development projects from 13 different locations around the world—to a more Agile approach as part of an effort to vastly improve performance, be more responsive to customers and improve quality.
In February of that year, Borland piloted an Agile project on a totally new product to determine whether the methodology could help achieve three key goals: reduce delivery time, improve overall product quality, and ensure the product met the market need by engaging customers in the development process. The project was extremely successful; the team released the product ten days ahead of schedule and with more features than originally requested.
In expanding its use of Agile throughout the organization, Borland decided to use a stepwise, iterative approach to transformation based on geography—converting one location at a time. Like most organizations considering an Agile transformation, Borland faced the challenge of making a major process shift while still executing an aggressive product roadmap. Our business is to deliver innovative software products to the market, and market pressures, customer expectations and business needs made it impossible for us to "take a break" to do a process overhaul. Thus, we faced a situation where we were changing the tires while the car was still in motion. Today, Borland is in "the thick" of transformation: with approximately 70 percent of teams utilizing Agile methodologies—and reaping tremendous benefits.
In this article, I will share some of the experiences from our Agile journey, highlighting decisions we made, challenges we faced and lessons we learned along the way.
Building and Empowering the Self-Managing Team
When you have a team of people somewhat new to Agile, it can be difficult to keep them aggressively moving forward on a business goal while also staying true to Agile principles. The reality is that people tend to revert back to behavior that has personally served them well in the past. At the start of our transition, we made a concerted effort to ensure that both teams and management kept their eyes on the long term goal—the business outcome we were striving for—which was not to successfully implement Agile, but to improve productivity and team performance. Thus, when formulating our "base" team structure, we made the following decisions:
Recruit a full-time Agile expert
We felt it important to have someone who could mentor new Scrum Masters while coaching the teams and evangelizing the Scrum as we expanded it across the broader organization.
Combine the Scrum Master and Development Manager/Director Roles
In some cases, we found it necessary to deviate a bit from the traditional rules of Agile—one such example is our decision to give some of our managers a dual role: manager and also Scrum Master. We were able to do this only by hiring "enabling" management types: individuals who were less authoritative in their management style and much stronger in leadership skills. Managers who were less risk averse were able to put on their more enabling "Scrum Master Hats" and help their teams succeed by removing obstacles and empowering them to make decisions and mistakes.
Keep an eye on traditional "functional leads"
In a traditional team you have technical leads for various functional areas. Functional areas are usually very well defined and everyone on the team understands who's driving what and where the direction should be coming from. In a well-formed Agile team, the lines between technical leaders start to blur and that can be stressful for those leaders accustomed to such well-defined roles. In our case, we had some "technical