The Agile Executive

Making Agile Work

Posts Tagged ‘Israel Gat

Cutter’s Technical Debt Assessment and Valuation Service

with 3 comments

 

 

Source: Cutter Technical Debt and Valuation Service

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:

Executives in charge of software governance have long dealt with two kinds of dollar figures: One, the cost of producing and maintaining the software; and two, the value of the software, which is usually expressed in terms of the net present value associated with the expected value stream the product will generate. Now we can deal with technical debt in the same quantitative manner, regardless of the software methods a company uses.

When expressed in terms of dollars, technical debt ties neatly into value vis-à-vis cost considerations. For a “well behaved” software project, three factors — value, cost, and technical debt — have to satisfy the equation Value >> Cost > Technical Debt. Monitoring the balance between value, cost, and technical debt on an ongoing basis is an effective way for organizations to stay on top of their real progress, and for stakeholders and investors to ensure their investment is sound.

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:

Technical debt assessments and valuation can specifically help CIOs ensure alignment of software development with IT Operations; give CTOs early warning signs of impending project trouble; assure those involved in due diligence for M&A activity that the code being acquired will adapt to meet future needs; enables CEOs to effectively govern the software development process; and, it provides critical information as to whether software under consideration constitutes an asset or a liability for venture capitalists who need to make informed investment decisions.

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:

  • Govern a heterogeneous environment in which multiple software methods are used
  • Make apples-to-apples comparisons between disparate software projects
  • Assess project performance vis-a-vis industry norms

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:

  • Karen Coburn
  • Jennifer Flaxman
  • Jonathon Golden
  • John Heintz
  • Jim Highsmith
  • Ken Collier
  • Kim Leonard
  • Kara Letourneau
  • Michal Mah
  • Anne Mullaney
  • Chris Sterling
  • Cindy Swain
  • Sarah Wiesbrock

The Concise Executive Guide to Agile

with 3 comments

a

a

The IEEE Computer Society Press published today a ReadyNote[1] that I authored entitled The Concise Executive Guide to Agile. It is available through the IEEE Computer Society Store. A Kindle version will be published in June.

I had two main objectives in writing the guide:

  1. Provide the know-how for approaching Agile in a concise manner that requires minimal investment of time and effort by the reader. The ReadyNote does so by summarizing most Agile topics in a page or two. Detailed coverage of a topic is left for follow-on reading in the selected references that accompany each topic and in the Further Reading appendix.
  2. Be accessible to any executive  — R&D, Marketing, Sales, Program Management, Professional Services, Customer Support, Finance, or IT.  The only assumption I make is that the reader has a conceptual grasp of software and software engineering as well as an interest in learning about Agile. No deep knowledge, let alone technical knowledge, about software engineering is required for comprehending the guide.

There is no fluff in the guide. Every paragraph has been written to satisfy the “And therefore what?!” criterion. It is my intent to drive a point home and make it clear to the reader what he/she could do with the information in as few words as possible.

A simple acid test for the guide is your successful assimilation of it in entirety during a flight in the continental US. Something has not quite worked if you need to fly all the way from the US to Europe or vice versa in order to comprehend the guide…

I would like to express my sincere thanks to Michael Cote, Michael Mah, Hubert Smits and to the fourth reviewer (whose identity I don’t know) for their many helpful insights and suggestions. I am also deeply indebted to Linda Shafer and Kate Guillemette of the IEEE Computer Society who got me to write the guide and supported the writing and editing process along the way.

Enjoy reading!

Footnotes:

  1. “ReadyNotes are short e-books that are tightly focused on specific topics” [IEEE Computer Society Press].

Apropos – The Inovis End-to-End Kanban System

with 4 comments



Figure 1:  End-to-end flow slide from Reformulating the Product Delivery Process

Erik HuddlestonWalter BodwellStephen Chin and I delivered a presentation at LSSC10 on the design and implementation of the end-to-end Kanban system Apropos at Inovis. The presentation highlights four key ingredients of the ‘secret sauce’ that makes Apropos so powerful:

  • Stakeholder Based Investment Themes
  • Business Case Management
  • Upstream and Downstream WIP Limits
  • Dynamic Allocations

You can read the slides here. A recording of the presentation will soon be posted by InfoQ. A commercial friendly open-source license of the code will be available on May 22, 2010.

Reformulating the Product Delivery Process

leave a comment »

LSSC ATLANTA 2010

