GROOVY

Agile methods have entered the mainstream, but they

don’t automatically create success. Product Owners play

a key role in creating successful products. In this issue

of JAXmag, we take a look at a whole range of topics

surrounding the agile ecosystem, from product owners

to coaches, to the process itself. This and much more will

also be covered at the upcoming JAX London, so make a

note of the date: www.jaxlondon.com

People and ProcessTwo Sides of the Same Coin

Agile CoachingUnderstanding The Role

Demystifying the Product OwnerThe Role in Scrum

Bad Code isn’t Technical Debt …… it’s an unhedged Call Option

Java, Enterprise Architecture, Agile and Eclipse

www.jaxenter.comIssue December 2010 | presented by

#4

Agile Development

Agile Day

at JAX London

http://www.jaxenter.com

http://www.jaxlondon.com

www.JAXenter.com | December 2010 2

Editorial

Agile software development has come a long way since the late nineties when I discovered what is now known as agile practices. Back then even the term agile software develop-ment had not been coined. Today there are various agile ap-proaches and methods to choose from with an ever-growing number of books, training courses, and instructional videos. This can make it hard to see what is central to agile develop-ment: teams that collaborate with stakeholders to create great products in a sustainable way.

This edition of the JAXmag discusses four important agi-le software development trends: Karl Scotland explains why people are more important than processes introducing some of the foundations of Kanban. Rachel Davies discusses why coaching is key to become great at agile development. I write

Four Trends in Agile Software Development

about the importance of engaging the business and the pro-duct owner role to create great products, and Steve Freeman explains the idea of technical options highlighting the signifi -cance of software quality and craftsmanship.

To learn more about the latest trends in agile software de-velopment, join me at the Agile Day at the next JAX London conference. The day takes palce on 11th April at the Park Pla-za Victoria in London. It offers insights into what it takes to become agile and to succeed with agile methods sharing real-life stories and practical tips. Find out more at www.jax-london.com.

I hope that reading this edition will be benefi cial and enjo-yable. May the agile force be with you.Roman Pichler

Karl Scotland Rachel Davies Roman Pichler Steve Freeman

Index:People and Process 3Two Sides of the Same Coin

Agile Coaching 6Understanding The Role

Demystifying the Product Owner 9The Role in Scrum

Bad Code isn’t Technical Debt … 11… it’s an unhedged Call Option

People and Process


von Karl Scotland

People and process are two sides of the same coin, both equally important in understanding how to improve capabili-ty to deliver valuable software.

PeopleThis side of the coin is about taking a group of people, who form a team in order to develop a capability. Peter Senge wro-te in ‘The Fifth Discipline’ that “the fundamental learning units in an organisation are working teams (people who need one another to produce an outcome)”. Creating teams in this way allows people to iteratively learn about the way that they work so that they can incrementally develop their capability in order to improve the outcomes that they produce.

This is the basis of all the popular Agile methods such as Scrum or Extreme Programming, which all recommend crea-ting cross-functional and co-located teams, collaborating with high bandwidth communication. Thus, the people side suggests that forming outcome-focussed teams, rather than activity-focussed siloes, will result in an improvement.

ProcessThis side of the coin is about taking a vision, which is deve-loped into a product in order to deliver value. Mark Denne and Jane Cleland-Huang wrote in their book ‘Software by Numbers’ about “an ROI-informed approach to software de-velopment in which software is developed and delivered in ca-refully prioritized chunks of customer valued functionality”.

People and Process are equally important

Two Sides of the Same Coin

One of the most valued statements from the Agile Manifesto is “individuals and interactions over processes and tools”. This is often abbreviated to “people over process” with a common interpretation being that the human aspects of software development are the primary areas we should be focussing on for improvement. However, this is counter to the ideas of W. Edwards Deming, who said “a bad process will beat a good person every time”. Similarly, Don Reinertsen has said he prefers “people times process” because if either is zero, then the product is zero.

People and Process


Figure 1: People

Figure 2: Process

Figure 3: People and Process

Taking this approach means that a product will maximise its value through being iteratively refi ned piece by piece in order to incrementally deliver functionality.

This is the basis of Lean approaches such as Kanban, which focuses on creating an explicit understanding of the process in order to learn how to deliver valuable pieces of software more effectively by modelling and visualising the work and associ-ated policies. Concepts such as Minimal Marketable Features and User Stories help break down the work into smaller pie-ces. Thus, the process side suggests that continuously delive-ring small pieces of functionality with minimal delays, rather than waiting to release large batches of features, will result in an improvement.

