Deep Creek Center home.

Category: Making IT Work

New Blog content from President of Deep Creek Center or guest contributors.

Why organizations fail in using Agile/Scrum practices – missing the forest for the trees

Why organizations fail in using Agile/Scrum practices – missing the forest for the trees

One of the deeply fundamental problems with how people wrestle with the adoption of Agile practices is that the “point” of using Agile is often lost on most of the participants. Many people have a VERY loose understanding of what Agile is even about. They often hear Agile and think

–          New meetings

–          Continuous Deployment

–          No changes during sprints

–          Visual Task Boards

While some of these are true, they’re not “the point.” WHY does thinking and acting in an Agile way help us?

Agile helps us focus on business value

In any endeavor, the temptation is to focus on the “to-do list.” What do I have to build/buy? What do we have to operate? But the bigger question is always “so what?” How does this help customers get the results they need? Who exactly uses this and when/where/why? The big idea in Agile is moving our teams from thinking about tool features (what it can do) to customer benefits (what I can do). Using User Stories as a fundamental organizing principle of our Product Backlog reminds us to focus on use and value, not on the system itself. Using a prioritized backlog ensures we are doing the most important things first, all the time.

We don’t know what we don’t know

Agile also acknowledges some fundamental challenges in how we work. Most methodologies acknowledge that work should begin with the customer’s requirements, but the real challenge here is that the customer’s understanding of their own requirements is often very fuzzy. Not that people aren’t trying to give IT good information, but everyone learns through the process, and then the customer will likely change their minds about certain things, adding certain pieces, changing others, and removing ones that turned out to be bad ideas. THIS IS GOOD! Agile practices simply acknowledge the truth of continuous learning and improvement, and make it possible to be need and priority driven instead of plan driven.

Risk Mitigation begins with early delivery of the highest value pieces

All services, whether formalized into projects or not, are valuable because they support outcomes for customers (enable them to get things they want) while managing costs and risks. Risk mitigation is never the most fun part of a service, but it is deeply fundamental to the value proposition. Agile practices support risk mitigation in many ways, but the greatest risk in my judgement is not getting enough engagement, input, and “fingerprints” from the customer in how we create solutions. By supporting team models that actively engage the customer throughout the process of developing solutions, Agile practices can course correct earlier, save rework, deliver solutions earlier, and improve solution stability.

Digital Transformation means thinking less about departments and divisions (IT vs business) and much more about teaming; how different business capabilities collaborate to automate and improve business processes and workflows. In upcoming blogs we will investigate how some of our customers are using Agile practices to transform how their organizations are creating new value and new business opportunities for their stakeholders.

Agile as a Business Transformation Practice

Agile as a Business Transformation Practice

One of the deeply fundamental problems with how people wrestle with the adoption of Agile practices is that the “point” of using Agile is often lost on most of the participants. They often hear Agile and think

  • New meetings
  • Continuous Deployment
  • No changes during sprints
  • Visual Task Boards

While some of these are true, they’re not “the point.” WHY does thinking and acting in an Agile way help us?

Agile helps us focus on business value

In any endeavor, the temptation is to focus on the “to-do list.” What do I have to build/buy? What do we have to operate? But the bigger question is always “so what?” How does this help customers get the results they need? Who exactly uses this and when/where/why? The big idea in Agile is moving our teams from thinking about tool features (what it can do) to customer benefits (what I can do). Using User Stories as a fundamental organizing principle of our Product Backlog reminds us to focus on use and value, not on the system itself. Using a prioritized backlog ensures we are doing the most important things first, all the time.

We don’t know what we don’t know

Agile also acknowledges some fundamental challenges in how we work. Most methodologies acknowledge that work should begin with the customer’s requirements, but the real challenge here is that the customer’s understanding of their own requirements is often very fuzzy. Not that people aren’t trying to give IT good information, but everyone learns through the process, and then the customer will likely change their minds about certain things, adding certain pieces, changing others, and removing ones that turned out to be bad ideas. THIS IS GOOD! Agile practices simply acknowledge the truth of continuous learning and improvement, and make it possible to be need and priority driven instead of plan driven.

Risk Mitigation begins with early delivery of the highest value pieces

All services, whether formalized into projects or not, are valuable because they support outcomes for customers (enable them to get things they want) while managing costs and risks. Risk mitigation is never the most fun part of a service, but it is deeply fundamental to the value proposition. Agile practices support risk mitigation in many ways, but the greatest risk in my judgement is not getting enough engagement, input, and “fingerprints” from the customer in how we create solutions. By supporting team models that actively engage the customer throughout the process of developing solutions, Agile practices can course correct earlier, save rework, deliver solutions earlier, and improve solution stability.

