A little over a year ago, I was asked to help start an initiative within our software development organization, called the "Bringup Lab". Since its inception, it has become a critical element of our software delivery process, and I'll describe in this blog what it is and how it complements existing development processes.
Let me first describe the context within which we created the lab: IBM Cloud Paks. Cloud Paks are assemblies of related software services running in containers, on Red Hat OpenShift. They cover a large set of capabilities, developed by teams literally spread across the globe, addressing a large set of use cases and solutions. Yet, the intent is that they all follow a common set of best practices, support a common and consistent operational model, and reuse designs and code wherever it makes sense. Duh, right?
We have a number of processes in place that promote and support this commonality, including centralized packaging and delivery and an internal 'certification' program that helps enforce the rules, so to speak. You can think of the Bringup Lab as an extension of that entire delivery process, but with an explicit outside-in perspective. In the lab, we run things as if we were a customer. For starters, we use the official documentation, and not some internal document that contains all the internal tricks and secrets only the developers know. We also combine various components in ways that the individual development teams don't, since they are focused on their individual capability only, and we run them in places and configurations they haven't been run before (the idea of "runs anywhere" is a key characteristic of Cloud Paks). But what drives it all is the question "what would a real user of the software do?"
By the way, the "Bringup Lab" is not really a lab, in the physical sense. All of the members of the team work remotely and are mostly in different locations. So, think of it as a virtual lab. And given that we run most of the workloads in some cloud, it doesn't matter anyway; we don't have physical servers we need to take care of. What we do need, however, is an appropriate set of accounts in the various places we use, so that we can deploy workloads there as we see fit. One fun aspect of it is that we have become fairly versatile in the use of the different public clouds. We don't have individual experts for individual clouds, all of us know all of them well enough for our needs. And it is a small team, less than ten people currently.
Everything we do must lead to an outcome. And these outcomes are in one of two categories (or, ideally, both):
- It must lead to improvement of the product itself. Whenever we find a technical issue, or a problem with the documentation, or a usability/consumability concern, we raise a defect against the appropriate team to get them to address the issue. We are a lot less interested in identifying workarounds and then documenting them in yet another set of secret magic documentation that customers don't have access to.
- It must make it easier for our customers to consume our products. Besides making sure that our public documentation is accurate and useful, we also create supporting materials, in the form of articles, blogs, demo videos, etc.
For example, we maintain a dashboard that contains a usability rating for each component, based on both 'hard' metrics (e.g. number of steps to install, elapsed time, memory/CPU footprint) and 'soft' metrics (e.g. quality of documentation, ease of troubleshooting), with regular improvement reports going to our executive team. We also have a playlist on Youtube with a set of 'how-to' videos, we publish blogs and articles, and we run frequent enablement and support sessions for our field personnel.
As I had mentioned earlier, the Bringup Lab logically sits between the development team and the customer, and provides an outside-in view of our software. To be able to do so, the members of the lab are not placed in the actual development organization. It is an organization of its own, which is important so that it can maintain its independence.
But isn't all this just saying it is a glorified test team? Maybe. I believe the difference lies in the strict customer perspective, the lack of claiming broad testcase coverage (it is a small team, remember?), and the focus on doing cross-functional testing. But it goes without saying that we work very closely with the individual product test teams, comparing notes and making sure that we are not duplicating work, and I think that works very well. There are always more things to test than we have time and people for.
Of course, we are a commercial software vendor, and we are a big vendor, too. So would a Bringup Lab make sense, say, for enterprises that do their own application development? I vote Yes, at least in large organizations where a set of capabilities that have been developed separately need to coexist or even be integrated. And it doesn't need a massive team to have massive impact. And for us - and I admit that I am somewhat biased -, I say it has had significantly improved the quality of our deliverables.
Comments
Post a Comment