People and ProcessIt is when we put these two sides together that we can achieve signifi cant improvement. The iterative loops of learning about both the team and the product link into each other, enabling product value to rapidly fl ow through capability teams. This is the development nirvana we are trying to reach.

This model also gives some insight into why the “Water-fall” model, described by Winston Royce in his 1970 paper ‘Managing the Development of Large Software Systems’, has proved to be unsuccessful. It is not because the simple work-fl ow described was inherently wrong, but because the work-fl ow has typically been implemented with specialist siloes rather than capability teams, and with large rather than small batches. It is both sides of the coin that should be the focus of learning and improvement in order to help us on our journey to the nirvana of product development fl ow.

Karl Scotland is a versatile software practitioner with over 15 years of experience covering development, project management, team leadership, coaching and training. For the last 10 years he has been successfully applying Agile methods, and most recently has been a pioneer and ad-vocate of using Kanban Systems for software development. Currently an

Agile Coach with Rally Software in the UK, Karl is a founding member of the Lean Software and Systems Consortium and the Limited WIP Society, and has previously championed Agile and Lean Thinking with the BBC, Yahoo! and EMC Consulting. Karl writes about his latest ideas on his blog at http://availagility.co.uk/

PublisherSoftware & Support Media GmbH

Editorial Offi ce AddressGeleitsstraße 1460599 Frankfurt am MainGermanywww.jaxenter.com

Editor in Chief: Sebastian Meyen

Editors: Jessica Thornsby, Claudia Fröhling

Authors: Rachel Davies, Steve Freeman, Roman Pichler, Karl Scotland

Copy Editor: Nicole Bechtel

Creative Director: Jens Mainz

Layout: Patricia Schwesinger

Sales Clerk:Mark Hazell+44 (0)20 7401 [email protected]

Entire contents copyright ©2010 Software & Support Media GmbH. All rights reserved. No part of this publication may be reproduced, redistributed, posted online, or reused by any means in any form, including print, electronic, photocopy, internal network, Web or any other method, without prior written permission of Software & Support Media GmbH

The views expressed are solely those of the authors and do not refl ect the views or po-sition of their fi rm, any of their clients, or Publisher. Regarding the information, Publisher disclaims all warranties as to the accuracy, completeness, or adequacy of any informa-tion, and is not responsible for any errors, omissions, in adequacies, misuse, or the con-sequences of using any information provided by Pub lisher. Rights of disposal of rewarded articles belong to Publisher. All mentioned trademarks and service marks are copyrighted by their respective owners.

Imprint

www.jaxlondon.com

Mark your Calendar!All about the Java Ecosystem!

Java, Enterprise, Web & Agile

Register by 14th January

and save £100!

11th – 13th April 2010Park Plaza Victoria


Coaching

by Rachel Davies, Agile Experience Ltd.

I’ve worked as an agile coach for seven years now and still find that the role is not widely understood in the software industry. I hooked up with Liz Sedley to get more information out there about the role, the result is the first book on "Agile Coaching" [1]. Let's explore here what an agile coach does and why this role is so crucial to succeeding with Agile.

Becoming an agile coachOnce upon a time, I was a software developer immersed in my own little world of software architecture and design. I was often oblivious to what my colleagues were working on

Understanding The Role

Agile Coach When I tell someone who hasn’t heard about agile software development that I work as an Agile Coach, they often assume that I work in physical fitness industry. Sadly, an agile coach is not going to help you get a wash-board stomach! We work with software development teams to help them improve their performance and get the benefits of applying agile principles to their work.

until we attempted to integrate our work, and then entered a world of pain. How could we work more effectively to avoid interminable periods of rework?

Luckily, I came across Extreme Programming (XP) in 2000. When you first hear about the practices of XP it sounds crazy; developers write tests before coding, they program in pairs, plan using index cards, and integrate software continuously. I joined an XP team to find out if this could really work. I was delighted to find that delivering software iteratively and wor-king in closer collaboration makes the work more enjoyable as we learn together.

XP includes the role of Coach who, according to Kent Beck [5], “watches the process as a whole and calls the


Coaching

team’s attention to impending problems or opportunities for improvement.” After three years working as a developer on an XP team, I chose to branch out and fi nd work as an independent XP Coach. I was able to help teams get star-ted with XP practices by drawing on my experience of im-plementing practices such as test-driven development and planning with user stories. Nowadays, I’ve broadened out and help teams use techniques from a wider set of Agile me-thods than XP. I won’t dwell on the pros and cons of Agile methodology here.