Digital Transformation means thinking less about departments and divisions (IT vs business) and much more about teaming; how different business capabilities collaborate to automate and improve business processes and workflows. In upcoming blogs we will investigate how some of our customers are using Agile practices to transform how their organizations are creating new value and new business opportunities for their stakeholders.

ITIL Practitioner: Finally the ITIL Certification we actually wanted!

With the upcoming February launch of the new ITIL Practitioner certification, we finally have the answer to the most frequently asked questions about ITIL.

  • What do I do to get started?
  • What should I focus on first?
  • What is the “next class” after Foundations?

ITIL Foundations has enormous scope; from strategic planning to continual improvement, from service architectures to operational support, from knowledge management to portfolios. As a 3-day class (and usually as two and a half), it is designed to provide persons new to service management with an extraordinary amount of information in a short time, much of which is new and outside the immediate scope of the work that person performs on a daily basis. In many ways it begins a journey of awareness of how IT organizations as service providers create value for customers, and how each of the stages of the service lifecycle drives and improves the value to the business.

But then the proverbial question…what do we DO now that we know all this?

ITIL Practitioner is fundamentally different than all of the other ITIL credentials. It is intended specifically to address “how-to” ; what exactly should we DO to start the ITIL journey successfully in our work, our teams, and our organizations? It is grounded in 9 key principles broadly shared with agile and other continual improvement models, and backed with specific tools and techniques to get started. It focuses on helping to instill continual improvement and leverages industry best practices in organizational change. It reinforces the need for strong metrics and measures to meaningfully assess, for better or for worse, “where are we now” so we can work to build meaningful and demonstrable improvements.

The 9 principles are broadly outlined here

  • Start where you are – Virtually none of us are working in greenfield environments, or with no existing processes or tools. Start your journey practically by looking at existing practices and working to improve them, as opposed to rip and replace.
  • Focus on Value – Many organizations become consumed by implementing new policies, processes, and especially ITSM software tools. The focus instead must be on the value to the customer; how do these things help us improve efficiency and effectiveness, reduce costs, and improve results?
  • Work Holistically – Service at its most basic means thinking end-to-end. How do all of the hardware, software, people, and other resources and capabilities make and support outcomes customers want? For many organizations one of the first steps in the ITIL journey must be to start “thinking in service,” instead of in technology components. This raises issues about coordination across technical/functional teams.
  • Keep it Simple – There are lots of potential places to begin service management improvements, and many improvements to choose from. Eventually success is driven by keeping your approach simple and straightforward, and focus on how specific, simple improvements to processes, tools, and teams can enable meaningful value for your customer.
  • Be Transparent – There are lots of “political layer” issues that can derail improvement initiatives in any organization…what’s the “real” reason for the change? Transparency demonstrates to the organization that we are committed to delivering the best that we can, and also demonstrates to stakeholders the very real constraints that we face. Rather than overpromising and underdelivering, transparent practices enable clarity of understanding across stakeholders and facilitate prioritization of efforts to improve value.
  • Collaborate – Most service provider organizations consist of a number of very smart, talented, and diverse individuals, with different levels of background and experience that can be brought to bear to improve services and processes. Creating effective collaboration models enables better solutions, improves buy-in, and demonstrates that this is a “team game.”
  • Progress iteratively – All of your processes and practices got to their current state through small, iterative changes over time. While many managers seek “zero-to-hero” improvements, iterative and consumable improvements are demonstrably better at creating lasting change, as anyone who has been able to lose weight AND keep it off will attest.
  • Observe directly – People often tend to look exclusively at reports and make important strategic decisions without direct engagement with many of the key stakeholders. Whether we’re trying to improve a business process, or facilitate operational improvements at a service desk, direct observation of the work will help us to better understand the processes in question (and find gaps in the process documentation!) This will help us to prescribe satisfying solutions that deliver the intended benefits, with the direct inputs of the key stakeholders improving buy-in and commitment.
  • Design for Experience – Many services “work” in the sense that they tick a list of requirements boxes, but don’t take into account the unique needs of the users of the system to successfully execute business process workflows. Service designs must take into account not only what a system must do, but what people must do, and how real people use the system to deliver value. This means a much greater focus on use and use models, and development approaches like Scrum or XP that focus on whole slices of solution based on a business and user need, not just a feature list.

One of the key benefits of the new guidance is specific tools and templates your team can adopt and adapt for immediate use to get started. These include templates for business case development, CSI tools, CSF and KPI development, assessment tools, communications tools, stakeholder management, and much more. Training programs for ITIL Practitioner focus on teaching your teams how to use these tools for immediate value.

