The Agile Executive

Making Agile Work

Posts Tagged ‘Forrester Research

Forrester on Managing Technical Debt

leave a comment »

Forrester Research analysts Dave West and Tom Grant just published their report on Agile 2010. Here is the section in their report on managing technical debt:

Managing technical debt

Dave: The Agile community has faced a lot of hard questions about how a methodology that breaks development into short iterations can maintain a long-term view on issues like maintainability. Does Agile unintentionally increase the risk of technical debt? Israel Gat is leading some breakthrough thinking in the financial measures and ramifications of technical debt. This topic deserves the attention it’s beginning to receive, in part because of its ramifications for backlog management and architecture planning. Application development professionals should :-

  • Starting captured debt. Even if it is just by encouraging developers to note issues as they are writing code in the comments of that code, or putting in place more formal peer review processes where debt is captured it is important to document debt as it accumulates.
  • Start measuring debt. Once captured, placing a value / cost to the debt created enables objective discussions to be made. It also enables reporting to provide the organization with transparency of their growing debt. I believe that this approach would enable application and product end of life discussions to be made earlier and with more accuracy.
  • Adopt standard architectures and opensource models. The more people that look at a piece of code the more likely debt will be reduced. The simple truth of many people using the same software makes it simpler and less prone to debt.

Tom: Since the role I serve, the product manager in technology companies, sites on the fault line between business and technology, I’m really interested in where Israel Gat and others take this discussion. The era of piling up functionality in the hopes that customers will be impressed with the size of the pile are clearly ending. What will replace it is still undetermined.

I will be responding to Tom’s good question in various posts along the way. For now I would just like to mention the tremendous importance of automated technical debt assessment. Typical velocity of formal code inspection is 100-200 lines of code per hour. Useful and important that formal code inspection is, there is only so much that can be inspected through our eyes, expertise and brains. The tools we use nowadays to do code analysis apply to code bases of any size. Consequently, the assessment of quality (or lack thereof) shifts from the local to the global. It is no more no a matter of an arcane code metric in an esoteric Java class that precious few folks ever hear of. Rather, it is a matter of overall quality in the portfolios of projects/products a company possesses. As mentioned in an earlier post, companies who capitalize software will sooner or later need to report technical debt as line item on their balance sheet. It will simply be listed as a liability.

From a governance perspective, technical debt techniques give us the opportunity to carry out consistent governance of the software process based on a single source of truth. The single source of truth is, of course, the code itself. The very same truth is reflected at every level in the organization. For the developer in the trenches the truth manifests itself as a blocking violation in a specific line of code. For the CFO it is the need to “pay back” $500K in the very same project. Different that the two views are, they are absolutely consistent. They merely differ in the level of aggregation.


The Agile Regime Change – Guest Post by Tom Grant

with 2 comments

Forrester’s Tom Grant shares with us his observations from the recent Agile Success Tour in Santa Clara, thoughts where the Agile movement is and lessons from history we all should pay attention to. His post is characterized by breadth of vision and depth of knowledge.

Tom is a Senior Analyst at Forrester Research, specializing in the technology industry’s challenges in product development and adoption. He has recently published research on the effects of Agile within technology companies, the use of social media as a new source of product requirements, and the roles of product management and product marketing. Before joining Forrester in 2008, Tom ran product management teams at big companies, such as Oracle, and small companies, such as Xythos.

Here is Tom’s post:

 By all appearances, the Agile revolutions is entering a new phase, by moving along the same path that many revolutions follow. We’re now at the point where revolutionary movements succeed or fail, based on their ability to be pragmatic and inclusive.
Revolution and pragmatism
In the 18th and 19th centuries, political thinkers and practitioners in the Old and New Worlds pondered the differences between the American and French Revolutions. How did the leaders of the American Revolution replace a distant monarchy with a benign republic, with violence limited to a traditional war among field armies? Why, in contrast, did the French revolutionaries eventually exchange their king for an emperor? And why did the Revolution turn its violent wrath on civilians?
Many pointed to the enlightened pragmatism of Jefferson, Washington, Madison, and other American revolutionaries. The leaders of the American Revolution made profound political changes that took human nature into account, without trying to change it. Madison, for example, argued in the Federalist papers for a form of government that took into account the “propensity of mankind to fall into mutual animosities,” instead of trying to cure people of these nasty tendencies.
In contrast, the radicals who eventually gained the upper hand in the French Revolution had a more ambitious agenda. For example, the Jacobins sought to “cure” citizens of their attachment to religion. Unfortunately, they didn’t replace one deeply personal source of inspiration and solace, the Church, with anything comparable. Not surprisingly, when the revolution regime fell under internal and external attack, the Jacobin leaders were unable to mobilize the support they needed, and the revolution collapsed.
The historian Charles Caleb Colton made this point succinctly: “Thus the American Revolution, from which little was expected, produced much; but the French Revolution, from which much was expected, produced little.”
Agile and pragmatism
Last week, both Israel Gat and I attended Rally’s “Agile Success Story Tour” (he as a presenter and moderator, me as an audience member). The success stories themselves had a clear, obvious common thread: Agile success depends on adapting methods to fit the organization, which encompasses a lot more than just the development team. For example, George Morris of Roche stressed how important it was to manage the “impedance mismatch” between Agile and non-Agile teams. Doug Miller of  Thermo Fisher Scientific argued that, to accommodate concerns like FDA regulations, his team needed to treat Agile and Waterfall as a continuum, not a binary choice.
These narratives of Agile success did not involve comparisons between the virtues of Scrum over XP,  analyses of the right build environment for Agile development teams, or many of the other familiar topics from the last several years of Agile discussions.
Just a new constitution re-defines how politicians and civil servants should behave, Agile introduces new practices, such as continuous integration, daily Scrum meetings, and test-driven development, that prescribe new behaviors for development teams. However, as shown in these success stories, the Agile revolution depends on more than just a new constitution. For any new regime to succeed, it must bring the rest of the country, or the organization, along with it.
From the particular to the general
Of course, you may wonder if any single success story, no matter how compelling it sounds, is really representative. That question has more than just academic interest, if you’re trying to repeat the same experiment successfully.
Fortunately, the broader data support the success stories presented at the Agile Success Story Tour. For a recent Forrester study about Agile in the technology industry, “From Agile Development To Agile Engagement,” we surveyed a broad range of tech industry professionals—some in development, others not. Among other results, we found that the vast majority of implementations mix Agile with other techniques, and don’t treat Agile as a strict orthodoxy.
Since we spoke to more than just the members of the development team, we also had a chance to spot how Agile changes the relationships between Development and other groups. The “impedance mismatch” that Roche’s George Morris reported is by no means a unique experience. Without a deliberate effort, the relationship between Development and other groups does improve to some degree. The amount of improvement depends on how close to the development process the other group is. On average, the relationship between Development and PM, for example, improves more than the relationship between Development and Sales.
In other words, Agile in its original form, new techniques for product teams to follow, is a mixed blessing. Improvements happen, but not necessarily everywhere they need to. As the technology industry has matured, vendors have gradually learned that, for innovation to succeed, the customer-facing groups, such as Sales, Professional Services, and Support (not to mention partners), have to work in closer sync with the Development team. Throwing code over the wall is a formula for failure. Throwing code over the wall faster is not a formula for success.
The people who move the Agile revolution forward from this critical juncture should ponder what Edmund Burke said about the English political system, in contrast to the French Revolutionary regime: “Our patience will achieve more than our force.”

Written by israelgat

June 18, 2009 at 7:18 pm