However, I have learned that being a coach requires more than experience with agile practice. A coach helps a team im-plement changes and work more collaboratively, which can be a slow process because most people don’t like to change how they work. For this a coach must understand how to infl uence people and manage organisational change.

Contrasting agile coaching with existing rolesIn a nutshell, an agile coach helps teams grow strong in ap-plying Agile [2] practice to their work. It takes time to adopt these changes so you can’t do this effectively as a "seagull con-sultant" or trainer who swoops in to deliver words of wisdom and then makes a sharp exit. You need to spend time with a team to help them to become more aware of their workfl ow and how to collaborate effectively.

How is being a coach different from a team lead or project manager job role? Well, it’s not incompatible. The difference is that these roles have a wider set of project and company specifi c responsibilities, such as reporting progress, perfor-mance appraisals, etc. I notice that the pressure to deliver can distract from a focus on process improvement. Whereas, if you work solely as an agile coach, you can make this your sole focus because you don't have responsibility for project deliverables and administriva.

Being a coach is also different because it’s transitory role not tied into project duration. Your goal is for the team to be-come self-coaching and adept in applying agile then you move on. That doesn’t limit agile coaches to introducing agile into organizations and establishing new agile teams. The majority of the teams that I coach are already applying agile techniques and seek coaching because they want to boost their perfor-mance and profi ciency in agile software development.

Drawing from other coaching fi eldsYou can see why people get confused about what agile coa-ching is because the term coaching is used more widely in non-software contexts. For instance, you may associate coa-ching with sports and also self-help techniques. Let's take a closer look at how these overlap with agile coaching.

Business and life coaches usually work with individuals on a one-to-one basis. They help their “coachees” uncover personal goals and work out how to achieve them. As an agile coach, your primary focus is team performance towards company goals rather than the personal growth of individual team members. Of course, you’ll fi nd that you often have to work with individuals to improve teamwork. So you can draw on techniques from life-coaching to help people gain perspective on their work and open their eyes to new possibilities. However, I'd say that life-coaching skills are not suffi cient. An agile coach has to bring a broader set of skills to a software development team than simply clarifying goals and working out required actions to achieve them.

Sports coaches share the same focus of building a team that performs effectively. They require a deep knowledge of their sport and are often former players. They work on skills, tactics, and motivation. An agile coach wants to help teams with the same things — although techniques for building up physical sports skills don't really transfer into the world of software development. Instead, you can encourage developers on your team to improve as craftsmen and practice their code kata through coaching dojos [3]. So we see an agile coach can draw from both these coaching fi elds.

Understanding core skillsThe core skills for coaching agile teams are solid communication skills, such as listening, asking questions and giving feedback. To engage with the whole team, you must go beyond one-to-one conversations and enable effective team conversations. So mee-ting design and facilitation are also core skills for agile coaches.

This year I've run workshops with coaches at Agile and XP conferences to introduce Richard Hackman's model for coaching interventions [4]. He defi nes a coaching interventi-on as “any action that seeks to minimize process losses or to foster process gains.” He goes on to identify three categories of coaching intervention:

Educational• interventions improve understanding and skills on the team.Consultative• interventions foster process improvement by helping the team become more aware of their (mindless) habits.Motivational• interventions improve effort by building shared commitment and minimizing free-riding.

More Infos

More Infos on Agile Coaching can be found in Rachel’s book “Agile Couching” (by Rachel Davies and Liz Sedley ISBN: 978-1934356432)and Liz Sedley ISBN: 978-1934356432)

SUMMARY POINTS

Rachel Davies, co-author of fi rst book on "Agile Coaching", ■explains the role an agile coach plays.Examine how the role of agile coach compares with other roles, ■such as trainer, consultant, and manager.Appreciate how agile coaching compares to coaching in other ■domains like sports and life-coaching.Learn about the Hackman model of coaching interventions. ■Discover how agile software design skills apply to agile coaching. ■Understand the core skills that will help you become an effective ■agile coach.


Coaching

The big eye-opener for most agile coaches, who took part in these workshops, is that they usually focus on educating teams in agile practices and how to improve their agile pro-cess but they neglect motivation. Notice where team mem-bers are coasting along and not pulling their weight, now explore why. Think about ways that you can re-engage each team member. You can make a start by bringing them to-gether to establish shared goals that they believe are achie-vable and open up team discussion of what’s in it for them.

