Guest View: Wrestling with scaling software agility

By Ryan Martens and Israel Gat

December 15, 2009 —

Agile champions spend a lot of time trying to communicate the agile premise to the executives in their organization. The difference in context between the champion and the executive often makes it a difficult conversation. A Scrum Master versed in behavior-driven design is not always able to relate to the frustrations of a sales executive who gets free advice on how to sell from everyone and his grandmother.

Conversely, a CFO does not necessarily understand why unit test coverage on the company's legacy code is still inadequate after a full year of investment in agile methods that embrace refactoring as a core practice.

To bridge the chasm through this article, we resort to role-playing. Ryan Martens plays the Agile Champion; Israel Gat plays the Skeptical Executive. Metaphorically speaking, each one tries to wrestle the other to the ground.

A note of caution before Ryan and Israel make irreparable damage to their long-standing relationship: The two actually understand each other extremely well and rarely are they of different opinions on the fundamentals of agile in real life...

How do I to assess and mitigate the risks of adopting agile?

The Skeptical Executive Asks: Ryan, I liked the materials you sent me about the benefits of agile development. I am particularly impressed with the opportunity to apply agile practices in conjunction with Lean in my company. Having said that, I am not so comfortable yet that I have a good handle on the risks involved in large-scale agile deployment. I am not talking “only” about execution risk; I am talking about competitive risk, market risk, branding risk, monetary risk and so on. What would be your advice? How do I to assess these risks of adopting agile, and how do I mitigate them?

The Agile Champion Responds: Israel, let's start with a definition of risk from David Anderson's talk at the agile 2009 conference. He said, "Risk is the likelihood and magnitude of the difference between the desired outcome and the actual outcome."

This requires us to understand your desired outcomes, how this agile implementation ties to your current strategies, and how likely you are to attain those goals if you do not work to scale the benefits of software agility across your organization. Most successful agile implementations have been done incrementally and iteratively with a focus on the highest-value and highest-risk projects, and this approach mirrors and reinforces the agile approach to development.

As we know, this adoption approach requires a prioritized backlog of work that is visible to the whole team, a road map of releases or transition steps, and a shared team commitment to making it happen. If you have these, you can deliver your change efforts in short cycles with feedback and actively mitigate the risks.

How do we balance what our executives need to know and the very limited time on their hands?

The Skeptical Executive Asks: Our company is not deep into technology; we are in the business of utilizing technology. Invariably our focus is on the needs of the customer, whether internal or external.

We have been quite successful in harnessing new technologies and methods to create value for our customers without acquiring deep expertise in the technologies we use in our products. For example, I would certainly expect our vice president of technology to be knowledgeable about agile and Lean development, but I can’t demand the other functional vice presidents to devote a significant amount of time to this subject. How do we strike the fine balance between what our executives need to know about agile development and the very limited time on their hands for doing so?

The Agile Champion Responds: Be open and honest with other VPs about your work, but do not over-promote the benefits until you have gotten some success and radically reduced risk. Once you can show tangible benefits and implications of a technology organization using agile methods, it will be time to introduce and talk about these concepts with other VPs.

Jim Highsmith's "Agile Project Management" introduces the concept of "delivering value over constraints" as a guiding idea for agile organizations. You will certainly want to introduce other executives to that model and the innovations in organizational and technical infrastructure, as well as changes in your methods and tools that will allow your organization to radically improve.

How do we attain effective reporting in a heterogeneous development environment?

The Skeptical Executive Asks: Let’s place agile methods in the context of other software processes we use at our company. Even if agile development were to sell like hotcakes, we will be running a heterogeneous environment—part agile, part waterfall, part ad hoc—for a long time. When we review the whole picture, we cannot compare apples to oranges, using one set of metrics for waterfall and another one for agile projects. This is not only a question of reporting, it is a matter of being able to effectively govern our portfolio. How do we attain effective reporting and governance in a heterogeneous development environment?

The Agile Champion Responds: If an organization manages a project portfolio, it is easy to get traditional metrics of earned value, remaining scope, quality, costs, risks, and resource allocation off of mixed project environments and into its portfolio management system or process. Agile adoption will be limited at first, and your portfolio management approaches will not change. However, the program managers working with the agile teams will be able to adjust to portfolio changes much more easily than their non-agile counterparts.

While it is true that agile teams will use different tactical metrics to assess their performance and maturity, those metrics do not go into the portfolio process. Though there is much to gain from a more agile and Lean portfolio approach, it is not one of the first things we encourage groups to put into their organizational change backlog.

Why would an investment in agile be more strategic to our company than investing in other areas of opportunity?

The Skeptical Executive Asks: Consider the money needed to “refactor” a company to be agile in the truest sense of the word. We can take that budget and apply it to any number of initiatives we want to roll across our business. Why should we invest it in agile development instead of other areas?

The Agile Champion Responds: As you allocate resources, understand that agile is a systemic change. It drives costs down, quality up and service levels higher by making the entire process leaner, the entire staff more responsible, and the customer more involved.

This change does not happen over night, and short-term needs cannot be ignored. For this reason, consider a two-pronged approach to adoption that addresses short-term needs but focuses a majority of the improvement resources on the more strategic agile adoption.

Ultimately the ROI of agile adoption will come from how well you focus to enable your core market differentiation as a low-cost provider, service leader or market innovator. Agile efforts should be focused at the strategic efforts in your company first. These are efforts that differentiate you and tend to have higher market and engineering risk. This is the sweet spot for agile in any company.

Ryan Martens is founder and CTO of Rally Software Development, which sells tools for agile development. Israel Gat is a senior consultant with the Cutter Consortium’s agile practice.

Related Search Term(s): agile, professional development

Share this link: http://www.sdtimes.com/link/33988

Rhodes framework brings agile to mobile development Tools for test-driven development and the ability to write interfaces in HTML facilitate the agile methodology

From the Editors: Agile isn't an all-or-nothing choice The editors say that shops should go their own way re: agile, and that mobile development gains from two main competitors

Agile world’s a stage Helping developers overcome their fear of agile development, consultants have team members act out and hang loose to get used to relinquishing control and aiming toward a team goal. Even though these techniques seem unorthodox, developers say that they work.

Comments

12/16/2009 10:31:39 PM EST

Extremely enjoyed reading this article. I wish that the executives would take about specific problems. Large backlog of required features to compete in rapidly changing market. Or probably customer churn. Generate more business from existing customers. Thanks, Sameh

CanadaSameh

Add comment

Name*
Email*
Country

Comment
Preview

News on Monday
more>>
SharePoint Tech Report
more>>

Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?

Google Code turns 5
Google Code Turns 5, and adds a Paxos Algorithm to make the system more stable and reliable.
03/17/2010 11:16 AM EST

Test your Visual Studio 2010 know-how
Microsoft is offering free beta certification exams for Visual Studio 2010.
03/17/2010 11:08 AM EST

Microsoft lifts the hood on IE9
Microsoft is previewing IE9.
03/16/2010 01:10 PM EST