The Agile Executive

Making Agile Work

Archive for the ‘Business Service Management’ Category

Extending a True Epiphany

with 2 comments

In Agile Software Development with Scrum, Ken Schwaber describes a true epiphany he experienced as a result of his 1995 meetings with DuPont’s process control experts:

They [DuPont's process control experts] inspected the system development processes that I brought them. I have rarely provided a group with so much laughter. They were amazed and appalled that my industry, system development, was trying to do its work using a completely inappropriate process control model. They said system development had so much complexity and unpredictability that it had to be managed by a process control model they referred to as “empirical.” They said it was nothing new, and all complex processes that were not completely understood required the empirical model…

… I realized why everyone in my industry had such problems building systems. I realized why the industry was in such trouble and had such poor reputation. We were wasting our time trying to control our work by thinking we had an assembly line when the only proper control was frequent and first-hand inspection, followed by immediate adjustments…

Based on this insight, I have since formulated with others the Scrum process for developing complex products, particularly software systems.

Fast forward to November 2009. During a lovely dinner in Boulder with Dean Leffingwell, we got into the subject of connecting Agile with ITIL. This conversation really registered with me. I actually recalled how years ago Ray Paquet characterized IT as a “continuous manufacturing” process. If you accept Ray’s premise, the chain {DuPont –> Scrum –> IT} is quite intriguing.

Re-reading Software Evolution recently, I was struck by the observation Tom Mens makes in the Introduction:

… due to the fact that the activity of software evolution is a continuous feedback process, the chosen process model itself is likely to be subject to evolution.

I can’t help wondering whether Tom’s observation applies to IT. If so, what are the implications with respect to IT operations and system management?!

Opinions please!

Predicting the Year Ahead

leave a comment »

Cutter Consortium has published predictions for 2010 by about a dozen of its experts. My own prediction, which examines the crash of 1929, the burst of the “dot-com bubble” in 2000 and the financial collapse in 2008, is actually quite bullish:

I expect 2010 to be the first year of a prolonged golden age. Serious as the various problems we all are wrestling with after the 2008-2009 macro-economic crisis are, they should be viewed as systemic to the way a new generation of revolutionary infrastructure gets assimilated in economy and society.

In addition to the techno-economic view expressed in the Cutter prediction, here are my Agile themes for 2010:

  • Agile moves “downstream” into Release Management.
  • Agile breaks out of Development into IT (and beyond) in the form of Agile Infrastructure and Agile Business Service Management.
  • SOA and Agile start to be linked in enterprise architecture and software/hardware/SaaS organizations.
  • Kanban starts an early adoption cycle similar to Scrum in 2006.

Acknowledgements: I am thankful to my colleagues Walter Bodwell, Sebastian HassingerErik Huddleston, Michael Cote and Annie Shum who influenced my thinking during 2009 and contributed either directly and indirectly to the themes listed above.

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.

    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.

    “How do we move towards an agile procurement or agile development methodology?”

    leave a comment »

    Colleague and friend Annie Shum sent me the following excerpt from  U.S. CIO Vivek Kundra’s Friday keynote talk at the University of Maryland’s CIO Forum:

    Questioned on whether service-oriented architecture still is an emphasis in a federal cloud computing paradigm, Kundra said SOA “absolutely” still matters. “Look at the Social Security Administration and what it’s done with SOA and local government,” he said. “They can build lightweight applications to interact with databases elsewhere.” That embrace of modern development practices extends beyond just SOA or upgrading programmers’ skills from COBOL. “How do we move towards an agile procurement or agile development methodology?” asked Kundra [highlighted by IG].

    The {SOA –> agile procurement –> agile development} connection is intriguing. Obviously, Kundra gets the nature of the next revolution in productivity. My hunch would be that Business Service Management, particularly in its Agile BSM flavor, would soon be added to the mix.

    Software Moulding Methods

    with 3 comments

    Christian Sarkar and I started an e-dialog on Agile Business Service Management in BSMReview. Both of us are keenly interested in exploring the broad application of Agile BSM in the context of Gartner’s Top Ten Technologies for 2010. To quote Christian:

    Israel, where do agile practices fit into this? Just about everywhere as well?

    The short answer to Christian’s good question is as follows:

    I consider the principles articulated in the Manifesto For Agile Software Development  http://agilemanifesto.org universal and timeless. They certainly apply just about everywhere. As a matter of fact, we are seeing the Manifesto principles applied more and more to the development of hardware and content.

    The fascinating thing in what we are witnessing (see, for example: Scale in London  – Part IIAn Omen in ChicagoDepth in Seattle, and Richness and Vibrancy in Boston) is the evolution of the classical problem of managing multiple Software Development Life Cycles. Instead of dealing with one ‘material’ (software), we handle multiple ‘materials’ (software, hardware, content, business initiative, etc.) of dissimilar characteristics. The net effect is as follows:

    The challenge then becomes the simultaneous and synchronized management of two or more ‘substances’ (e.g. software and content; software, content and business initiative; or, software, hardware, content and business initiative) of different characteristics under a unified process. It is conceptually fairly similar to the techniques used in engineering composite materials.

    Ten years have passed since Evans and Wurster demonstrated the effects of separating the virtual from the physical. As software becomes pervasive, we are now starting to explore putting the virtual back together with the physical through a new generation of software moulding methods.

    Follow

    Get every new post delivered to your Inbox.

    Join 38 other followers