Where software design experience helpsYou might be surprised to learn that many of the skills that we acquire as a software developers also come in handy as coaches. Much of our work is to help teams “debug” their agile process by making them more visible and inspecting what’s revealed. We follow the work through the team from concept to delivery and help the team to become more aware of inputs and outputs along the way. We prompt them to get their brains in gear and find ways they can adapt their proces-ses to raise and handle exceptions smoothly.

Object-oriented thinking also helps us see opportunities for refactoring team process. Our team needs to get the coupling and cohesion of the work right to improve the flow of soft-ware deliveries through the team. Many activities in the Agile lifecycle can be decoupled. For example, a planning meeting can be broken into different sections that are run as separa-te meetings; doing this helps keeps the meetings shorter and more focussed.

We can also apply the Once-And-Only-Once principle to remove duplication of information which when spread around a plethora of tools (such as wikis, defect tracker, in-dex cards, spreadsheets) can be a source of confusion and lead to important aspects of requirements being missed. When you make the right information easy to find then decisions can be made swiftly by the team.

Bringing it all togetherWhen you're engaged as an agile coach, don't be surprised if your clients have some strange ideas about what an agi-

le coach does. They may expect all coaching to happen in a series of meetings far away from the team. You’ll need to educate them about the role and explain that spending time with the team while they’re at work is an essential part of coaching.

Before you get started, hone your communications skills for one-to-one conversations and team meetings. Draw from the fields of life-coaching and sports coaching for ways to unleash intrinsic motivation. Now you can apply your existing expe-rience in software development, to lead teams to debug and refactor their agile process.

If all that seems like a tall-order, start simple. Engage your current team by making their process more visible and then reflect with them on what’s revealed.

References

[1] "Agile Coaching" by Rachel Davies and Liz Sedley ISBN: 978-1934356432

[2] Agile Manifesto: http://www.agilemanifesto.org/principles.html

[3] "Leading Teams: Setting the Stage for Great Performances" by J. Richard Hackman ISBN: 978-1578513338

[4] Coding Dojo: http://www.codingdojo.org

[5] “Extreme Programming Explained” by Kent Beck ISBN: 978-0201616415

[6] <iframe src="http://player.vimeo.com/video/14500114?byline=0&portrait=0&color=A8CC45" width="400" height="300" frameborder="0"></iframe><p><a href="http://vimeo.com/14500114">Rachel Davies - Coaching Agile Teams</a> from <a href="http://vimeo.com/user3233384">Maria Diaconu</a> on <a href="http://vimeo.com">Vimeo</a>.</p>

[7] <a href="http://vimeo.com/14500114" target="_blank">Coaching Agile Teams</a> video of talk at Open Agile Romania<br/>

Rachel Davies works in the UK as an independent agile coach helping teams adopt and improve their agile delivery capability. Her new book "Agile Coaching" shares many practical tips that can help you take your teams to the next level. Rachel has supported the agile community as a former chair of the Agile Alliance and as an organizer of many Agile con-

ferences. This year she is the general chair for XP2011 conference in Madrid. Find out more information from her website at http://www.agilexp.com and follow her blog at http://agilecoach.typepad.com/

Scrum


By Roman Pichler, romanpichler.com

In a nutshell, the product owner is responsible for the success of the product. This usually requires the product owner to lead product discovery, to help identify and describe require-ments, and to ensure that the product backlog is ready for the next sprint planning meeting. It also means that the product owner has to engage in product planning, visioning and pro-duct road mapping, decide what functionality is provided by a release, carry out release planning, and answer questions from the team, review work results, and collaborate with cus-tomers, users and other stakeholders.

“The Product Owner’s focus is on return on investment (ROI),” writes Ken Schwaber in his book Agile Project Ma-nagement with Scrum (2004, 18). If we follow this advice, then product owners will have to look after products over an extended period of time – at least until the ROI can be determined – if not after the product’s entire lifecycle. Having one person in charge from bringing a new product to life, to discontinuing the product has many benefits; it creates conti-nuity and eliminates wasteful handoffs, delays and defects.

Many FacetsThe different responsibilities make the product owner a chal-lenging and multi-faceted role that shares some of the res-ponsibilities traditionally attributed to a product marketer,

product manager and project manager. But make no mistake: As tempting as it may be to compare the product owner to traditional roles, it’s fundamentally flawed. The product ow-ner is a genuinely new role that cuts across existing job and department boundaries.

