The IBM Bluemix Garage Method provides industry best practices Utilizing IBM Design Thinking (Lean Startup, Agile Development, DevOps and the impact with Cloud) to help you build and deliver innovative solutions quickly and reduce adoption issues. We have seen great successes using the Bluemix Garage to facilitate and support the transformation at clients. However, it was mostly focusing towards the design and build part of the lifecycle.
In April of last year, we applied the same concepts from DevOps to the operational domain. It was well received by customers and had the additional benefit in reducing adoption issues. From there we started developing a Garage Offering that is focused on the Run and management side, to cover Cloud Service Management and Operations. The offering is available since end of 2016 and after presentations at Fast Start and Interconnect conference many people have expressed strong interest in running an engagement with them / with their clients.
What do we do in the Garage?
Digital transformation is in everybody’s mind, with the push towards Mobile, Social, but also Big Data and Cloud as enablers of this transformation. Practices are entirely revamped to increase development velocity and the ability to release new functionality fast and frequently. Operations need to support this velocity (or risk shadow IT or further divergence between the LOBs and central IT). However, legacy processes, cultural issues and different needs/viewpoints are standing in the way of this: central IT focuses on proven processes where the LOB is moving rapidly to DevOps with Continuous Integration and Continuous Delivery to remain competitive in their marketplace. Processes, roles / organizations, tools and – quite frankly – culture must change to support this new paradigm. Therefore, the main objective of the Garage is to stimulate this transformation and support clients in adoption of cloud and becoming successful in this transformational journey.
Rather than prescribing a one-size-fits-all approach, we use methods like IBM Design Thinking to nurture this transformation. It is the client team that needs to become the change angles in their company, so they need to experience the transformation, and come up with the solution to their most critical problems. For this reason, we invite key representatives of the client into the Garage: Head of Operations, Developers, Architects, but also administrators that sit on the bridge, perform incident management and resolution. We also welcome end-users, or someone representing the user, for instance a Service Manager.
Frequently, this is the first time that these people work together in a project. In Design Thinking, a critical element that we will use is the notion of Personas, expressed through Empathy Maps. An Empathy Map shows what a Persona (a specific archetype of a user) is thinking, feeling, doing, and saying. By understanding how they feel about the system, and how they react to the system, designers, developers, and administrators can obtain a better shared understanding of how different design and implementation choices will be interpreted.
The next step is to define the current state, or the As-Is scenario(s). Scenarios could be for instance Incident Management, showing the full lifecycle of an incident from detection all the way to the restoration of the service and ultimately its Root Cause analysis. Other examples could be Change Management, Release Management, Etc.
Once the as-is scenario is defined, we would identify pain-points that exist today. It is quite interesting to see where the friction in the processes and tools reside, where the lack of information is causing delays and efficiency / quality issues. This step helps us to the design the future state. Using Ideation the group comes up with ideas how to address these issues. In this step, IBM subject matter experts may provide their experience and insight on potential solutions, or what they have seen with other clients. With a large set of ideas – at this state we favor quantity over quality – we then need to identify the top ideas. Using a particular prioritization strategy we have isolated a few ideas which we now enrich and extend. The design thinking element “Storyboarding” further helps us to narrate the idea.
Throughout the entire process, we inject some short Ignite Talks to spark new thoughts and stimulate the thinking of the group.
The information gained through applying these aspects of Design Thinking results in a touch point that the team can rally around – the description of a Minimum Viable Product (MVP). An MVP is the smallest, most tightly focused description of what a team can deliver and still bring measurable value. Sometimes we also use the MVP to validate a hypothesis (i.e. “if we do x, we would improve MTTR by y%”).
What are MVPs?
Minimum Viable Products (MVPs) are well known in the context of Development, but what are MVPs in the context of Service management? For me, MVPs generally could be put in one of four buckets
- Process Improvements
- Role / Organization Improvements
- Tool Improvements
- Culture Improvements
Let me give you a few examples to describe each of these categories
For process improvements, an example would be Build to Manage (BTM). The underlying concept is that developers instrument their products / services to become more manageable, to ease operations and expedite MTTR (mean time to restore). An MVP could be that new micro services will be instrumented with the HealthCheckAPI, and that this API will then be monitored for availability.
Other examples are the transition from reactive monitoring towards proactive and predictive monitoring and management. The MVP would be to pilot a prediction tool and establish the necessary process changes to treat predictive events as important as the traditional alerts.
For role improvement, an example would be to establish new roles like a First Responder that is empowered and skilled to resolve an incident with little dependency from other people / organizations. Certainly, this has requirements to the skill and experience of people fulfilling this role, but also empowered to perform the necessary actions to restore the service. Equipped with the right tooling and knowledge repositories, the future First Responder may span the traditional Level-1, Level-2 and potentially Level-3 roles.
Are more fundamental change would be to seed the concept of Site Reliability Engineering at the client. This would be a major undertaking, so one needs to carefully identify the right steps to lead into this transition.
Examples for technology improvements are: Development of user-specific dashboards that visualize the key metrics of the application (SLI, Service Level indicators) together with business-oriented key performance indicators.
Most of these MVPs play not just in one category. An example for the combination of technology and process could be ChatOps: Improving the incident management process using highly collaborative tools where people not only communicate with each other, but also with service management tools. While you still use the traditional incident management / helpdesk tools, the actual collaboration during investigation may happen in tools like Slack.
Blame-less Root Cause Analysis is an example where process improvements frequently depend on cultural changes. Rather than finger pointing, the purpose of the blameless postmortem is to find out what happened and how to make the organization better. When this is done effectively, it creates an environment where team members enthusiastically share mistakes in order to help prevent others from making the same mistake.
These are only a few examples of MVPs. Per definition, the Design Thinking Workshop is open with regards to what the identified MVPs. While we have seen MVPs reoccurring, we frequently see new MVPs being identified.
To keep the momentum, the implementation of these MVPs will be performed right after the Design Thinking workshop in what we call the “MVP Buildups”. A joint team of client specialists and IBM subject matter experts is being compiled, allowing us to inject our vast experience in Service Management and to coach the client in the journey. The implementation itself follows agile and lean concepts, for instance we perform regular Standup Meetings. Regular Playbacks to the identified personas will help to steer the project in the right direction and incorporate feedback immediately.
How to get started?
To propose the concept of a Garage to the client, we typically conduct a “Garage Visit” with the key stakeholders of the client. We would motivate the need for and benefit of change and show the IBM Point of View on Cloud Service Management and Operations. Throughout the day, we highlight success stories and testimonies, for instance how IBM reorganized its Cloud Marketplace operations towards the SRE model.
In addition to get the agreement to proceed by the stake holders, we would also define a problem statement to set the context for the upcoming workshop. For this, we already practice some concepts of IBM Design Thinking by defining the objective using Mad Libs :
This visit ideally should happen in one of our Garage Locations to convey the underlying theme of innovation, start-up culture, and disruptive ideas – doing this in a traditional brick and mortar location may be counterproductive.
I hope this gave a good introduction to the Service Management offering in the Garage. In the visit, we get agreement from Stakeholders and set a common objective. The workshop follows the IBM Design Thinking principles to identify solutions for the critical pain points. The solutions are details in MVPs, which will be jointly implemented in short-duration MVP Buildups. Multiple of these buildups lead towards the operational transformation.
We are excited working with clients in the transformation towards an operational model that provides higher quality, effectiveness and efficiency for todays increasingly dynamic and agile world.