At Blossom, we care a lot about workflows and how people interact in order to get a certain task done. We strive to understand what processes are in place at different companies to make Blossom easier to use for everybody involved in a project. This series is intended to show you how different companies approach the software development process and what matters to them. This is the fifth part of the series. If you haven’t read it, check out the first interview with Johannes Nagl from “Die Socialisten” and the other interviews!
THE DEVELOPMENT WORKFLOW OF DriveNow
Henrik Mitsch from DriveNow, a German car-sharing company owned by BMW and Sixt, sat down with me and we talked through their challenges when developing the software behind carsharing and how their development workflow looks like.
DriveNow BMW i3
Please tell us who you are and what you do, Henrik!
Hi, I am Henrik, Head of DriveNow IT at Sixt. My main responsibilities include business/technology alignment, secure stable operations and make sure our software developers have everything they need to make an outstanding job. Before joining Sixt I was a consultant at Accenture, working mainly in the telco industry. This is where my exposure and hands-on experience with Agile in big and small environments started and it is continuing ever since.
Can you tell us a little bit about DriveNow?
DriveNow is premium, flexible car sharing by BMW and Sixt. We operate various MINI and BMW models including the BMW i3. These cars are located via an app, and can pick them up and return anywhere within our business area. This is a very technology-dominated service offering. For this reason, our product and software development teams are closely knit together in order to deliver a high value product.
How is the company and the team you are working with structured?
We are a product organization of approximately 50 people spanning product management, UX, business engineering, software development and DevOps. The team is distributed among two locations and split into several cross-functional entities, each following agile methodologies (Scrum and Kanban).
We observe multiple clock-speeds in our organization. Sometimes features go from ideation to production in a few minutes, in other instances rigorous planning and alignment with third parties might result in a months-long delivery cycle.
In order to stay on top of the many product initiatives which concurrently run through our organization, we use Blossom’s software to manage our “operational release planning”.
Lots of feedback cycles, cross-functional delivery teams and a continuous strive for lean product management principles help us keep an agile spirit along our journey.
How do requirements come to your team and how do they progress through your company?
As DriveNow is a growing business, there are a multitude of entry channels for requirements. About a year ago we have analyzed our value chain and mapped it onto a Kanban board using Blossom. Since then it has been iteratively refined to make sure it maps out our actual flow.
Incoming requirements are captured in an “Alignment required” column. This is the triage point for our product management and business engineering people. We inspect this column at least once per week and together decide on ownership. From there our requirements take a rather standard path: specification, solution architecture, implementation, testing, deployment. Sounds like a waterfall? Not so much! Lots of feedback cycles, cross-functional delivery teams and a continuous strive for lean product management principles help us keep an agile spirit along our journey.
The DriveNow iOS App
What tools (Project Management, Issue Tracker) help you deliver your product and why?
As we have been on the road for a number of years, our tooling landscape is quite diverse.
We are heavily invested in the Atlassian stack for ticketing (Jira Service Desk), development (Jira), requirements wrangling & living documentation (Confluence), and communication & ChatOps (HipChat). Code lives in git with beautiful continuous integration and continuous delivery tooling crafted around it (Hi Jenkins!). Ops tooling is following Etsy’s “if it moves, graph it” philosophy with ELK (Elasticsearch, Logstash, Kibana), Instana and Pingdom at its core.
Finally, ideation and themes are handled in Blossom. We are currently experimenting with the best way to handle our product roadmap and are using OKRs for that matter.
Are there any tools missing from your setup?
Our motto is “people – processes – tools”, in that order. We know that people go first. Next we help them understand value chains and identify appropriate processes. Ultimately, we have a look at supporting tools.
Right now, our team is going through a “norming phase” so we have to evaluate the impact on processes and tooling as we move along.
Do you have a methodology for evaluating the impact of processes and tooling which you are doing right now?
We really like using Mathias Verraes’ “Small Uncontrolled Experiments framework“. The basic idea is: We run an experiment and see how it works after a few days. This is also how we introduced Blossom into our operational release planning process.
The DriveNow Team working in their office in Munich, Germany
When you use the Small Uncontrolled Experiments Framework, how do you evaluate the success of an experiment, especially with tools and processes that might take a longer time to show their real value?
For such cases we rely on an „experiment board“ (i.e. another Kanban board). This is where we keep track of our experiments (Backlog, in progress, done). Such a board allows us to keep track of experiments running longer than our two week sprint.
Agile is hard because it requires you to question yourself every single day (Kaizen), move the conversation from features to purpose (remember Daniel Pink’s Drive), and apply systems thinking to (almost) everything .
How did your development workflow evolve over time?
We have been on the road for more than four years. During this time our product development workflow has evolved substantially. In the early days we were very plan-centric, which certainly was the correct thing in the beginning. Over time, we adopted more and more empirical and lean practices across our entire value chain.
What are your plans to evolve your development workflow in the future, if any?
As our understanding of agile product discovery and delivery matures, our workflow will eventually evolve. OKRs help us to get broader organizational alignment of product goals. This is surely something we will keep iterating on.
The monitoring interface for the DriveNow infrastructure
Thanks! Anything missing you want to point out?
Agile is hard because it requires you to question yourself every single day (Kaizen), move the conversation from features to purpose (remember Daniel Pink’s Drive), and apply systems thinking to (almost) everything . Blossom’s Kanban tool provides us with a beautiful and simple landing base along this slippery slope. Keep it up!
Staying lean is a demanding endeavor, as many organizations know. Putting people first and making sure the whole team keeps agile principles at its core seems to help a lot. This makes moving fast possible and, as DriveNow shows, is also suitable for highly reliable products. Keeping in mind that moving fast doesn’t mean skipping the planning. This is important as well, especially when introducing agile methods into your organization.