The specific shape of the role is context-sensitive: It depends on the nature of the product, the stage of the product lifecycle, and the size of the project, among other factors. For example, the product owner responsible for a new product consisting of software, hardware, and mechanics will need different competencies than someone who is leading the effort to en-hance a web application. Similarly, a product owner working with a large Scrum project will require different skills than one collaborating with only one or two teams.

CollaborationBeing the product owner is no solo act. As a member of the Scrum team, the product owner closely works with the ScrumMaster and the team. But the individual also collabora-tes with the customers, users and other stakeholders thereby bridging the gap between the market and development.

The product owner needs the support from the other Scrum team members, for instance, to discover, describe, prioritise and detail product backlog items. Otherwise, the individual will end up being overworked, and the knowledge, creativity, and experience of the ScrumMaster and the team are wasted.

The Role of product owners in Scrum

Demystifying the Product Owner

This article discusses the role of the product owner in Scrum. The role has attracted plenty of interest and con-troversy. Some people believe it rebrands the traditional product manager. Others think it is a team lead role or Scrum’s take on the project manager. None of theses views are completely true, but there is some truth in them.

Scrum


Finding the Right IndividualFor commercial products, the product owner is typically a customer representative, such as a product manager or mar-keter. An actual customer tends to assume the role when the product is being developed for a specifi c organisation, for in-stance, an external client who requires a new data warehouse solution or an internal client like the marketing department asking for a web site update. I have worked with customers, users, business line managers, product managers, project ma-nagers, business analysts, and architects who fi lled the pro-duct owner role well in the given circumstances. Even CEOs can make great product owners.

I often get asked what characteristics a product owner should exhibit. Even though the answer depends on the con-text, the successful product owners I have worked with share the attributes discussed below. As transitioning into the pro-duct owner role is a learning process for the individual and the organisation, playing the role effectively may require pa-tience and perseverance.

Visionary and DoerThe product owner is a visionary who can envision the fi nal product and communicate the vision. But the product owner is also a doer who sees the vision through to completion. This includes describing requirements, closely collaborating with the team, accepting or rejecting work results, and steering the pro-ject by tracking and forecasting its progress. As an entrepreneur, the product owner facilitates creativity; encourages innovation; and is comfortable with change, ambiguity, debate, confl ict, playfulness, experimentation, and informed risk taking.

Leader and Team PlayerAs the individual responsible for the product’s success, the product owner provides guidance and direction for every-one involved in the development effort and ensures that tough decisions are made. For instance, should the launch date be postponed or should less functionality be delivered? At the same time, the product owner must be a team play-er who relies on close collaboration with the other Scrum team members, yet has no formal authority over them. You can think of the product owner as primus inter pares, fi rst among peers, regarding the product.

Communicator and NegotiatorThe product owner must be an effective communicator and negotiator. The individual communicates with and aligns different parties, including customers, users, development and engineering, marketing, sales, service, operations, and

management. The product owner is the voice of the custo-mer, communicating customer needs and requirements con-necting “the suits” with “the techies.” Sometimes this means saying no and other times negotiating a compromise.

Empowered and CommittedThe product owner must have enough authority and the right level of management sponsorship to lead the development ef-fort and to align stakeholders. An empowered product owner is essential for leading the effort to create a great product. The product owner must have the proper decision-making autho-rity—from fi nding the right team members to deciding which functionality is delivered as part of the release. The individual must be someone who can be entrusted with a budget and at the same time has the ability to create a work environment that fosters creativity and innovation. Finally, the product owner must be committed to the development effort.

Available and Qualifi edThe product owner must be available and qualifi ed to do a great job. Being the product owner is usually a full-time job. It is important to give product owners enough time to sustai-nably carry out their responsibilities. If the individual is over-worked, the project’s progress suffers and the resulting product may be suboptimal. Being adequately qualifi ed usually requi-res an intimate understanding of the customer and the market, being passionate about the user experience, and the ability to communicate needs and describe requirements, to manage a budget, to guide a development project, and to be comfortable working with a cross-functional, self-organising team.

SummaryThe product owner is a fascinating and challenging role. It plays a key part in creating great products with Scrum, and it is the cornerstone of establishing Scrum in the enterprise. “Until recently, I viewed this relationship [between product management and development] as one of many changes in a Scrum adoption. I now view it as the most critical change, the lynchpin of the adoption. If this change is successful, the use of Scrum will persist and benefi ts will increase. If the change isn’t successful, the use of Scrum in your enterprise might well unravel,” writes Ken Schwaber in his book Scrum and the Enterprise (2007, 85). Given that the product owner is a genuinely new role, it is not surprising that playing it can be challenging. But it is well worth the effort.