I do like to think of the ITIL Practitioner credential as the ITIL certification many of us have been seeking for a long time, especially in the enterprise. I recommend this program for ALL ITIL candidates. While it is suitable for students fresh out of Foundations, the scope of the credential is so different and the approach so practical and useful that I strongly recommend it for all of my ITIL-credentialed students, up to and including ITIL Expert and even Master. I’m genuinely excited about what this will do for all of our customers trying to “get past talking” about ITSM and get demonstrable results. Good luck and reach out to us if you have any questions at all about this or any other ITIL issue.

Portfolio of What?

Many organizations struggle to understand and differentiate project portfolio management from service portfolio management. This is an important distinction, because project portfolio managers understandably focus on the project portfolio. This is useful, but ultimately misses the point of looking at the investment of service assets across the service lifecycle.

The basic idea behind service portfolio management is simple but profound. We only have a finite number of service assets available to us, and the goal is simple in concept though tremendously difficult in practice: optimize the value you create for your customers, and the value you capture as a service provider.

Strategy is fundamentally about dealing with constraints. If we didn’t have constraints, we wouldn’t really need a strategy, just a plan to execute. Because we are not omniscient, we need to establish strategies to help us best assess cost, risk, and value of delivering different types of services.

One of the fundamental objectives of most service management initiatives is optimizing investment, especially in areas of the organization such as service operation. By using service portfolio management, the focus is not only on optimizing the performance of projects, but ultimately the shifting of resources from reactive activities to proactive activities that drive better value for the organization.

Many organizations focus on the service operation and transition process areas of ITIL, but much of the better value proposition is actually higher up in the service lifecycle. Take the time to explore some of the value of the service strategy and service design books.

Build out the higher end processes. It’s well worth your time and investment.

Putting the Service in IT Service Management

Many people understandably think about ITIL as a process framework. When you describe good practices for 25+ processes and capabilities it seems a no brainer. Yet when you look at the books, their names, and their objectives, it becomes clear that processes are an important means (COBIT calls them one of seven enablers), but that the desired end is delivering services.The entire concept of service in ITIL is embedded in thinking end-to-end; how service teams facilitate outcomes for customers and manage costs and risks on their behalf.

When I teach ITIL courses, I emphasize the idea that services describe not in fact what we do in IT, but what the customer gets. How do our hardware, software, people, processes, etc. produce valuable results for customers and enable them to perform better, faster, or more cost-effectively? The entire construct of information technology is predicated on the CSI model, or how the technology enables the use and processing of information to automate and otherwise facilitate business processes.

If the goal is services (and therefore outcomes for customers), the how-to is the Service Lifecycle. WAAAAAAYYYY too many people consider ITSM consistent with the operational and support process around Incident, Problem, Change, and Configuration Management. In order to set the table for success in those operational processes, we have to be able to manage the service first. Here is a brief summary of how the Service Lifecycle notion really supports the cultural transformation from technology provision to service and outcome enablement.

Service Strategy – there are many things we’d like to do, but simply cannot. Why? Not enough money, time, people, etc. In short, we are always facing some type of constraints. Therefore, given all of the things we could do, what things will we commit to do, and who decides? Service Strategy outlines a transparent way to make strategic decisions in the face of uncertainty and limitations.

 Service Design – how do we understand customer requirements for a service (utility and warrant you), and how do we in turn build/buy/integrate a service to meet the requirements. The Service Design processes enable us to essentially take a piece of paper (a Service Charter, and Approved Change Request, etc.) and transform it into a new or updated service.

Service Transition – my usual flip statement about Service Transition is how to take a new or changed service from development successfully into production without “blowing stuff up.” Sadly, the industry data continues to finger transition practices as a primary reason for production incidents. In the highly dynamic and Agile world we are working in today, change is normal and a fundamental source of competitive advantage in business. Our ability to streamline transition practices and build compelling and highly reliable models is critical to supporting highly iterative business needs.

Service Operation serves essentially as a party host. Deliver services to customers according to our agreed levels and support them as needed. In order to actually be able to operate services, we have to be able to visualize them (typically through a CMS), monitor them, and be able to coordinate support for them across a number of technical/functional teams. The service lifecycle emphasizes early engagement with operations teams during design, transition ( and even strategy) to ensure we don’t get over our skis when establishing service targets that will be incorporated into SLAs.

