Archive for the ‘Q&A’ Category
How are “uncertainty” and “correctness” related?
Doesn’t uncertainty mean my definition of correct may change? Could I have totally correct direction, but still have uncertainty?
John is referring to the way I try to pinpoint the exact “pain” Agile is expected to address by an executive considering an Agile implementation. Specifically:
Agile is all about effectively addressing uncertainty, I say. I stress that Agile does not address complexity per se. It might indirectly help with complexity if it leads you towards deeper thinking about Complex Adaptive Systems. For example, you might consider evolving the product architecture in the course of your Agile project instead of pre-defining it. However, Agile is not a “medicine” for complexity pains.
Nor is Agile about correctness. A hyper-productive Agile team could actually go fast nowhere implementing a poorly conceived product. The “real time” feedback loops of the project team might help uncover that a product is mis-conceived. However, independent of the team feedback, you still need to determine what correctness means to you and how you would assess it as the product evolves.
The answer to John’s good question is that correctness is a matter of the level of abstraction as defined in Hardware Engineering: A DEC View of Hardware Systems Design. Suppose you are coding a service enabling passengers to check in for flights. At the functional level, the correctness of the coded service is fairly unambiguous and (hopefully) will be established through testing. The check in service might be correct functionally, but still subject to change. For example, an airline could aspire to enable its passengers to check in through any mobile device whose volume of sales exceeded one million units. Such an aspiration will necessitate fairly frequent changes to support new mobile devices as they cross a threshold of popularity.
So, yes: one could have a totally correct direction, but still have uncertainty.
One of the “services” we want to offer is a classic write-in question section here at The Agile Executive. Inevitably, with something like Agile, there are many questions, esp. from those who are transitioning to it or looking to apply it to new environments.
With the Q&A service, we’d love to have you, dear readers, write in your questions and concerns. We’ll take a whack at addressing them, pulling in other experts as warranted as well.
As an example, I recently had a fun, multi-modal (from a lunch of mole enchiladas to email) conversation about the role of code review in Agile Development.
How does it work?
All you need to do is email in your agile related questions to email@example.com and Israel and I will answer select questions here.
Colleague Clarke Ching asked me about the language I use in interacting with executives on Agile topics. To quote Clarke:
Obviously the language one uses with a developer is quite different from the language one uses with a program manager. Likewise, the language you [Israel] use in discussing Agile with executives must be quite different. What language do you use? In particular, what language do you use amidst the current economic crisis?
What language do you use amidst the current economic crisis?
I view the economic crisis as part of life. Having grown up in Israel, I still clearly remember:
- The 1956, 1967 and 1973 wars;
- Various economic crises;
- Any number of measures taken by the government to cope with financial crises. For example, devaluing the currency on many occasions.
We all survived and the country moved forward in leaps and bounds. We simply learned to accept dramatic changes as inevitable, to continue doing what we believed in. We, of course, changed tactical plans in response to disruptions such as a change in the value of the currency, but continued to do the right things strategically. Such turbulence, and possibly worse, has been characteristic of much of the world for many years now. Just think of Eastern Europe, Latin America or Africa.
Fast forwarding to 2009: I try to put the economic crisis in perspective. I have discussed the techno-economic cycle along the lines articulated by author Carlota Perez in her book Technological Revolutions and Financial Capital: The Dynamics of Bubbles and olden Ages. In my recent post Why Agile Matters, I stated:
- The fifth techno-economic cycle started in 1971 with the introduction of the Microprocessor;
- This cycle has been characterized by software going hand-in-hand with miniaturized hardware. We are witnessing pervasive software on unprecedented scale;
- Furthermore, software is becoming a bigger piece in the contents of just about any product. For example, there are about 1 million lines of code in a vanilla cell phone;
- Agile software significantly reduces the cost of not “only” software, but the cost of any product containing software;
- And, Agile software enables us to respond faster and more flexibly to changes – in the software, in the business process that is codified by the software, in the product in which the software is embedded.
In short, I speak about software as an important factor in the bigger scheme of things – the techno-economic cycle.
What language do you use in your conversation with executives?
I describe the benefits of Agile in the business context. For example, when I meet an executive of a major financial institution, I discuss with him/her issues of compliance and risk his company is facing. For a global financial institution I typically discuss the critical needs during transfer of trade from London to Wall Street. A lot of things need to work seamlessly in order to ensure smooth transition. If things do not work well within the short transition window, the implications are dire:
- Unacceptable risks. Billions of $$ could be lost if a global financial company cannot start trading on time in Wall Street;
- Severe compliance issues. The executive with whom I speak and his/her company could get in serious regulatory trouble due to a failure to reconcile trades and keep the required audit trail.
The ties of these business imperatives to Agile are straightforward:
- Higher quality code reduces the risk of a ‘glitch’ in the transition of trade from London to Wall Street;
- Should a financial institution suspect a glitch might happen, Agile usually enables Application Development and Operations to fix the code faster than traditional methods;
- And, using virtual appliance technology enables deploying the fix in minutes instead of months.
I usually cite the examples of Flickr and IMVU to demonstrate how fast one can deploy software nowadays. I make it crystal clear that I do not expect a global financial institution today to be able to deploy every thirty minutes or every nine minutes as Flickr and IMVU do. However, I stress that the software industry is clearly heading toward a much shorter cycle between concept or problem identification and deployment. I point out that he/she has an opportunity to be ahead of the power curve, to gain competitive advantage in the market through superior velocity in both development and deployment. Obviously, a faster introduction of a new hedging algorithm could make a big difference for a financial institution.
What do I typically hear from the executive in such a conversation?
The responses I usually get tend to reflect the alignment (or lack thereof) between the financial strategy and the operational strategy a company follows:
- The “cut costs by cutting costs” variety: the discussion revolves around the need to continue to carry out layoffs on a quarterly basis. In this case I stress the life cycle costs of software, asking the executive I am speaking with to answer a tough question: Can you afford the software you are developing? This question often leads the executive to reexamine the balance between the two strategies (financial versus operational).
- The “cut costs by systemically improving the underlying system” variety. The conversation with executives of this mindset usually converge quickly on what is most important to the business: time-to-market, quality or productivity. It is a small step from here to getting into the “hows” of Agile roll-out.
A reader of The Agile Executive brought up some questions about product retirement in the context of project teams that use Agile methods. For example: Should a product backed by a hyper-productive Agile project team be retired at the same point that an aging Waterfall product typically would?
The question is important. Customers can get very upset over the retirement of a product, particularly a mission-critical product. Even if the vendor offers a new product that replaces the one to be retired, the operational disruption associated with migrating to the new product is often troublesome. On the other hand, the cost of maintaining software, let alone keeping it current, could be and is often high for the enterprise software vendor.
The answer to the product retirement question ties Agile methods and practices to the fabric and economics of software engineering. A good way to address the subject is to ask the following two questions:
- Can you afford the software you are developing now?
- Would you be able to continue to adequately invest in the software as it evolves down the road?
Rules of Thumb for Affordability
Affordability is, of course, in the eyes of the beholder. Your CFO might see it in quite differently than your CMO. To bring a discussion between the two, or any other forum of CXOs, to a common denominator, you need to get a handle on two numbers:
- Development cost (including product management and test costs) per story card
- Development cost as a percentage of product life-cycle cost
Development costs and life-cycle costs vary greatly from one company to another as well as within your company. For example:
- Off-shore costs can be quite different from on-shore costs
- The costs of maintaining high quality code are drastically different from those for average quality code. (See Estimating Software Costs by Capers Jones for a detailed analysis of the subject).
- Productivity of an Agile team can easily eclipse that of a Waterfall team.
Laborious and time consuming that collecting good cost data across development methods, projects, sites and continents might be, you are essentially flying blindly with respect to affordability unless you have very specific cost data.
Until you gather this data, here are two rules of thumb that can be used to get a rough sense of affordability:
- A typical figure for development and test cost per story card for enterprise software project teams is thousands and thousands of dollars. It can exceed $10,000. This (order of magnitude) figure is for a contemporary software development and test organization in the US that is “reasonably” balanced between on-shore and off-shore development
- Development cost is typically less than 50% of the total software life-cycle costs. Again, the assumption of reasonable balance between on-shore and off-shore applies
These rules of thumb should be used prudently. For example, Mens and Demeyer report cases in which software development costs constituted a mere 10% of the total life-cycle cost.
What is your Software Evolution Strategy?
In Program Evolution: Processes of Software Change, authors Lehman and Belady summarized years of research on the subject they and various collaborators carried out. Their bottom line is deceptively simple: software is live and always evolving. Furthermore, software decays.
Jim Highsmith uses the following great graph to demonstrate the effect of accrued technical debt on cost of change and responsiveness to customers:
Jim points out that no good option exists once the software has decayed to the point of excessive technical debt. Furthermore, once you are in the far right of curve estimation is next to impossible and afforability calculations become pretty useless. You might think about technical debt like debt on a credit card – you become a slave to servicing the debt instead of paying off the principal.
Between the initial development cost and the cost of evolving and maintaining decaying software, many software development projects find themselves in dire need of higher productivity. Hence, a more precise statement of affordability is as follows:
- Can you afford the software you are developing given your productivity during and after development of the first release?
The productivity results reported for companies successfully using Agile methods such as BMC Software, SirsiDynix and Xebia indicate productivity gains of at least 2X, and often higher, compared to industry average. Everything else being equal you would be able to retire a product backed by a good Agile team later than a product backed by a Waterfall team.
Many Agile teams tend to be inclined to refactor the code on an on-going basis. For example, Salesforce devotes about 20% of development resources to refactoring. As a result, software decay is slower for such teams. They reach the point of no good options in Jim Highsmith’s graph later than teams who do not refactor the code day in and day out.
Refactoring is like flossing your teeth regularly. The dental tape disconnects your bank account from the dentist’s…