Archive for November 2009
Prior to Sprint Zero: A Note on Jakob Nielsen’s “Agile User Experience Projects”
Dr. Jakob Nielsen published the results of a follow-on study to his 2008 report Agile Development Methods and Usability. The bottom line from the 2009 study (entitled Agile User Experience Projects) is as follows:
The two main recommendations for ensuring good usability in Agile projects remain the same as in our original research:
Separate design and development, and have the user interface team progress one step ahead of the implementation team. That way, when it comes time to build something, it’s already been designed and tested. (And yes, you can do both in a week or two by using paper prototypes and discount user testing.) Maintain a coherent vision of the user interface architecture. Create the initial vision during a “sprint zero” period — before any implementation has started — and maintain it through annual (or semi-annual) design vision sprints. You can’t just design individual features; they have to fit together into a coherent whole — a whole that must be designed as well. Bottom-up user interface design equals a confused total user experience (the Linux syndrome).
I would like to highlight one implicit sub-aspect of Dr. Nielsen’s good counsel to maintain a coherent vision of the user interface architecture:
- Ensure coherence with the underlying application paradigm
To illustrate the point, think of a Business Service Management Application. You might monitor any number of servers, routers, databases and applications in order to ensure that a service satisfies the corresponding Service Level Agreement. However, the user interface architecture should have service as its fundamental concept. The architecture should certainly enable zooming in on any component of the service. But, the status of any such component (or sub-component) is merely means to an end: reflecting the status of the service and initiating as appropriate action(s) to fix it. Forming a service piecemeal from a number of constituent elements like those mentioned above – servers, routers, databases, applications, etc. – is no substitute to “service orientation” of the user interface.
The reason for my strong emphasis on the service as the most fundamental user interface concept is nicely captured in the article “How to Spell BSM” by BSM Review‘s Tom Bishop:
Most businesses today are so dependent on IT that, if an IT organization does not understand how the business depends on its services, or does not manage those services with that business perspective in mind, they are dooming the business to slow, steady death….
Dr. Nielsen’s recommendation to conceive the initial user interface architecture prior to beginning any implementation work is very consistent with this imperative need in BSM to manage the services from a business perspective. I would actually go one step further and contend that whenever the underlying paradigm changes in a manner as dramatic as the servers –> services in the BSM example above, demonstration of the core concept(s) of the user interface might need to precede the “sprint zero” period. In the context of the overall planning and budgeting process which governs the Agile process, such demonstration could actually be a pre-requisite to launching “sprint zero.”
If you consider this “prior to sprint zero” approach a bit heavy-handed, I would offer a simple test to assess its reasonableness. Play with a number of IT Service Management (ITSM) products that you picked in random. Once you did so, compare the numbers of those that clearly have services at their core, to the number of those that integrated services into their user interface as an afterthought.
What Sony Showed at Their Shareholders Meeting
Strictly speaking this video might not be considered an Agile topic. I would just say I had never seen as dramatic a demonstration of the importance of cadence as this artful “Did You Know?” video.
Many thanks to colleague Walter Bodwell for bringing this fascinating video to my attention.
The Changing Nature of Innovation: Part II — National Policy
Michael Porter makes two interesting observations about innovation in the US in his BusinessWeek interview entitled Why America Needs an Economic Strategy:
… U.S. entrepreneurship has been fed by a science, technology, and innovation machine that remains by far the best in the world. While other countries increase their spending on research and development, the U.S. remains uniquely good at coaxing innovation out of its research and translating those innovations into commercial products. In 2007, American inventors registered about 80,000 patents in the U.S. patent system, where virtually all important technologies developed in any nation are patented. That’s more than the rest of the world combined
In contrast to the effectiveness of utilizing research and technology for entrepreneurial purposes, Porter notes a worrisome trend:
An inadequate rate of reinvestment in science and technology is hampering America’s feeder system for entrepreneurship. Research and development as a share of GDP has actually declined, while it has risen in many other countries. Federal policymakers recognize this problem but have failed to act.
Viewed in light of Part I of this mini-series on innovation, a natural question posts itself:
Do the new forms of experimentation, which enable the US entrepreneurial system to be so very effective in coaxing innovation out of research that has already been done, mask a fundamental decline for which there will be hell to pay?!
The Changing Nature of Innovation: Part I — New Forms of Experimentation
Colleague Christian Sarkar drew my attention to two recent Harvard Business Review (HBR) articles that shed light on the way(s) innovation is being approached nowadays. To the best of my knowledge, none of the two articles has been written by an author who is associated with the Agile movement. Both, if you ask me, would have resonated big time with the authors of the Agile Manifesto.
The February 2009 HBR article How to Design Smart Business Experiments focuses on data-driven decisions as distinct from decisions taken based on “intuition”:
Every day, managers in your organization take steps to implement new ideas without having any real evidence to back them up. They fiddle with offerings, try out distribution approaches, and alter how work gets done, usually acting on little more than gut feel or seeming common sense—”I’ll bet this” or “I think that.” Even more disturbing, some wrap their decisions in the language of science, creating an illusion of evidence. Their so-called experiments aren’t worthy of the name, because they lack investigative rigor. It’s likely that the resulting guesses will be wrong and, worst of all, that very little will have been learned in the process.
It doesn’t have to be this way. Thanks to new, broadly available software and given some straightforward investments to build capabilities, managers can now base consequential decisions on scientifically valid experiments. Of course, the scientific method is not new, nor is its application in business. The R&D centers of firms ranging from biscuit bakers to drug makers have always relied on it, as have direct-mail marketers tracking response rates to different permutations of their pitches. To apply it outside such settings, however, has until recently been a major undertaking. Any foray into the randomized testing of management ideas—that is, the random assignment of subjects to test and control groups—meant employing or engaging a PhD in statistics or perhaps a “design of experiments” expert (sometimes seen in advanced TQM programs). Now, a quantitatively trained MBA can oversee the process, assisted by software that will help determine what kind of samples are necessary, which sites to use for testing and controls, and whether any changes resulting from experiments are statistically significant.
On the heels of this essay on how one could attain and utilize experimentally validated data, the October 2009 HBR article How GE is Disrupting Itself discusses what is already happening in the form of Reverse Innovation:
- The model that GE and other industrial manufacturers have followed for decades – developing high-end products at home and adapting them for other markets around the world – won’t suffice as growth slows in rich nations.
- To tap opportunities in emerging markets and pioneer value segments in wealthy countries, companies must learn reverse innovation: developing products in countries like China and India and then distributing them globally.
- While multinationals need both approaches, there are deep conflicts between the two. But those conflicts can be overcome.
- If GE doesn’t master reverse innovation, the emerging giants could destroy the company.
It does not really matter whether you are a “shoe string and prayer” start-up spending $500 on A/B testing through Web 2.0 technology or a Fortune 500 company investing $1B in the development and introduction of a new car in rural India in order to “pioneer value segments in wealthy countries.” Either way, your experimentation is affordable in the context of the end-result you have in mind.
Fast forward to Agile methods. The chunking of work to two-week segments makes experimentation affordable – you cancel an unsuccessful iteration as needed and move on to work on the next one. Furthermore, you can make the go/no-go decision with respect to an iteration based on statistically significant “real time” user response. This closed-loop operational nimbleness and affordability , in conjunction with a mindset that considers a “failure” of an iteration as a valuable lesson to learn from, facilitates experimentation. Innovation simply follows.
Your Investment in Enterprise Software – Guidelines to CIOs and CFOs
The overall investment associated with implementing and maintaining a suite of enterprise software products could be significant. A 1:4 ratio between product investment and the corresponding investment over time in related services is not uncommon. In other words, an initial $2M in licensing a suite of enterprise software products might easily balloon to $10M in total life-cycle costs (initial investment in perpetual license plus the ongoing investment in associated services).
I offer the following rule-of-a-thumb guidelines to assessing whether the terms quoted by a vendor for an enterprise software suite of products are right:
- Standard maintenance costs: Insist on a 1:1 ratio between license and standard maintenance over a 5 year period. If standard maintenance costs over this period exceed the corresponding license costs, chances are: A) the vendor is quite greedy; or, B) the vendor’s software accrued a non-negligible amount of technical debt. Ask the vendor to quantify the technical debt in monetary terms. See Technical Debt on Your Balance Sheet for an example how to conduct such quantification.
- Premium customer support costs: Certain premium customer support services could be quite appropriate for your business parameters. However, various “premium services” could actually address deficits or defects in the enterprise software products you license. If the technical debt figure is high, the vendor you are considering might not be able to afford the software he has developed. Under such circumstances, “premium services” could simply be a vehicle the vendor uses to recoup his investment in software development.
- Professional services costs: Something is wrong if the costs of professional services exceed licensing cost. Either the suite of products you are considering is not a good fit for your business parameters or the initiative you are aspiring to implement through the software is overly ambitious.
To summarize, the grand total of license fees, customer support fees and professional services fees over a 5 year period should not be higher than 3X license fees. Something is out of balance if you are staring at a 4X or 5X ratio for the software you are considering.
One final point: please do not forget to add End-of-Life costs to the economic calculus. Successful enterprise software initiatives can be very sticky.
An Update on Agile Business Service Management
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:
- The Joys of Real Hardware – what it means to do Business Service Management on a very large-scale
- The Voice of the CIO – a study on the attributes needed by today’s CIO (yes, you had better be agile and Agile…)
- The Quest for a Maturity Model in Business Service Management – while the focus is on BSM, some of the models might apply in a fairly straightforward manner to Agile
- Business Service Management, Six Sigma and your IT Compliance Program – lessons to the champion who has one foot in Agile, the other foot in Six Sigma
- A Measured Approach to Cloud Computing – what it really means to “… make muck so you don’t have to”
- The Case for Agile Business Service Management – the fusion of modern software development methods with the prevailing preference to run IT from the perspective of the business customer
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.
Predictability is Bad for Your Business
I had the pleasure of meeting some old colleagues a few weeks ago. They work for a software company that pays a lot of attention to software engineering practices and invests heavily in software tools. Financial results, however, have not been great over the past few years.
Obviously, the disparity between the strength of the software engineering discipline and the relative weakness of the financial results is due to more than a single cause. One factor, however, was highlighted time and time again by my colleagues:
Predictability is killing us!
Paradoxical that this observation might seem, it is actually quite straightforward. Senior management in their company is really forceful about predictability. Hence, initiative, (affordable) experimentation and innovation have pretty much faded away. For most practical purposes it has become a check-the-box culture. All attempts to substitute reliable delivery for predictability seem to have failed so far.
One last “ingredient” to add to the story. This company is rich in talent. Generally speaking, the folks in the engineering trenches are gifted, knowledgeable, capable and dedicated.
How predictably poignant!
Technical Debt: Refactoring vis-a-vis Starting Afresh
Only three options are available to you once your technical debt overwhelms the development and customer support teams:
- Continue as is.
- Start refactoring in earnest to pay back your debt.
- Switch to a new code base, either by launching an unencumbered development project or through acquiring new software from another company.
The first option, obviously, does not solve any problem – you simply continue a struggle that becomes more and more difficult over time. As indicated in the post Elbow Room for Handling Technical Debt, the second option is quite difficult to carry out if it is exercised at a late point in the software’s life cycle. This post examines the third option – starting afresh.
The attraction of starting afresh is always tempting. The sins of the past, hidden in layers over layers of technical debt and manifesting themselves in low customer satisfaction and poor customer retention, are (sort of) forgiven. The shiny new software holds the promise of better days to come.
Trouble is, your old sins are there to get you in three nasty ways:
- New technical debt: Even if the shiny new software is very good indeed, it will decay over time. Unless you transformed your software engineering practices to ensure refactoring is carried out on an ongoing basis, sooner or later you will accrue new technical debt.
- Migration: Good that the new software might be, it is not likely to provide all the functionality the old software had. Migrating your customers will require a lot of hard work, particularly if your customers developed elaborate business processes on top of your old software.
- Critical race between old and new: For a period of time (say a couple of years) the old software is likely to run alongside the new software. Any significant new regulatory requirement will force you to update both the old software and the new software. Ditto for security. Any nifty new technology you might want to embed in your new software is likely to be equally desirable to customers who still use your old software. You will be pressed to incorporate the new technology in the old software, not just in the new software.
Before opting for new software (in preference to refactoring the old software), I would recommend you compare the economics of the two option. My rule of a thumb for the calculus of introducing new enterprise software to replace legacy software is straightforward:
For a period of about two years, assume the run rate for dev/test/support will be 150% of your current investment in development, test and support of the old software.
Please note that the 150% figure is just the expected run rate for running the new software alongside the legacy software. You will need, of course, to add the cost of acquiring/producing the new software to the economic calculus.
You might be able to reduce the ‘150% for two years’ investment by applying some draconian migration measures. Such measures, of course, will affect your customers. In the final analysis, your decision to acquire new software must be viewed as the following simple question:
What value do you place on your customer base?!
Open Source Software and Agile Software Development: Parallels and Lessons for Enterprise IT
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).
The Agile Executive 