CSI emphasizes the need for accountable owners and the intentional and ongoing use of metrics and measures to drive ongoing, consistent improvement in the performance of processes and services. CSI supports process and service owners (and managers) in the proactive seeking of improvements in all practices across the lifecycle, and drives the execution of the 7 step improvement process to execute improvement projects and drive iterative improvement in practices.

 While each service lifecycle stage clearly uses processes to carry out many of their activities, the bigger value proposition is how the service lifecycle itself visualizes how we manage constrained resources to optimize service value delivered for customers. In this blog we will explore many processes, but you will see me tend to tie these back to bigger picture questions that hopefully answer the “so what” question for you. If we follow these practices, so what? Stay tuned!

Crossing the Chasm – Projects, Operations, and Best Practices

Deep Creek has worked with customers for many years to help them better align IT services to business needs. This has drawn us to provide training and mentoring support in lots of different best practice areas, from governance, to quality management, to project management, to service management, and so on. When ITIL restructured itself in V3 to a service lifecycle approach, I was hopeful that this would begin to address the yawning cultural gaps I see in many organizations between development/design teams and operations/support teams. It seems to have gotten sufficiently bad now that people who develop applications don’t even perceive themselves to be in IT at all; that term is reserved for operations teams, with a definite negative tone.

(more…)

Free ITIL Lessons Learned Webinar Coming Soon

Lessons Learned from 200 ITIL Implementations over 20 Years

Don’t miss our upcoming free ITIL webinar on “Lessons Learned: Best Practices in Implementing ITIL Best Practices.” Deep Creek Founder and President Patrick von Schlag will review many of the most critical issues organizations face in implementing ITIL and how to overcome them.

Register for the Webinar

 

Blended learning – a new concept that isn’t new

Blended learning programs have been around for as long as people have been learning. The core idea of course is very simple. Instead of a “one-size-fits-all” approach to learning a new set of knowledge or skills, combine multiple approaches in a way that provides the student with flexibility that allow adaptation to support different learning styles and pacing.

Sounds like a simple good practice to me; find an efficient and effective way to get someone the knowledge and skills they need.

The dirty little secret of the training industry is this one: most people don’t in fact want training at all. They want knowledge, skills, experiences, and perhaps recognized credentials. Training at best is a means to these more meaningful ends. From the learner’s perspective, the goal is simple: achieve the ends with the “right” combination of means, whatever that is.

Deep Creek recognizes that not all learners want to take (or even can afford the money or time for) 5-day courses on every subject. That’s a supplier-driven view of the world. Learner-based programs have to offer a combination of key resources:

  • Effective methods of knowledge transfer
  • Peer interaction and engagement
  • Expert coaching and support
  • Validation of the knowledge and skills

Our approach to learning is anchored in supporting learner choices and options. Choices in classroom vs. self-paced vs live-over-the Web classes. Mentoring support communities of practice. Real experts providing more than just “real-world” training; “really good lessons learned” so that participants benefit from the accumulated knowledge and good practices of hundreds of market leading organizations.

Blended programs are often as distinctive as you…let us know your “ends” and we’ll work with you to provide the “means” to help you achieve your goals.

Business analysts crack the code for IT/business alignment and integration

Regardless of the job boards or “skills in demand” surveys you watch, one of the fastest growing areas in IT is that of the Business Analyst. Now, it may end up taking some slightly different titles…Requirements Engineer, Service Manager, or even Business Process Modeler, but make no mistake, this is a critical job role for now, and one with accelerating need in the future, with more strategic sourcing, more business needs, and more dependency on IT to automate and facilitate business processes.

As the name implies, a Business Analyst’s job is to, well…, analyze business practices and facilitate IT solutions to business problems and opportunities. Most of the time, this involves

  • Eliciting requirements through various techniques (interviews, workshops, etc.)
  • Modeling requirements (using tools like use cases, process models, class diagrams, etc.
  • Validating and prioritizing requirements

Regardless of a business’s sourcing strategy, requirements must be elicited and validated in-house (to ensure no foxes in the henhouse). The most important ability to deliver successful IT projects is to be able to correct capture and manage requirements; without the correct requirements the project team stands virtually no chance of success in delivering the right business solution.
Successful business analysts support their customers in

  • Early-stage business case development and prioritizing business investments in IT
  • Identifying key stakeholders and documenting stakeholder drivers, requirements, and outcomes
  • Supporting a cross-functional view of business processes and facilitating process efficiencies
  • Focusing IT solutions on realized business benefits, and not just tool features
  • Aligning customer requirements to achievable and deliverable IT targets
  • Properly scoping and controlling IT project timelines, costs, and deliverables

While there are many different skills areas fundamental to a business analyst, one place to learn more is the Business Analysis Body of Knowledge (BABOK), published by the International Institute of Business Analysis (IIBA). All of our courses are approved as recommended preparation for IIBA certifications like the Certified Business Analysis Professional (CBAP).