The Agile Executive

Making Agile Work

Archive for November 2009

Prior to Sprint Zero: A Note on Jakob Nielsen’s “Agile User Experience Projects”

leave a comment »

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

    leave a comment »

    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.

    Written by israelgat

    November 24, 2009 at 7:56 pm

    Posted in The Agile Life

    Tagged with , ,

    The Changing Nature of Innovation: Part II — National Policy

    with 4 comments

    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?!

    Written by israelgat

    November 24, 2009 at 5:30 am

    The Changing Nature of Innovation: Part I — New Forms of Experimentation

    with 4 comments

    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

    with 6 comments

    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:

    1. 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.

    2. 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.
    3. 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

    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.

    Predictability is Bad for Your Business

    with 2 comments

    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!

    Written by israelgat

    November 12, 2009 at 4:00 am