IBM Garage radically changes how you deliver tech-enabled innovation

Share this post:

How well do you know the Bluemix Garage? CTO Rachel Reinitz calls it “a collaborative environment to work as one team with clients to rapidly define, design, develop, validate, analyze, and deploy successful apps.” In fact, she says, “Our Bluemix Garage Method melds industry best practices, startup culture, and IBM’s expertise, and adapts these for the needs of our clients, large or small.”

But that’s only the beginning.

How do most Bluemix Garage projects get started?

Most innovation projects start with a two-day design thinking workshop. Before starting the workshop, businesses have identified an area of opportunity (but not a solution—that’s what the workshop is for). Identifying the right mix of participants is also important. Diverse perspectives are key, so it needs a mix of business, design, and technical folks—and also a mix of Garage and client personnel. Design thinking frames problems in terms of the user, which can be an incredibly powerful way of finding innovative solutions. It works best when actual users are in the room, although that’s not always possible, depending on the problem domain.

At the start of design thinking, we usually have a loosely defined problem but no solution. By the end of the two-day workshop, we’ll have an insight into how to help our user, a long-term vision, and a crisp definition of a minimum viable product. The minimum viable product (MVP) is the smallest thing we can build to test our business hypothesis.


How long does it take to build an MVP?

Building an MVP will usually take about six to eight weeks. We start with an inception, which takes the output of the design thinking workshop and turns it into a backlog of user stories. Compared to the non-iterative, traditionally managed, multi-year projects many of us are used to, six to eight weeks to get something out to real users is very fast indeed—and this is not just a clickable prototype or a hacked proof of concept. Because Bluemix is great, the Garage is lean and efficient, and the team is so high-performing, we could do a prototype in a couple of days.

But we build for something scalable, maintainable, robust, and with an integration to on-premises systems which may need a bit more patience. Not that much patience is required, though, because we deploy new code a couple of dozen times a day—our stakeholders can always have a play with features which are hot off the press.

What makes the Bluemix Garage Method successful?

Frequent feedback is a key motivation of the Garage methodology, and this is reflected in our weekly cadence. (Another way of thinking about “frequent feedback” is “nasty surprise elimination.”) We have an iteration planning meeting on Mondays, short daily stand-up meetings, and a retrospective on Fridays.

The iteration planning meeting is a chance to get a shared team understanding of what’s coming up next in the backlog, and identify any user stories which need to move up or down the prioritized list. Product owners also can (and do!) add new stories and adjust priorities throughout the week.

Our daily stand-up is a chance to share the previous day’s progress, plan the day’s work, and rotate programming pairs.

The retrospective is a chance to reflect on the week, generally with one of the on-tap beers or ciders provided by our lovely co-working office. We celebrate things that have gone well and figure out how to fix things which didn’t go so well.

Notice that there’s no slot for playbacks. This is because the product owner accepts user stories daily (probably several). This means we don’t need to have a special meeting to show them what we’ve been up to, because they already know. (For a project with many stakeholders, playbacks may be appropriate, and in that case, we’ll do them.)

As well as continuous acceptance testing, we do pair-programming, test-driven development, and full devops—we think it’s the best way to flush out problems early and de-risk projects.

Tech tips from a London Bluemix Garage insider

It’s an awkward truth of our industry that many IT projects run over budget, don’t meet user expectations, or just fail entirely. Our approach in the Garage is to ensure that the business gets all feedback and information it needs to make decisions as early as possible and have the flexibility to act on them. In a Garage project, the business has full control of the work backlog and project scope, so that it can act on lessons learned throughout the project—instead of being locked into a scope defined at the project start. The beginning is when we know the least about the technical landscape and what users really want. Customers are sometimes surprised when they ask if it’s possible to change direction and we answer, “Sure! Just re-order the backlog and we’ll get right on it.” In order to really drive impacting, technology-enabled innovation, feedback needs flexibility.

Meet Holly and the team by


WW Development Discipline Leader - Cloud Garage

More Community stories
May 3, 2019

IBM Garage Method Applied to Moving to and Modernizing with IBM Cloud

The IBM Cloud Garage has expanded our expertise, patterns, and assets to guide our clients’ existing applications to “move-to-cloud” and to better manage their hybrid and multicloud environments by leveraging a variety of IBM Cloud capabilities.

Continue reading

April 30, 2019

IBM Cloud Garage: Blockchain and New Business Models

The IBM Cloud Garage has played a pivotal role in helping clients uncover the feasibility and potential of blockchain technology.

Continue reading

April 25, 2019

Ten Learnings from Five Years of Intrapreneurial Success in the IBM Cloud Garage

For Rachel Reinitz, CTO and Founder of the IBM Cloud Garage, it has been an incredible five-year journey. More than anything, it has been the talented, collaborative people she's gotten to work with and the creation of value for our clients that have made it a great growth experience.

Continue reading