Erik Huddleston, Walter Bodwell, Stephen Chin and I will  present and demo an end-to-end Kanban system that addresses the #1 challenge modern software methods pose – reformulation of the product delivery process. We will do so the coming Friday, April 23, 10:45AM at the Lean Software and Systems Conference. Here is the abstract for our presentation/demo:

Software methods can be viewed as the glue that holds the product development process together. With Kanban, the glue is melting on both sides of the process. Traditional portfolio management systems and organizations have difficulty coping with the granularity of Kanban. Likewise, today’s product release and delivery systems and the corresponding organizational constructs are ill-equipped to effectively handle the Kanban flow.

We present a field-tested system for implementing Kanban on an end-to-end basis – from product ideation through continuous delivery. This system reformulates the deconstructed product delivery process to strike an optimal balance between planning, development and operations.

Written by israelgat

April 21, 2010 at 3:25 am

Toxic Code

with 2 comments

“[The 100% loan-to-value subprime loan is] the most dangerous product in existence and there can be nothing more toxic…”

This quip by Angelo Mozilo, founder of Countrywide Financial, led me to coin the term “toxic code.” The code stops being an asset when it accumulates technical debt equal to the value it is expected to generate. As matter of fact, the code could become a liability when the cost to “pay back” the technical debt exceeds the revenues the code would generate. Such situations have been known to happen more often than we might realize. They occur, for example, when numerous customers develop elaborate business processes around poor quality enterprise software.

I will be exploring the topic in my May 27, 2010 presentation at The Path to Agility conference in Columbus, OH. Here is the abstract of my talk:

Technical debt had originally been conceived as an expediency measure – “a little debt speeds development so long as it is paid back promptly with a rewrite.” However, like financial debt, unrestrained borrowing can lead to a broad spectrum of difficulties, from collapsed roadmaps to inability to respond to customer problems in a timely manner, and anything in between.

Recent advances in source code analysis enable us to quantify technical debt and express it in $$ terms. By so doing, the software development process can be governed with unprecedented effectiveness. It is possible to constrain the “development on margin” mal-practice and avoid the toxic code phenomenon: technical-debt-to-value ratio of 100%. Moreover, even toxic code can ultimately be “marked-to-market” by reducing/eliminating technical debt.

The combination of Agile refactoring practices with technical debt analytics brings rigor to the software development process through:

  • Providing quantifiable data about the overall state of the code and its value
  • Highlighting error-prone modules in the code and offering guidance to fixing them in a biggest-bang for-the-buck manner
  • Pinpointing technical issues all the way down to the individual line of code level
  • Balancing the technical debt work stream vis-a-vis other work streams

In the course of managing software development in this manner, your team will improve its design, coding, testing and project management skills. Ultimately, these improvements are the best antidote against accrual of technical debt in the future.

Written by israelgat

April 19, 2010 at 4:45 am

Preface from The Concise Executive Guide to Agile

with one comment

ICS_black_stacked.jpg

The good folks at the IEEE Computer Society are just about ready to publish my e-book The Concise Executive Guide to Agile. It will be available for purchase in the Computer Society store in May. A Kindle version will follow in June.

Here is the preface from the guide:

Preface: Connecting the Agile Dots

“The closer one listens to it, the more distantly one hears it.”[1] These insightful words about Schubert’s Unfinished Symphony apply equally well to the art of Agile software methods. The nuts and bolts of Agile methods are not likely to be very relevant to the executive. Instead, he or she needs to stand back and focus on the mindset, values, and principles that make Agile methods so powerful, and on harnessing their power to create business value.

It is the objective of this guide to provide the know-how for approaching Agile in a concise manner that requires minimal investment of time and effort by the reader. It does so by summarizing most Agile topics in a page or two with minimal use of geek jargon. Detailed coverage of a topic is left for follow-on reading in the selected references that accompany each topic and in the Further Reading appendix.

The guide targets executives as the primary audience. It gives them the principles they need to comprehend and apply in order to become effective with an Agile initiative. These executives are not necessarily software engineering experts. They come from any function that Agile affects — R&D, Marketing, Sales, Program Management, Professional Services, Customer Support, Finance, or IT. Nor are the executives restricted to companies whose business is software; they are as likely to reside in companies that embed software in their products or utilize software in implementing business initiatives. Nowadays one can hardly think of a company that would not be included in at least one of these three categories.

