So, What is IBM Garage?!
After so many years with the IBM Garage, I am still asked this question by clients and even IBMers who are trying to wrap their mind around this new way of working.
Many times I have been asked by teams, “We’ve been using agile for years and we’ve adopted design thinking in most of our workshops, so how would IBM Garage be any different?”
From other more technical teams I am asked, “We follow DevSecOps practices, we adopted pair programming, we focus on delivering MVPs and not POCs, so how is IBM Garage any different than what we already do?”
In very simple words I would answer that:
“IBM Garage is a collection of practices woven together as a methodology to bring all of IBM together in helping a client realize business value at the fastest and most efficient rate possible.”
Let me shed some light on what that means by explaining some of these practices.
One of the earliest practices we use in Garage is Business Framing. This practice was developed by the IBM Garage for Cloud and evolved by the IBM Services team to focus on client pain points and possible opportunities for IBM to partner with our clients to address pain points through value-focused business opportunities.
Based on that business framing there is viability to establish a Garage for that client. One of the practices that was devised to structure a Garage is the concept of Core and Flex. A Garage is not rigid in nature; it needs to flex if needed. We define the initial core team based on the capacity that we foresee, but as we expose more business opportunities we might need to scale the Garage team using the flex model. What flex really means is additional capacity to allow the Garage to deliver as many outcomes as needed without having to queue things due to limited capacity.
Another very important practice that was developed by the APAC Garage Center of Competency (CoC) team is the concept of an Interface Team. Innovation is not something new; every organization is trying their best to innovate, but most of these efforts fail because the teams driving these innovations are being influenced by the technical and business debt the enterprise is imposing on them. The only way to enable innovation is to shield it and let it flourish before it is exposed to the rest of the enterprise where it can then become an agent of transformation if introduced successfully. The concept of an interface team allows for that to happen. The interface team shields the Garage squads from the rest of the enterprise to allow for their efforts to thrive without being impeded. The interface team consists of two boards—a Garage Board and and Investment Board. The Garage Board is focused on supporting the Garage squads in achieving their mission: approving the business opportunities they will work on, addressing resources and capability challenges the squads can’t address on their own, as well as addressing impediments the squad might escalate where interaction with the rest of the enterprise is needed. The Investment Board on the other hand is focused on justifying the existence of the Garage by tracking realization of ROI. If the Garage team is not achieving the expected business value generation it was created for then it is the duty of the investment board to redirect the Garage team to the path that will generate the business value that would align with the overall enterprise business initiatives and value drivers.
To govern the IBM Garage our APAC Garage COC also came up with a framework they call VOTE (velocity, outcomes, technical and administrative debt, and employee capability and satisfaction). It is a collection of metrics that, when used together, can give the Garage team a a pulse on Garage operations. The term velocity comes from Agile, it is a measure of the number of completed user story points against the number of committed story points by iteration. The reason Agile uses velocity is that story point counting is not comparable squad to squad, but velocity improvement is comparable squad to squad. We actually prefer to use efficiency over velocity as it is a measure of work completed against work planned so it can can capture effort not just story points as velocity can capture. Outcomes is a measure of the expected business value that is being generated from business opportunities identified and realized by the Garage squads. Technical and administrative debt consists of several things; one being productivity: the amount of productive hours compared to the amount of wasted hours. Wasted hours could result due to impediments; that is why we prefer to call this metric productivity as technical debt isn’t the only contributor. Employee capability and satisfaction is a measure of the cohesiveness of the Garage squads—their ability to deliver the work expected of them, how they work together, and how they value the work they do. We prefer to call this engagement as it embodies all of these aspects and much more.
As we progress through the various IBM Garage phases we uncover yet more practices.
In the Co-create phase we would usually start by conducting user research around the business initiatives communicated to the Garage team by the enterprise. That research would be an input to an Envisioning Workshop focused on identifying value drivers and key metrics that map to the business initiatives. We would also identify pain points and outline as-is scenarios that would help us generate improvement ideas that we would frame into potential business opportunities that we can pursue in the Garage. This Envisioning Workshop relies heavily on Enterprise Design Thinking practices.
The Garage team would use value orchestration practices to estimate the value of the business opportunity. Various techniques are used to estimate the value of a business opportunity, and that value would continue to be refined throughout all the stages of the Garage.
As we further refine the business opportunity, we draft it in a Business Opportunity Canvas that covers 16 different aspects of the business opportunity and is used by the Garage team to communicate their vision to the Garage board and gain their approval to proceed with that business opportunity.
As part of refining the business opportunity the Garage team would develop one or several problem hypotheses and go through an exercise of validating these problem hypothesis with a group of sponsor users. This practice of validation is based on Lean Startup practices. If the problem hypothesis is proven wrong, we pivot to identify a more suitable problem hypothesis.
Once the problem hypothesis is validated, we would start to look at possible solutions. The Garage team would draft these as solution hypotheses and go through a validation process similar to the problem hypothesis validation. Prototypes could be used during the validation process to get feedback from sponsor users. Anything uncovered through this process is used to further refine the Business Opportunity Canvas.
The Garage board would meet on a regular basis and review all proposed Business Opportunity Canvases and make decisions on which to be approved to proceed to the next phase of the Garage.
In Co-execute the Garage team would start to develop conceptual architecture and design for the approved business opportunity, which would be an input to an MVP (minimum viable product) Workshop. That MVP Workshop is based on enterprise design thinking practices and focuses on exposing all the features of the proposed solution and narrowing down to the key features needed for a minimum viable product. But we do not stop there; the Garage team would then break down the MVP into all the user stories and activities needed to realize it. This will be the foundation for iteration planning for the MVP.
From this point on we typically follow standard Agile and DevSecOps practices to realize the MVP. The only difference with IBM Garage is that we would perform an MVP Market Fit validation to make sure the MVP we created is on target to achieve the expected business outcomes we identified during Co-create. This is done by confirming the value driver metrics we captured early on during the Envisioning Workshop in Co-create. If for some reason we fail to validate market fit we would need to go back to the drawing board. Once market fit is validated we would then proceed to scale the MVP in Co-operate.
In Co-operate we perform an MVP Scaling Workshop where we identify challenges, identify ideas, and develop actions to address around production workload, security, compliance, regulation, ennoblement, adoption, value, go to market, distribution, service, support, deployment, and go live.
Our North America Garage CoC developed two additional practices of note. The first practice, called the Golden Thread, is used to validate the solution hypothesis. The Golden Thread is a representation of the user journey for the solution. It is shared with the enterprise and feedback is collected from all stakeholders and parties of interest. The Golden Thread is updated as the solution evolves through the Garage phases. The second practice is called Pain Point Tracker and is used to capture the pain points identified during the Envisioning Workshop in Co-create and maps the features addressed by the MVP in Co-execute to the pain points they are addressing. This helps us make sure each feature introduced is addressing a key critical pain point.
The IBM Garage Methodology is also manifested through a set of tools that enable Garage teams to perform the various practices and enforces the governance needed by the interface team to support the Garage. These tools range from assessment of client readiness for the Garage way of working, to governance and operation of the Garage, to opportunity value projection, to squad health surveys, to opportunity framing and business case justification.
Now that we have more background on the practices that make up IBM Garage, you should also understand that there is more to IBM Garage than its practices. IBM Garage is a way of working that brings together all of IBM with undivided focus on generating business value with our clients. What that means is that different IBM business units do not create separate Garages for one client. Instead, we recommend that we have a single Garage for each client and various IBM business units join the Garage flexibly based on the capabilities, skills, and assets that are needed to realize the identified business opportunities that we uncover with our clients. That is why IBM is the only company in the world that can deliver the breadth of capability in almost every aspect of IT as well as the depth of expertise we have developed over decades of experience in every industry that we bring to the table when we collaborate with our clients. To facilitate this kind of IBM business unit collaboration, we have aligned several of the methods used within IBM to the IBM Garage Methodology so when these business units join a Garage they can be clear on where the practices they use align to the various IBM Garage Methodology phases and practices.
I welcome your thoughts and feedback on my characterization of what IBM Garage is and how it is different from other practices and frameworks.
The best way to know more about IBM Garage is to acquire the IBM Garage Essentials badge available to everyone at: http://ibm.biz/garageessentials
If you start to get involved in an IBM Garage, I would recommend you acquire the IBM Garage Practitioner Badge available at: http://ibm.biz/garagepractitioner
If you are a squad leader in an IBM Garage, I would recommend you acquire the IBM Garage Squad Leader badge available at: http://ibm.biz/garagesquadleader
If you have led several IBM Garages, I would recommend you acquire the IBM Garage Leader badge available at: http://ibm.biz/garageleader
And if you are a master of everything that is IBM Garage, then I would recommend you acquire the IBM Garage Coach badge available at: http://ibm.biz/garagecoach
Authored by Dr. Mohamed El-Refai, IBM Distinguished Engineer, IBM Garage@Scale Leader
Illustrated by Chloe Sun, Olivia Wen and Zhuo Ma, IBM Studios Dalian Designers
