Posts Tagged ‘Business Value’
A Good Start Point for Devops – Guest Post by Peter McGarahan
Source: http://www.flickr.com/photos/stevepj2009/3461077400/
Many of the devops posts in this blog were written from a dev perspective. Today’s guest post by Peter McGarahan examines the topic from the ops perspective. It is inspired by the following eloquent quip about change:
Assume we’re starting from scratch. Assume that we actually are a startup that doesn’t have over a hundred years of experience and sub-optimized IT legacy.
A few biographical details for readers who might not know Peter or know of him. Peter J. McGarahan is the founder and president of McGarahan & Associates, an IT Service Management consulting and training organization. Peter offers 27 years of IT and Business Service Management experience in optimizing and aligning the service and support organizations of the Fortune 1000 to deliver value against business objectives. His thought leadership has influenced the maturity and image of the service and support industry. His passion for customer service led the Taco Bell support organization to achieve the Help Desk Institute Team Excellence Award in 1995. IT Support News named him one of the “Top 25 Professionals in the Service and Support Industry” in 1999. Support professionals voted McGarahan “The Legend of the Year” in 2002 and again in 2004 at the Service Desk Professionals conference for his endless energy, mentoring and leadership coaching. As a practitioner, product manager and support industry analyst and expert, McGarahan has left his service signature on the support industry / community.
Here is Peter:
As a former Director of Infrastructure & Operations (I&O), I found it beneficial to establish a respectful working relationship with my Development Colleagues. It was important for the accountable leaders to better understand the objectives, workings and success metrics of each team. It was also critical for the leader to establish the ‘rules of engagement’ for how each team would assist each other in achieving their stated objectives (success metrics). It certainly helped to have an IT / Business leader who established a cooperative / collaborative teamwork culture. She also supported it with shared IT / Business objectives and performance goals for all accountable IT leaders. The I&O team certainly benefited from a CIO who understood the importance of customer service, the value of support and the business impact (negative IT perception) caused by repetitive incidents, problems and service disruptions. It was a game changing day for I&O when the CIO announced that all accountable leaders would have half of their performance objectives (bonus compensation) based on the success metrics of the I&O team.
In working with Infrastructure & Operations organizations, it has become apparent that as we continue to implement, measure and continuously improve the IT Infrastructure Library v3 (ITIL) processes, we must simultaneously address how we focus on all things new! In a recent Cutter Executive Update entitled IT’s Change Imperative, I relate lessons learned from my conversations with Geir Ramleth, CIO of Bechtel and Ron Griffin, Senior VP of Applications for Hewlett-Packard. Their leadership, vision and courage inspired me to think differently about how IT can better work together for the benefit of the business. In the end, the only success that matters – is the continued growth and profitability of the business. A summary of their change success stories:
- Hewlett-Packard CIO Randy Mott hired the right people to implement his IT strategy and change plan that included building, consolidating and automating its data centers; transferred work in-house from contractors; standardized on only a quarter of its apps; and built one central data warehouse — all while cutting spending in half.
- Geir Ramleth, CIO of Bechtel described how he used cloud computing principles to transform IT and make Bechtel’s computing environment more agile. He had a vision of allowing Bechtal’s global employees access to the right resources at any place at any time with any device – delivered securely and cost-effectively. He encouraged his IT people to step outside their comfort zones and do things in a different way. He resisted modifying the current state and went with the transformational change fearing they would only wind-up incrementally better. In targeting a desired end state, he gave his team guiding instructions to “Assume we’re starting from scratch. Assume that we actually are a startup that doesn’t have over a hundred years of experience and sub-optimized IT legacy.”
In the spirit of change, we should challenge ourselves to develop shared ‘devops’ goals / objectives. In the end, these should help us identify, link and realize how to translate IT objectives / metrics into tangible business benefits / value.
I have listed some shared ‘devops’ goals / objectives that I believe are a good starting point. I encourage and invite your thoughts, opinions and ideas around these and any others that you feel would aid ‘devops’ in working to establish measurable business value credibility.
- Lower the total cost of ownership of all services (best way to achieve this is build them with serviceability, usability and maintainability in the design of all new applications, systems and services).
- Increase business value – achieve business benefits (lower operational costs, increased revenues, improved customer experience)
- Simplified navigation
- Productivity enhancing capabilities /functionality
- Plug ‘n play integration
- Personalization
- Training / On-line Self-help features
3. Minimize business impact
- Reduce change-related outages / incidents.
- Reduce number of problems / incidents / calls.
- Reduce the number of requests / training-related calls / inquiries.
- Provide insights and tracking to the number of Known errors / workarounds / knowledge articles (solutions).
- Speed to resolution based on business prioritization model
- Operating Level Agreement / Commitment between Single Point of Contact (SPOC) Service Desk and internal IT Service Providers based on response / resolution times / commitments.
- Bug-fix Process:
– Provide insights into the ‘bug/fix/enhancement’ list and process with transparent visibility to business prioritization (needs / requirements / quantifiable benefits).
4. Improved and frequent Communication
- A marketing / product launch / status update and awareness campaign.
- Especially around rollout / enhancement time.
Definition: Agile Methodology
Agile Methodology is actually a bit of a controversial term. Various authors consider Agile a method, as distinct from a methodology. Others, prefer methodology over method. For example, using the Merriam-Webster dictionaries, Alistair Cockburn makes the following distinction between methodology and method in Agile Software Development: The Cooperative Game :
- Methodology: A series of related methods or techniques
- Method: Systematic procedure
Alistair views Agile as a methodology in the sense defined above. For example, he discusses Crystal as a family of methodologies. The reader is referred to Alistair’s book for a an excellent analysis of the various aspects of methodologies. As a matter of fact, Alistair tracks down the confusion between method and methodology to certain inconsistencies between various versions of the Oxford English Dictionary.
On the other hand, best I can tell from various conversations with him, Jim Highsmith seems to prefer the term Agile Method. This preference is reflected in Agile Project Management: Creating Innovative Products. It is possible that Jim’s preference is due to writing his book from a project management perspective.
Rather than getting in-depth to the method versus methodology controversy, I would simply cite two definitions I find useful in capturing the essence of Agile methodology, or method if you prefer.
An interesting metaphor for Agile has been used by Jim Highsmith in a 2009 Cutter Advisory:
Visualize a house structure with a roof, a foundation, and three pillars… The roof is business goals — the rationale for implementing agile methods and scaling to larger agile projects. The foundation is agile values or principles — principles that need careful interpretation as to how to apply them to larger teams. And finally, the three pillars: organization, product backlog, and process/practice.
The simplicity of the metaphor makes it quite effective in communicating what Agile is in a concise way without losing the richness of the various elements in Agile.
Using Scrum as an example, colleague David Spann gives the following down-to-earth summary of the key structural components of Agile in a 2008 Cutter Executive Report:
Scrum, as a management methodology, is elegant in its design, requiring only three roles (i.e., product owner, ScrumMaster, and self-organized team), three ceremonies (sprint/iteration planning, daily Scrum/debrief, and sprint review meetings), and three artifacts (product and sprint backlogs and the burndown chart) — just-enough practical advice so agile teams do not overcomplicate the development lifecycle with too much ceremony and documentation.
Needless to say, the structural elements will change from one Agile methodology to another. However, examining an Agile methodology through the {roles, ceremonies, artifacts} “lens” is an excellent way to summarize an Agile methodology. Furthermore, it enables easy comparison between the ‘usual suspects’ of Agile – Crystal Methods, Dynamic Systems Development, Extreme Programming, Feature Driven Development, and Kanban. The reader is referred to The Business Value of Agile Software Methods: Maximizing ROI with Just-in-Time Processes and Documentation for detailed comparisons between the various methods/methodologies.
Three Criteria for Qualifying as Agile
Agile methods have been gaining popularity to the extent that one sees the term Agile used beyond the domain of software methods. Agile Infrastructure and Agile Business Service Management were used in this blog and elsewhere. Recently I have seen the term used in the domain of Business Process Management (BPM). For example, a presentations entitled Best Practices for Agile BPM will be delivered in the forthcoming Gartner Group Business Process Management Summit 2010.
I have no doubt the term Agile will be adopted in various fields. Using BPM as an example, I propose the following three criteria to differentiate between agile (small A) and Agile (capital A):
- Beyond software: A software team carrying out a BPM initiative might use Agile methods. This fact to itself does not suffice to make the initiative Agile BPM.
- Methodical specificity: Roles, forums/ceremonies and artifacts for the BPM initiative must be specified. Folks might be already applying Lean, TOC or other approaches to BPM, but a definitive Agile BPM method has not crystalized yet.
- Values: Adherence in spirit to the four principles of the Agile Manifesto. Replace the word “software” with “product” in the manifesto (just two occurences!) and you get a universal value statement that is not restricted to “just” software. It applies to BPM as well as to any other field in which products are produced and used.
You might be impressively agile in what you do but it does not necessarily make you Agile. The pace by which you do things must be anchored in a broader perspective that incorporates customers and employees. A forthcoming post entitled Indivisibility of the Principles of Operation will explore the connection between the Agile values (plural) you hold and the business value (singular) you generate.
It Won’t Work Here
Two major obstacles to vetting Agile topics effectively with executives were identified in the post entitled The Business Value of Agile Software Methods:
- Lack of hard quantitative data.
- The “It won’t work here” syndrome.
As indicated in the post, the data provided in the study How Agile Projects Measure Up, and What This Means to You and the book The business Value of Agile Software Methods address the first obstacle. This follow-on post is about the second of the two obstacles – the resistance to Agile transformation in the face of hard data on its benefits to other companies.
Resistance in the form of “it won’t work here” is typically anchored in one or more of the following five beliefs:
- Uniqueness: “Some very unique elements exist in our company. These elements render industry data inapplicable.”
- Secret sauce: “Something very special element existed in the companies reporting great success with Agile. Our company does not possess nor have access to the ‘secret sauce’ that enabled success elsewhere.”
- Cultural change: “For the Agile initiative to succeed, our corporate culture needs to change. The required cultural change takes a lot of time and involves a great deal of pain. All in all, the risk of rolling Agile is unacceptably high.”
- Affordability: “The company is strapped to the degree that investment in another software method is a luxury it can’t afford.”
- Software is not core to us: “We are not a software company, nor is software engineering our core competency. Software is merely one of the many elements we use in our business.”
Various other reasons for not going Agile in the context of a specific company are, of course, cited at some frequency. The five reasons listed above seem to be encountered most often by Agile champions.
Use the following counter-arguments to turn around these beliefs:
- Uniqueness: Very rare occurence. Companies use similar business designs, apply fairly standard operating procedures, utilize common technology, are subject to the same regulatory constraints that their competitors are, have offshore sites in places like India, etc. Discussion of your company vis-a-vis its direct competitor usually suffices to overcome the uniqueness claim.
- Secret sauce: The ‘secret sauce’ is neither secret nor difficult to concoct. For example, the secret sauce used by BMC Software in its successful Agile initiative had four simple ingredient: intentionality, know-how, flexibility and patience. Based on insights by colleague and friend Alan Atlas, I have recently added mutuality as the fifth ingredient. Your own secret sauce might be somewhat different, but I very much doubt that an extravagantly exotic sauce will be needed.
- Cultural change: Myth has it that Agile would only work in the Collaborative culture. Reality is it will work in any of the four core cultures identified by Schneider: Control, Competence, Cultivation or Collaboration. See Four Principles, Four Cultures, One Mirror for an approach to building Agile on the strength of whatever culture prevails in your company/organization.
- Affordability: The question to ask is whether you can afford not to improve your software. Tools are readily available to quantify your company’s technical debt. Monetize the technical debt and include it as a liability line item in a pro forma balance sheet. Doing so is likely to shift the discussion from affordability to how to create elbow room for handling the technical debt.
- Software is not core to us: Indeed, it might not be but it is likely to become so in just about any industry. Use an analogy like the record industry vis-a-vis the publishing industry. The record industry has been decimated by software over the past decade. Chances are a similar decimation is likely to occur in publishing unless the industry transforms itself. (Some of the decimation that already took place in publishing has become quite visible recently. For example, last week Bloomberg LP announced completion of the acquisition of BusinessWeek for a paltry $5M).
You will need to be realistically patient with respect to the time it takes for the considerations listed above to sink in. It could easily take six months just to forge a consensus on the subject in the executive team. It might then take another six month to operationalize the consensus. Chances are there is an elephant hidden somewhere in the “room” if you don’t carry the day with within a one year period of diligently vetting Agile with your executives.
The Agile Executive 