Links & Literatur

[1] http://www.se-radio.net/2010/05/episode-161-agile-product-management-with-roman-pichler/

Roman Pichler helps companies create great products by providing con-sulting, coaching and training in agile product management and Scrum. Roman has ten years experience in helping companies embrace agile methods, and a long track record in teaching and coaching product ow-ners and product managers, business analysts, ScrumMasters, managers,

and teams. He is the author of several books on Scrum including “Agile Product Ma-nagement with Scrum,” the product owner's guide to developing successful products with Scrum. Product ownership and agile product management form a focal point of Roman's work.

More Infos

More Infors on Agile Product Management can be found in Roman's book "Agile Product Management with Scrum" (ISBN: 978-0321605788)

Software Culture


von Steve Freeman

I “write” a Call Option [2] when I sell someone the right, but not the obligation, to buy in the future an agreed quantity of something at a price that is fixed now. So, for a payment now, I agree to sell you 10,000 chocolate santas at 56 pence each, at any time up to 10th December. You’re prepared to pay the premium because you want to know that you’ll have santas in your stores at a price you can sell.

From my side, if the price of the santas stays low, I get to keep your payment and I’m ahead. But, I also run the risk of having to provide these santas when the price has rocketed to 72 pence. I can protect myself by making arrangements with another party to acquire them at 56 pence or less, or by actually having them in stock. Or, I can take a chance and just collect the premium. This is called an unhedged, or “Naked” [3], Call. In the financial world this is risky because it has un-limited downside, I have to supply the santas whatever they cost me to provide.

Call options are a better model than debt for cruddy code (without tests) because they capture the unpredictability of what we do. If I slap in an a feature without cleaning up then I get the benefit immediately, I collect the premium. If I ne-ver see that code again, then I’m ahead and, in retrospect, it would have been foolish to have spent time cleaning it up.

On the other hand, if a radical new feature comes in that I have to do, all those quick fixes suddenly become very expensive to work with. Examples I’ve seen are a big new client that requires a port to a different platform, or a new regulatory requirement that needs a new report. I get equi-valent problems if there’s a failure I have to interpret and fix just before a deadline, or the team members turn over completely and no-one remembers the tacit knowledge that helps the code make sense. The market has moved away from where I thought it was going to be and my option has been called.

Even if it is more expensive to do things cleanly (and I’m not convinced of that beyond a two-week horizon), it’s also less risky. A messy system is full of unhedged calls, each of which can cost an unpredictable amount should they ever be exercised. We’ve all seen what this can do in the financial markets, and the scary thing is that failure, if it comes, can be sudden—everything is fine until it isn’t. I’ve seen a few systems which are just too hard to change to keep up with the competition and the owners are in real trouble.

So that makes refactoring like buying an option too. I pay a premium now so that I have more choices about where I might take the code later. This is a mundane and obvious activity in many aspects of business—although not, it seems, software development. I don’t need to spend this money if I know exactly what will happen, if I have perfect knowledge of the relevant parts of the future, but I don’t recall when I last saw this happen.

So, the next time you have to deal with implausible delivery dates, don’t talk about Technical Debt. Debt is predictable and can be managed, it’s just another tool. Try talking about an Un-hedged Call. Now all we need is a way to price Code Smells [4].

Changing metaphors

Bad code isn’t Technical Debt ...... it's an unhedged Call Option. This is all Chris Matts‘ idea [1]. He realised that the problem with the “Technical Debt” metaphor is that for managers debt can be a good thing. Executives can be required to take on more debt because it makes the finances work better, it might even be encouraged by tax breaks. This is not the same debt as your personal credit card. Chris came up with a better metaphor, the Call Option.

Links

[1] http://abc.truemesh.com/

[2] http://en.wikipedia.org/wiki/Call_option

[3] http://en.wikipedia.org/wiki/Naked_call

[4] This text was originally published here: http://www.m3p.co.uk/blog/2010/07/23/bad-code-isnt-technical-debt-its-an-unhedged-call-option/

Steve Freeman is an independent consultant specializing in Agile soft-ware development. A founder member of the London Extreme Tuesday Club, he was chair of the first XPDay and is a frequent organizer and pre-senter at international conferences. Steve has worked in a variety of or-ganizations, from writing shrink-wrap software for IBM, to prototyping for

major research laboratories. Steve has a Ph.D. from Cambridge University, and de-grees in statistics and music. Steve is based in London, UK.

Documents

GROOVY