Pipeline Evolution: from Three Pipelines to One MVP
When customers come to us for help with their digital transformation we start the process with a simple message: “We can do everything you are asking us to do.” However, as we go through the pre-sales process and start defining what the customer actually needs, what we deliver is often quite different from their original expectation. Different teams have different needs - but more often they have very similar needs but don’t know it. And sometimes they really don’t know what they need beyond the ability to release software without the anxiety. So what is the process of getting the customer from point A to point Z in their journey to releasing software on business demand? A minimum viable pipeline (MVP) - one that lets then onboard the vast majority of their applications in the shortest amount of time but give them the flexibility adapt or refactor that pipeline as their needs change. Following is a prime example of the evolution of the conversations we recently had with a very large hotel chain. Please keep in mind that not every customer is the same. In reality, however, they are all the same: they all have their own variations and challenges, but most will fall into this same way of thinking.
Three Teams, Three Pipelines
Running a pre-implementation workshop is a key function of our Professional Services organization. The workshop isolates the proof of concept details from the reality of implementation of the solution. The workshop is designed to extricate additional information from the customer and figure out what the “go-live” strategy is. Ultimately, to be successful, we want our solution thriving in Production. When we first started mapping out their pipeline requirements we ended up with three different pipelines — and that was just the beginning! The images below show that these pipelines were designed purely from conversations with the different teams. In this case, we started off with the first team and the first identified application, “GTP (Go to Production) App 1,” which resulted in the following pipeline. As you can see, while rudimentary, it was a good starting point. Not only did it generate conversation amongst the team, but it also stimulated some heated arguments when team members couldn’t see eye-to-eye.
The second pipeline we discussed was for their CRM (backend technologies). The workflow wasn’t much different, but that particular team was insistent that it was significantly different from the others and therefore needed its own pipeline. Extracting such information, is challenging but is key to understanding the significant differences and needs of that group. Everyone keeping an open mind is the best way to get through this often-contentious step.
The third pipeline we wanted to help develop was for their Mobile Systems. Interestingly enough, the Mobile Systems group had no experience with a pipeline nor how to get the application “instantiated” into CloudBees Flow. Their pipeline diagram was nothing more than discussion points. Team members not knowing why they are there or what their product does is not uncommon when we start an implementation.
The Evolution Begins
Thus began the process of re-educating all the teams and evolving the pipeline. We expected the development of these pipelines to be interesting, if nothing else, but we knew we had to start somewhere. Because the customer was unclear about where to start, we realized from Day 1 that, despite the on-going conversations and fleshing out most of the technical detail, trying to develop multiple pipelines in tandem or attempting to develop a single pipeline (MVP) was going to be difficult.
We started out the implementation by recommending an MVP. This approach helped the team (both CloudBees and the customer) start looking at a more cohesive approach to creating one pipeline that would cater to 80-85% of the applications. There will always be edge-cases so we planned on handling those later as the customer’s team built their expertise with CloudBees Flow. The quick win here was to start off by recreating an existing Jenkins pipeline that catered to the bulk of their applications. This was a great starting point because it dealt with the typical build—>publish—>deploy—>test methodology. What we had to do was insert the “cool” things that CloudBees Flow does in between. Below is the Jenkins pipeline that was initially modeled out.
Following that initial design, the customer decided it was essential to get a proper workflow in place so that the application lead could explain to his peers and app-dev teams what the pipeline was doing. As you can see, this made it easy to design the MVP for the three stages, INT (INTegration), STAGE, and PROD. In short, this is what you need to create that MVP.
The coolest thing about this whole process was that their team is the one that started the MVP design — not us. The integrations included, but were not limited to:
- Service Now
- CA Agile Central (Rally).
The integrations had already been identified and were being worked on by the CloudBees team. It was up to the customer to come up with the MVP.
Three Teams, One Minimum Viable Pipeline
The image below highlights the first version (1.0) of that MVP. It satisfies the customer’s initial implementation plans for all three applications and places them on the path to get over 100+ apps on-boarded by the end of 2019.
The Moral of the Story
The MVP is a concept and solution that has delivered a high rate of success at customers of all sizes, because it:
- Provides a roadmap for the customer to start on the path of proper pipeline development.
- Enables customers to see “the big picture” from the onset.
- Gives implementation teams a common, pre-agreed goal to work towards as well as a great starting point.
- Reduces the churn of multi-use-case development that can take up so much time and waste so many cycles during an implementation cycle.
————————————————————————————————————————————————————— Stay tuned for similar stories. You can also subscribe to our blog and get updated on the latest news from CloudBees here.