Posts Tagged ‘Jim Highsmith’
From Vivek Kundra to Devops and Compounding Interest: Cutter’s Forthcoming Special Issue on Technical Debt
Source: http://www.flickr.com/photos/wallyg/152453473/
In a little over a month the Cutter Consortium will publish a special issue of the Cutter IT Journal (CITJ) on Technical Debt. As the guest editor for this issue I had the privilege to set the direction for it and now have early exposure to the latest and greatest in research and field work from the various authors. This short post is intended to share with you some of the more exciting findings you could expect in this issue of the CITJ.
The picture above of the debt clock is a common metaphor that runs through all articles. The various authors are unanimously of the opinion that one must measure his/her technical debt, embed the measurements in the software governance process and relentlessly push hard to reduce technical debt. One can easily extrapolate this common thread to conjecture an initiative by Vivek Kundra to assess technical debt and its ramification at the national level.
Naturally, the specific areas of interest with respect to technical debt vary from one author to another. From the broad spectrum of topics addressed in the journal, I would like to mention two that are quite representative:
- One of the authors focuses on the difference between the manifestation of technical debt in dev versus its manifestation in devops, reaching the conclusion that the change in context (from dev to devops) makes quite a difference. The author actually doubts that the classical differentiation between “building the right system” and “building the system right” holds in devops.
- Another author derives formulas for calculating Recurring Interest and Compounding Interest in technical debt. The author uses these formulas to demonstrate two scenario: Scenario A in which technical debt as % of total product revenue is 12% and Scenario B in which technical debt as % of total product revenue is 280%. The fascinating thing is that this dramatic difference (12% v. 280%) is induced through much smaller variances in the Recurring Interest and the Compounding Interest.
I will blog much more on the subject when the CITJ issue is published in October. In addition, Jim Highsmith and I will discuss the findings of the various authors as part of our joint seminar on the subject in the forthcoming Cutter Summit.
Stay tuned!
Forthcoming Technical Debt Events
In just about a week I will be sharing the latest and greatest in technical debt techniques through a Cutter webinar in which colleague John Heintz and I will be speaking . In a little over a month a special issue of the Cutter IT Journal [CITJ] on technical debt will be published. And, in a couple of months Jim Highsmith and I will deliver a workshop on the subject in the Cutter Summit.
Shifting from the process to its output (i.e. the code) is the common thread that runs through the three events. Rigorous that your implementation of the software process is, the proof of the pudding is the quality of the code your teams produce. The technical debt accrued in the code is the ultimate acid test for your success with the Agile roll-out and/or with any other software method you might be using.
Another important thread in all three events is a single source of truth. The technical debt data seen by the developer in the trenches, his/her project leader, the mid-level manager on the project, the vice president of engineering and the CFO/CEO represents different views of the realities of the code. Each level sees a different aggregation of data – all the way from a blocking violation at a specific line of code to the aggregate $$ amount required to “pay back” the debt. But, there is no distortion between the five levels of the technical debt data – all draw upon the code itself as the single source of truth.
Here is the announcement of the first event – the Reining in Technical Debt webinar scheduled for August 19, 12:00PM EDT:
Do you really govern the software development process in your IT organization or do its uncertainty and unpredictability leave you aghast? Do you manage to bake in quality in every build? Can you assess the quality of your software in a way that quantifies the risk?
Recent developments in software engineering and in software governance enable you to tie quality, cost, and value together to form a simple and effective governance framework for software. This webinar will provide you with a preliminary understanding of how to assess quality through technical debt techniques, will familiarize you with state-of-the-art tools for measuring technical debt, and will demonstrate the effect on value delivery when technical debt is not “paid back” promptly.
Israel and John will also introduce a governance framework that ensures you can rigorously manage your software development process from a business perspective. This framework reduces a large number of complex technical considerations to a common denominator that is easily understood by both technical and non-technical people — dollars.
Get Your Questions Answered
Don’t miss your chance to get specific advice from Cutter’s experts on technical debt and toxic code. Join us on Thursday, August 19 at 12:00 EDT (see your local time here) to learn how both your software development process(es) and the corresponding governance process can be transformed in a manner that will make a big difference to your software developers and testers, to key stakeholders in your company, and to your firm’s customers.
Register Now!
Register to attend so you’ll have the opportunity to have your specific questions answered. We’ll send you the login instructions a day prior to the webinar.
As always, this Cutter Webinar is not vendor sponsored, and is available to Cutter clients and our guests at no charge. Register here.
Pass this invitation along!
Be sure to extend our invitation to your CIO, CFO and the other senior business-IT leaders and trainers in your organization who you think could benefit from this discussion.
If you have any questions prior to the program, please contact Kim Leonard at kleonard@cutter.com or call her directly at +1 781 648 8700.
Can’t Make the Live Event?
You won’t miss out — the recording will be added to the webinarsonline resource center for client access, along with the rest of these past events.
This is Not a “Me Too” Product
I had the distinct pleasure to discuss AgileEVM over dinner yesterday with its two “fathers” – Chris Sterling and Brent Barton. I was much impressed by the originality of the concept, the clear differentiation of the product and the laser focus on Earned Value Management (EVM) aspects.
Governance of the software development process is a topic that has been much discussed in various Cutter publications – see for example recent Cutter blog posts by Stephen Andriole, Robert Charette, Jim Highsmith, Vince Kellen, Masa Maeda, Michael Mah and me. Chris and Brent add a layer of EVM – both in terms of theoretical foundations and actual tool – to our spectrum of thoughts on governance. IMHO AgileEVM has the potential to induce a disruption in the way companies go about the business of governing software.
AgileEVM is particularly intriguing as a {product + professional services} combo. Chris and Brent are well-known as awesome Agile consultants. The opportunity to pick their brains twice – once through the product, a second time through a related consulting engagement with them – is most attractive.
The two “pages” below give a sense of the power of the product. Even better, simply download the product through the AgileEVM website.
Grab Chris or Brent for a 1-1 demo if you are at Agile 2010 this week. You will not be disappointed…
How to Combine Development Productivity Data with Software Quality Metrics
Consider the situation described in Should You Invest in This Software:
- One of your portfolio companies expects to ship 500K lines of code in 6 months.
- The company asks for additional $2M to complete development and bring the product to market.
- Using technical debt quantification techniques you find the technical debt amounts to $1M.
You are not at all comfortable “paying back” the technical debt in addition to funding the requested $2M. You wonder whether you should start afresh instead of trying to complete and fix the code.
Photo credit: @muntz (Flickr)
A good starting point for assessing the fresh start option is Michael Mah‘s studies of software productivity. Based on the QSMA SLIM metrics database of more than 8,000 projects, Michael will probably bracket the productivity per person in a team consisting of product management, development and test at 10-15K lines of code per year. If you use the 15K lines of code per year figure for the purposes of the analysis, 500K lines of code could theoretically be delivered with an investment of about 33.3 (500/15) man years. Assuming average loaded cost of $99,000 per man-year, the software represents a programming effort of $3.3M. Not much is left if you deduct $3M ($2M+1M) from $3.3M…
Five considerations are of paramount importance in evaluating the start afresh option:
- The comparison above ($3.3M versus $3.0M) is timeless. It is a snapshot at a certain point in time which does not take into account the value of time. To factor in the time dimension, the analysis needs to get into value (as distinct from cost) considerations. See the note on Intrinsic Quality v. Extrinsic Quality at the bottom of this post.
- Your “mileage” may vary. For example, best in class teams in large software projects have reported productivity of 20K lines of code per team member per year. As another example, productivity in business applications is very different from productivity in real-time software.
- If you decide to start with a brand new team, remember Napoleon’s quip: “Soldiers have to eat soup together for a long time before they are ready to fight.”
- If you decide to start afresh with the same team plus some enhancements to the headcount, be mindful of ‘Mythical Man-Month‘ effects. Michael Mah’s studies of the BMC BPM projects indicate that such effects might not hold for proficient Agile teams. Hence, you might opt to go Agile if you plan to enhanced the team in an aggressive manner.
- Starting afresh is not an antidote to accruing technical debt (yet again…) over time. But, it gives you the opportunity to aggressively curtail technical debt by applying the techniques described in Using Credit Limits to Constrain Development on Margin. For example, you might run source code analytics every two weeks and go over the results in the bi-weekly demo.
As long as you are mindful of these five aspects (timeless analysis, your mileage may vary, Napoleon’s quip, mythical man-month effects and credit limits on technical debt), combining technical debt figures with productivity data is an effective way to consider the pros and cons of “fix it” versus starting afresh. The combination of the two simplifies a complex investment decision by reducing all considerations to a single common denominator – $$.
Note: This is not a discussion from a value perspective. The software, warts and everything, might (or might not) be valuable to the target customers. The reader is referred to Jim Highsmith‘s analysis of Intrinsic quality versus Extrinsic Quality in Agile Project Management: Creating Innovative Products. See the Cutter Blog post entitled Beyond Scope, Schedule and Cost: Measuring Agile Performance for a short summary of the distinction between the two.
Delivering Valuable Software, guest Jim Highsmith – Agile Executive #5
To listen to this podcast, download the podcast directly, subscribe to the blog/podcast feed in iTunes (or whatever), or click play below to hear it:
In this episode, Israel and I talk with Jim Highsmith. We center the discusion around the new edition of Jim’s book, Agile Project Management, but this pulls in all sorts of general discussion about Agile:
- How did Jim get into Agile? Going from traditional software development to Agile.
- How does Rapid Development compare to Agile? Tools in RAD vs. tools in Agile.
- Pivoting on a mention of Jim being in China, I ask him about cultural differences of applying Agile, for instance, based on geo-cultural differences.
- What’s new in the new edition that leads into larger applications of Agile? Release planning, “scaling” self-organizing teams, governance issues, and measuring.
- How does Agile work in a systems, or hardware plus software situation.
- Israel asks Jim for some advice on synching up software developed in an Agile fashion with hardware folks. There’s primarily more coordination and dependency management between teams and features.
- Release planning – most Agile teams focus on iteration planning, without peaking up to concerns at the release level, e.g., budgeting, timing, and marketing concerns.
- How can “the business” get involved with the process to make sure focus is kept on the release?
- What’s this “scaling” business? Scaling a team up in size, or scaling a team out in a distributed process.
- Israel and Jim then dig into distributed scaling, adding in off-premise teams and collaboration.
- Tracking and measuring things from a (business) strategic orientation. This hits on keeping track of value (will this software make us money?), quality and other “metrics” over time. Who is that determines this “value” ongoing? Getting people to figure out “value points.”
- Israel then asks Jim for a retrospective on where we’ve been and are after the Agile Manifesto.
Also, see Jim’s sum-up of the new content in the book.
The Agile Executive 
Cutter’s Technical Debt Assessment and Valuation Service
with 3 comments
The Cutter Consortium has announced the availability of the Technical Debt Assessment and Valuation Service. The service combines static code analytics with dynamic program analytics to give the client “x-rays” of the software being examined at any desired granularity – from the whole project portfolio to a single instruction. It breaks down technical debt into the areas of coverage, complexity, duplication, violations and comments. Clients get an aggregate dollar figure for “paying back” debt that they can then plug into their financial models to objectively analyze their critical software assets. Based on these metrics, they can make the best decisions about their ongoing strategy for the software development effort under scrutiny.
This new service is an important addition to the enlightened software governance framework that Jim Highsmith, Michael Mah and I have been thinking about and contributing to for sometime now (see Beyond Scope, Schedule and Cost: Measuring Agile Performance and Quantifying the Start Afresh Option). The heart of both the technical debt service and the enlightened governance framework is captured by the following words from the press release:
By boiling down technical debt to dollars and tying it to cost and value, the service enables a metrics-driven governance framework for the use of five major constituencies, as follows:
It should finally be pointed out that the technical debt assessment service and the governance framework it enables are applicable to any software method. They can be used to:
Forthcoming Cutter Executive Reports, Executive Updates and Email Advisors on the technical debt service are restricted to Cutter clients. As appropriate, I will publish the latest and greatest news on the subject in the Cutter Blog (which is an open forum I highly recommend).
Acknowledgements: I would like to wholeheartedly thank the following colleagues for inspiring, enlightening and supporting me during the preparation of the service:
Written by israelgat
May 5, 2010 at 4:40 am
Posted in Agile Performance Management, Companies, Events, Performance Measurement, Software Costs
Tagged with Anne Mullaney, CEO, Chris Sterling, Cindy Swain, CIO, Comments, Complexity, Coverage, CTO, Cutter Consortium, Duplication, Governance Framework, Industry Norms, Israel Gat, IT Operations, Jennifer Flaxman, Jim Highsmith, John Heintz, Jonathon Golden, Kara Letourneau, Karen Coburn, Ken Collier, Kim Leonard, M&A, Michael Mah, NPV, Paying Back, Software Method, Technical Debt, Valuation, Venture Capitalist, Violation