Four broad topics are covered in The Concise Executive Guide to Agile: rationale for Agile, implementing it, fitting it into your company, and scaling it to the enterprise level. The rationale explains why Agile is so appropriate for our time, summarizes the state of the art in Agile, and sets realistic expectations with respect to its business value. Implementing addresses critical “real life” issues such as risk assessment and mitigation, off-shoring and outsourcing, governance, and sustainability of the Agile initiative. Fitting connects Agile to the hard realities of introducing a new software method into an environment in which various processes already exist — multiple software methods as well as planning and budgeting processes. Scaling is primarily about the numerous benefits to be attained through end-to-end implementation, such as enabling new business designs that fully utilize the power of Agile.

In the course of covering these four topics, the guide puts special emphasis on the operational, financial, and business benefits of Agile methods. The overarching message is clear and simple: Agile is the most productive technology your business is not using.


[1] Giuseppe Sinopoli. “Dream and Memory in Schubert’s ‘Unfinished.’” Program Notes to his recording of the symphony with the Philharmonia Orchestra, Deutsche Grammophon 410 862-2, 1984.

Written by israelgat

April 12, 2010 at 4:35 am

Wrestling with Scaling Software Agility

with 2 comments

Software Development Times has just published Guest View: Wrestling with Scaling Software Agility by Ryan Martens and me. This Guest View is a little unique in that Ryan and I actually try to wrestle each other to the ground… Here is why we try to do so:

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.

Before you get into this Guest View, I would like to reinforce an important disclaimer:

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…

Enjoy the article!

An Update on Agile Business Service Management

leave a comment »

A previous post in this blog defined the demarcation line between The Agile Executive and BSM Review as follows:

If software development is your primary interest, you might find my forthcoming posts in BSM Review go a little beyond the traditional scope of software methods. If, however, you are interested in software delivery in entirety, you are likely to find good synergy between the topics I will address in BSM Review and those I will continue to bring up in The Agile Executive. Either way, I trust my posts and Cote’s will be of on-going interest to you.

Since writing these words, I realized how tricky it is to adhere to this differentiation. The difficulty lies in the “cord” between development and operations. Development needs to devise algorithms that take into account operational characteristics in IT. Operations needs to comprehend the limits of such algorithms in the context of the service level agreements and operational level agreements that had been negotiated with their customers (either external or internal). The mutual need is particularly strong in the web application/web operations domain where mutual understanding, collaborative work and joint commitment often need to transcend organizational lines.

Given the inherently close ties between development and operations, here are some BSM Review articles and posts that are likely to be of interest to readers of The Agile Executive:

It is a little premature at this early stage to project how BSM Review will evolve. My hunch is that forthcoming articles in BSM Review on cloud computing, large-scale operations, leadership, risk mitigation and technology trends will be of particular interest to readers of this blog.

Open Source Software and Agile Software Development: Parallels and Lessons for Enterprise IT

with one comment

Cutter Consortium has published the Executive Update entitled Open Source Software and Agile Software Development: Parallels and Lessons for Enterprise IT by Sebastian Hassinger (“Seb”) and me. Here is the abstract:

The phenomenon of open source software (OSS) is a recognized and mature aspect of the global IT market with profound implications for enterprise IT. A newer trend emerging is the various disciplines and methodologies that fall under the rubric of agile software development, which has a number of interesting parallels with and similarities to OSS. With the adoption en masse of OSS projects, such as Linux and Apache, by the mainstream enterprise customer, there is a track record of more than 10 years with which to gauge the extent and the nature of the impact on the enterprise. While agile has not yet reached the level of adoption that OSS enjoys, all indications are positive for that occurring in the near future. By examining its parallels with OSS, one can make inferences about the nature of the long-term potential impact of agile.

I am honored to co-publish with Seb!

(If you have not yet “e-met” Seb, here is his bio:

Sebastian Hassinger has worked in the IT industry for more than 25 years in large firms and as an entrepreneur. He founded two ISPs, helped launched several startups, and held senior strategy and business development roles with Apple, IBM, and Oracle. Mr. Hassinger created the first customer support Web site for Apple Computer. At IBM, he helped create a new business unit in the Tivoli subsidiary to address the needs of system management in the Internet era; worked on special projects for Tivoli’s CTO, including defining an Internet protocol for management of dynamic services; and was Senior Strategist for IBM’s Pervasive Computing initiative. At Oracle, Mr. Hassinger is Director of Market Development, where his specific responsibilities include developing the financial services market worldwide and the Asia-Pacific horizontal market. He holds MBAs from Columbia University and London Business School, is a published author, and holds more than a dozen software and business model patents. He can be reached at shassinger@gmail.com).

Teach Your Boss to be Agile with a Social Contract – Guest Post by Alan Atlas

with 4 comments

When I [Israel] joined BMC Software in Fall 2004, I made a promise to each and every one of the hundreds of employees in my business unit:

I commit to read and respond within 48 hours to any email you send me. My answer is not likely to be long as I am drinking from a hose right now. But, it will be substantive.

Till this very day, various ex-employees of mine tell me that this simple statement was actually the first step toward our adopting Agile – it created mutuality in our relationships. A few months later, when we started discussing the ground rules for Agile team empowerment, I was credible with respect to adhering to voluntary “contracts” due to the mutuality established in the “email policy” cited above (and other “it cuts both ways” steps we as a management team have taken along the way).

Fast forward five years to today. How delightful it was to get the guest post below from Rally coach Alan Atlas. His post has taken me all the way back to the very gratifying experience of starting the enterprise-level Agile “adventure” at BMC. Furthermore, Alan’s post made me realize I need to add mutuality as the fifth ingredient in my ‘secret sauce’ for large-scale Agile implementations.

Here is Alan:

Hey, how’re you doing? How’s the new Agile thing going? What? Oh, yeah. We had that same thing. The manager thing. Yep. It can be a killer! Wanna know what we did?

Dan Rawsthorne first introduced me to social contracts. He had put together an example that was called something like “Contract Between the Team and the Organization”.  Israel Gat’s work on Agile Social Contracts gives perspective on using them at the enterprise level.

I have put social contracts to good use more than once, and I am convinced that they are a tool that has much to offer to coaches, consultants, and maybe most importantly, internal Agile champions at companies around the world.

Most of us are familiar with the idea of Working Agreements. Working Agreements are a form of social contract that is often used to help a self-organizing team to establish behavioral standards without having them imposed from the outside (e.g., by a manager). Working Agreements are:

  • Established and changed by mutual agreement
  • Enforced by mutual agreement
  • Outside of established corporate legal structure, and
  • Made between peers.

A social contract, at least the way I have seen them created and used, is essentially a Working Agreement between non-peers.  In an Agile context, social contracts are written between a team and its management, or a team and its encompassing organization.

Of what use is an agreement in which each clause can be summarized as “I promise to do something that you want until I change my mind”? I think there are two really important benefits to be realized by using social contracts:

  • They codify and externalize the agreement, making the substance of the agreement clear, and
  • They form the basis of an “interaction between people” (i.e., a conversation).

Here’s an extract from a hypothetical Social Contract:

  1. The Organization and the Team agree that:
    1. Customer satisfaction is our ultimate goal
    2. Mutual respect will be the foundation for trust between all parties
    3. The Team promises the Organization that:
      1. It will develop the most valuable software, as defined by the Organization through the Product Owner, at all times
      2. It will provide transparency in all things related to its activities
      3. The Organization promises the Team that:
        1. The Team’s success will be judged by the production of working software
        2. The Team will have a Product Owner and a Scrum Master and a reasonable expectation of team stability

Yes, it does seem a bit idealistic and maybe even unrealistic. Yet, it is invaluable when used in the following way:

“Hey Boss. One part of launching the team on Scrum is to sit down with you and go over our social contract. Let’s take a look and talk about the things that are in here.”

The social contract is, above all things, a means to direct a conversation with your manager about roles and behaviors in the new world of Scrum. If you can all actually agree on one, and even sign it, Wow! But if you can’t, you can still use it to begin to teach your boss (I bet she wasn’t included in team Scrum training, was she?) how to be a good boss in an Agile world. If you are afraid of broaching certain subjects, arrange to have a neutral Agile coach supply you with an Agile contract, in which case you can’t be blamed for the content.

“The Organization promises the Team that impediments raised by the team will receive prompt and thorough attention at all levels.”

“The Team promises the Organization that it will adhere to all corporate quality standards when building software.”

“The Team promises the Organization that it will maintain the highest possible level of technical rigor through design and code reviews.”

And on and on…

Don’t be too disappointed if it never gets completely agreed and signed and put on the wall. Use it to open up a dialog with your management that you can build on over time.

Written by israelgat

November 5, 2009 at 7:46 am