KANBAN AT MOBILE.DE Creating the Perfect Process, One Block at a Time

KANBANCASESTUDYSERIES pple’s App Store users gave it a one-star rating. The first entry by the online search tool for Abuying and selling vehicles, mobile.de, on the portable devices was not receiving a standing ovation by any means. Ralf Tomczak, mobile.de’s CTO, stood in disbelief as he saw how many downloads were followed by user reviews far below the top score of five. “We knew our first mobile application could be better, but we never expected the users to be that harsh,” he says. The year was 2010; iOS application downloads had reached the billion mark, and users were already being spoiled by a growing talent force equipped to make their mobile experience fulfilling and meaningful. Mediocre applications were not simply being criticized; they were also tarnishing the images of the companies that released them. A mid-September Friday in 2013 is Holger Hammel’s last day as Development Manager of the mobile development team for mobile.de. He is moving on to his next assignment within the parent company, eBay Inc., leaving behind three mobile applications and a mobile version of mobile.de. The rewritten iOS app now has an average ranking of 4.5 stars. The team has created iPad and Android apps and a mobile website portal. The site carries an app-like look and feel and generates roughly 35 percent of the overall traffic for the service. This is the story of how Holger and his team turned the odds with the help of the Kanban Method and Lean Thinking. In just two years they have managed to put the applications at the top of the mobile rankings for Germany.

Background Facing a major reengineering, of visualizing the knowledge work and mobile.de was advised by the German instituting process changes to make it Holger first started working for the consulting company IT-Agile to more smoothly—both on the team Berlin-based company mobile.de in adopt emerging Agile practices such level and on the portfolio-management 2007 as a freelance developer, and he as Scrum1. At the time, companies level—were successfully implemented. later accepted a permanent position. worldwide were reporting improved By 2010, with an already The Internet platform hosts more delivery rates for software and reengineered browser experience, than a million offers for vehicles from significantly greater commitment from Ralf and the rest of the senior-level both private owners and dealers. team members through the increased managers decided to pursue the mobile Used primarily in Germany, as well involvement and empowerment such domain and extend the company’s as in many other Central and Eastern Agile practices provide. services in that direction. At the European countries, it receives up to Scrum helped the teams become time, it made more sense to hire 2,000 queries a second. more effcient, but a few things seemed an experienced external agency to The business was established in to be missing in the new Agile reality: produce the application rather than 1996 and was acquired by the giant the flow of ideas, a picture of all build a team from in-house developers, eBay Inc. in 2004. Soon after the ongoing projects, and the important as they would have had to learn the acquisition, the company grew and had combination of both a viable plan and platform first. to scale up to meet the consequences predictable feature delivery. In 2010, Apple’s iPhone and its of increased user demand, as well as In the search for something that mobile App Store were far more deal with the side effects of having a could address all of these, Kanban advanced than any others in the bigger team. The development teams Method practices were introduced on market, so the choice to go for the iOS realized as they faced these challenges top of Scrum in the following years. platform was obvious. that something in their process had to With time and the help of the external “We had objections toward the change. coaches from IT-Agile, the practices visuals and user experience of the

– 2 – realize how weak the underlying During this time, Holger was a tickets per column, people present at technology of the proposed application software engineer on another team. or moderating those daily meetings— was,” Ralf recalls. Through the years he had developed nothing was ever a constant. He Experienced mobile users, curious a particular interest in the Kanban loved the idea of such freedom. His and enthusiastic for the product, Method. While he was on a Scrum colleagues told him that with each quickly found an array of glitches in team he noticed other teams that change the process became better. the app. Ralf soon realized that no visualized their work on whiteboards He was particularly interested in shortcuts were allowed in mobile. referred to as Kanban boards. seeing that even to an outsider like “Seven million people use mobile. Those boards were divided him, all these things seemed easy to de. We had to face the fact that many into columns that represented the spot. It was the inherent transparency of them were now wanting to look for individual process steps that a piece of that Kanban provided that gave such their next car on their mobile devices. work underwent from input and ready- detailed insight. If we wanted them to continue using for-development to deployment and He began reading more about the mobile.de, we had to provide a smooth release. The work items were written Kanban Method and became fascinated experience for that,” Ralf says. on colored post-it notes and put on the with another aspect of it: Some argued The mobile application needed to board. that estimating delivery time might not carry the spirit and philosophy that Holger saw his colleagues on the be necessary. Delivering features in a made mobile.de so popular. Internal other teams attend stand-up meetings reliable and constant flow seemed to developers knew best how to do that. every morning. He overheard them be much more vital than estimating. Learning and adapting to the mobile discussing tickets, especially the ones How much time that actually took was environment was the easier part of the that were not moving along the board a matter of measuring the progress equation. as easily as others. of tasks in real time. He had tried to “We figured out that the only chance Holger paid attention and saw convince his team leads to try the for a good mobile application to pop something particularly interesting: approach, but they never agreed, up was if a team was created and Nothing in the process stayed the same, thinking that it interfered with the nurtured in its own space with only and over time, many things changed. underlying principles of Scrum. that priority in mind,” Ralf explains. Names of the columns, numbers of

– 3 – The Beginning Such an approach had its risks. “It might have taken us less time if Holger and the team were ready to we had selected an existing framework The mobile development team take responsibility for those risks. The and made it work for us. We all shared was established in 2011. Holger was question was, would the managers high expectations that the user base assigned as the Team Lead. Initially above agree? would grow exponentially. Without there were two developers, a Quality Projects in mobile.de were usually a tailor-made backbone to meet Assurance engineer, and a Product executed with clear milestones and that, chances were that the servers Owner. accountability for the investment of would crash and annoy users,” Holger “We were all very experienced in resources. Previous Kanban Method explains. building a high-traffic e-commerce adoptions had improved delivery, but Within a few months the backend website, but we knew little about how they came on top of existing release was built. to do mobile applications, and it was plans and processes. The mobile With the help of external developers certain we would run into pitfalls and team was the first ever to start from from IT-Agile, the team tried to salvage issues along the way where the answer scratch with Kanban; they insisted the iOS app. They realized it had to be could not be found in the codebase. We on no iterations, no estimations, and rebuilt from scratch to make it user- might have had to spend the first few no deadlines, just a constant flow of friendly, stable, and maintainable in the months outlining ideas and preparing a communication, learning, and delivery. long run. solution, but such preparation felt like “It did require a leap of faith that Part of the team took on rewriting a complete waste,” Holger says. this team, with no track record, would the iOS app and a little over a year The project had strategic value for succeed from the start, without metrics after the team was first assembled, the company, not only in economic to hold them accountable, using just a many iPhones owner in Germany had terms, but also in terms of proving Kanban board,” Ralf says. a much better way to look for their mobile.de’s ability to be an innovative The team made a commitment to next car. But the endeavour was far and fast-moving company. The team experiment with various solutions from over: a new mobile platform was had to start developing immediately. to each of the design and software growing hungry for apps. To ensure their endeavor, they architecture problems they came across decided to rely on the Kanban Method. until they found the best solution. They believed the right process would To help the flow and reliability, The Android App and the stem from the help of transparency— individual work items were small, visualization of invisible work and the taking between half a day and two “Do you actually think this is workflow process. Such transparency days to complete, and were releasable enough functionality to release the An- would also help in identifying blockers to the end users. The team’s Kanban droid app?” and dealing with them in a timely board had just two columns—planned The derogatory question from the manner. and ongoing. They all agreed to spend business people stung Holger and “I believed we were capable of five minutes together in front of the caught him unprepared. By 2012 the building the mobile applications board every morning. There was an Android OS had already gained signif- without too many plans and additional one-hour planning meeting icant momentum in the marketplace. documents in advance. I saw these every week to discuss and roughly More and more smartphone brands as constraints and overhead, so we prioritize upcoming user stories. were adopting it, and the user base was removed them from the start,” Holger In the first year, the focused team substantial. It was the next logical step says. solved many problems such as what for the mobile team, so more develop- All the communication that is backend engine should drive the future ers were added to the team. woven into Kanban—the daily stand- mobile applications and whether or They were given time to learn the up meetings, the planning sessions, not existing APIs should be part of Android environment while the user and the consequent retrospectives— the framework. The bitter taste of stories were added to the team’s board. would give the possibility for quick the low rankings for the initial iOS So, when the team presented what they resolution of problems, technological app remained, and the backbone believed was the completed first ver- or process related. technology had to be impeccable. With sion of the Android app to the business “This was our chance to experiment such a small team, it was easy to have people, they were taken aback by the with Kanban and we took it,” Holger focus, discussion, and consequent negative reaction and dissatisfaction. says. resolution. In the case of the backend “But you could observe what we technology, the choice was obvious. were building all along and you never

– 4 – said anything to indicate it was not More meetings or definitive It represented a bundle of features, enough,” Holger replied. plans were certainly not the answer all connected by a common idea, and From the very beginning, the team in an industry where technology was named such that everyone could tried to avoid the label “project.” A developments changed constantly. To understand what it was and what to project meant plans, documents, find a resolution, Holger went to the expect of it. and expectations, all of which was one place that he believed held the When formulating an Epic, the unnecessary waste in a system whose answer— the Kanban board. team tried to make sure that building main goal, after all, was to create a He looked at the columns, he it would not take more than two or working mobile application. They looked at the colorful array of sticky three weeks. The user stories within it believed that a user story on a ticket notes arrayed in those columns, and would still be in a developer’s language, gave the “who,” “what,” and “why” of he wondered about the answer. He such as “Input field for first registration a requirement in a simple and concise remembered how he had looked at date,” but the Epic would be called way and that it ought to be clear to other teams’ Kanban boards, studying something like “Create form to insert everyone. No additional layer of them with curiosity. And then it a car by private clients,” which was organization was necessary. occurred to him. What the team was language universally understood by Now, for the first time, they began to working on was there; nothing was anyone at the firm. doubt their assumptions. The team was hidden, but it was not graspable to an “Initially, we did it to help coming across a blockage in the system outsider. management understand what we were that was not the usual pink ticket, like a User stories alone were small doing, but with time, the Epic helped missing requirement. The problem was enough to create the sort of constant our thinking on how to drive demand,” bigger, and they wondered if the team’s flow he had wanted all along, but they Holger says. isolation from their internal clients were not big enough for someone Eventually, the Epics also proved a had something to do with it. In their outside to get a big picture of what the way for the team to control their work- detachment from the business people, team was working on. In his drive for in-progress and multitasking—the the team had lost one of its main flow and freedom of process he had rule was that a developer should be sources of validation that what they are sacrificed context. involved with user stories only in the doing was right. The team never stood a chance context of one Epic. After some discussion, a new to receive timely feedback on key The Epic, in addition, became definition of the Android app’s first functionalities for the Android app, a success and validation metric version was cleared. The necessary or for anything else for that matter, and a way to evaluate the return additional functionalities were turned because the business stake-holders on investment, as it represented a into user stories, which were written on didn’t understand what was going on. foreseeable addition to the product. sticky notes. Everyone wanted to make Soon after, the notion of an “Epic” sure that such misunderstandings was introduced and a place for it was didn’t occur in the future. designated on the board (Figure 1).

– 5 – Figure 1 - The column designated for Epic tickets. Once a ticket is here, it has to be split into user stories or have the already collected user stories visually associated with it. The next time the Epic ticket moves is when all of its user stories are completed; then the Epic goes up for Validation.

Torsten and the Vision Fighting the urge to break that rule was and features in development was not as difficult,” Torsten says. easy to follow as it once was. Without “You should feel the pain of the Torsten’s previous experience stood the larger picture, dealing with problem and work to resolve it.” in the way of adapting to the principle blockages first hand was becoming That piece of direction marked the of not leaving any tasks behind. harder, too. As good as it had sounded first few months of Torsten’s tenure Coming from a world that used the just to develop in a flow, Epic after at mobile.de. A front-end developer, traditional software development Epic, people needed a sense of he was the first who specialized in lifecycle (SDLC) model, he was used to direction and of what to expect to feed developing for mobile to start work on a phase-gate approach to progressing their motivation. the mobile team. through the lifecycle stages of a Holger went again to the place “I came from advertising agencies product: First, the entire framework where the answers lay—the Kanban and startups and had been used to would be finished, then the whole UI; board. The issue was addressed during the notion of just being productive. afterward, all the functionalities would a team meeting. If something blocked my current be added, and in the end, all of this “What do we need to do to assignment, I always put it aside and would be merged with the backend. improve?” he asked. “It would help if moved to the next thing on the to-do “At mobile.de, my teammates and I we had the perspective of where we are list,” Torsten says. would work on a single functionality, going, side by side with the Epics and That naturally had resulted in a habit ensuring it worked on its own, before the user stories,” they agreed. moving to the next. In the big scheme Soon after, the Vision—a higher- of working on multiple tasks at once, of things, it did not make much sense, level, concept-phase column—was some of which were forgotten in the especially when I had to focus on a introduced. haze of heated activity. single user story even when it was By that time the team already had “During the first months I found it blocked,” Torsten recalls. a third domain where it focuses its really hard to focus on one user story As the mobile team scaled up, the attention: the browser. only, especially when it was blocked. overview of the various applications Each of those domains had a different

– 6 – vision because it was at a different stage The Vision helped Torsten stick with functionality after functionality, made of its development, it became evident a user story, but so did the constant the applications more stable in the long the common board had to be split into communication. run. three separate Kanban boards. The iOS “I never felt left alone with the Due to the fragile nature of mobile (Figure 2), Android (Figure 3), and struggle of a blockage. We solved applications and websites, Torsten had Mobile Web (Figure 4) boards all had a blocks together, discussing them in often been frustrated with products Vision Ongoing column that served as meetings. I developed a responsibility crashing after changing and refactoring a preplanning phase. to show progress the next morning the code base. By that time, the team already had to the same people who had helped “When I knew that I could add a its first product owner, who defined me with my problem the day before,” feature without the chances of breaking the creation of the Vision as his ter- Torsten says. the product, I felt more compelled to ritory. Only Epic-sized tickets were As he slowly changed habits, finish it, even if I was blocked,” Torsten put in the Vision Ongoing column, he realized that with the Kanban says. and after careful evaluation from the system he saw the fruits of his work product owner, these were moved to much sooner. He did not have to Vision Done. From there they would wait six months for a product to be moved to the Epic column when a be completed fully and delivered. slot opened up. Building the product in this leaner way,

Figure 2 - The iOS team’s board.

– 7 – Figure 3 - The Android team’s Kanban board.

Figure 4 -The Mobile web platform’s Kanban board.

– 8 – The QA and the During consequent retrospectives, responsibility for the quality of the the team began to reevaluate the code from the developers themselves. Retrospective notion of shufflng work to the one QA Whenever developers were unable “We have always had this issue— guy. How fair was that? The developers to perform a test, they proactively more developers than Quality were the original writers and creators collaborated with testers from other Assurance engineers. When the ratio of code, so how could they help resolve teams. This evolutionary change of the became twelve to one, we were in this bottleneck? As the team pondered QA’s role helped to return the flow to trouble.” Holger says. on these questions, they agreed that where it had been previously. Although development had something drastic had to change. In hindsight, the retrospective increased substantially, the mobile And it did—little by little, Harald, meetings resolved many other team still remained with just one QA the Quality Assurance engineer, began glitches the mobile teams faced. The engineer. As the team scaled, testing to consult with the team about how daily stand-up meeting’s quality had and quality assurance was on the verge they themselves could test more and deteriorated when the team scaled of becoming a serious bottleneck. therefore need less actual QA testing. up. Without set policies, it often was Developers were used to handing in He established practices for the team to chaotic and unfocused, oftentimes their user stories to QA for testing, be able to test their own work. shifting to non-development-related but soon the flow was disrupted and “Test cases2 are not something matters. the team could no longer achieve the that I as a front-end developer could After the problems with ineffective continuous deployment they desired. create. I do not know the appropriate daily meetings were escalated during The question was whether to push for programing language. But what numerous retrospectives, new rules more QA engineers so they could go our QA did was to come up with were put in place. The only people who on the way they had been working frameworks that made writing a test were allowed to speak during the daily before, or to make some other kind of very easy. Running them, I could see were the developers. Questions from change. immediately whether I had engineered “We sat down during a retrospective my user story well.” Torsten says. other participants such as the product and talked about our understanding of Manual testing sessions were owner, Holger, or anybody else had to the QA role,” Holger says. established, during which developers be taken privately afterward. Retrospectives had proven to be a from one team tested the stories valuable source for addressing issues of another. Furthermore, the QA that hindered the team. They got consultant was motivated to look for people to think about the problems and innovative, automated ways of testing. come up with solutions. With time, something else developed as well—the sense of

2A test case represents a set of conditions or variables under which a tester will determine whether his or her work item is functioning as it was origi- nally intended. Its components describe an input, an action or event, and an expected response, will help to determine if a feature of an application is working correctly.

– 9 – Figure 5 - The Epic ticket for the iOS 7 version of the application is already on the iOS team’s board.

The Lean Experiment and something as minimal as possible that four iterations and each time presented can still function as a viable product, or an improved version based on the the Café Tests a minimum viable product (MVP), as feedback they had received from the “The next project should be an iOS it is known. previous iteration. app for mobile.de car dealers,” the This MVP should be taken out After two days, a click dummy was business people said one day. into the field for testing with example created. After a few more iterations It was February 2013 and the team target customers, even if the product and some pivots, it became clear that was skeptical that the need existed. has many defects. The purpose of the they had found valuable features, but At that time, the mobile development test is to see whether these target users that most likely the business model team already had an iOS app for find the application interesting and would not work. In those four days, all iPhone and iPad, as well as Android valuable. participants received so much valuable apps in German and in English. Instead of arguing with his feedback about the existing application “We are sure the dealers need a colleagues from the business side, the that they came back to Berlin with a service to help them keep track of product development department bagful of user stories. inventory,” the argument went. cleared some budget and time for Inspired by this experience, team By that time two-thirds of all car a field trip to Frankfurt to test the members Lars and Max (product dealers in Germany were active users proposed new application and validate owner and interaction architect, of mobile.de. The mobile team’s process the business model. respectively) set up lean and frequent had smoothed out to a large extent, A group of user experience validation experiments. and Holger had more time to focus on (UX) experts, product owners, and For instance, once a week Max takes non-process-related issues. developers volunteered to do the his laptop and works from cafes around Reading a copy of The Lean Startup,3 experiment. Spending just four Berlin. He talks to strangers there which he and all of his colleagues days and starting off with a paper and asks them to play around with a were given by mobile.de, was one prototype, the five explorers visited prototype. The quick user feedback, such thing. He was fascinated with the car dealers’ capital. They knew this proper metrics, and consistent the argument for early validation of timeframe would be enough for the validation of features fundamentally the hypothesis of customer needs. The necessary iterations to create the MVP changed the way the team develops process to do that was simple—build on the spot. They split each day into their products.

3 Ries, Eric. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. New York: Crown Busi- ness, 2011.

– 10 – Conclusion

n 2013, three years after the initial mobile application was created, the mobile team’s developers Ihave learned not only the technology of mobile, but they can now focus on experimenting with their ideas and seeing users’ reactions. Developing what people want has become the driving force in the ideation phase of their process. The flat design of iOS 7 is one of their next challenges. “We want to find out if we can design the new, flat look of our application iteratively, rather than as a full redesign that we release as a big bang. This will create a visual inconsistency, which users may not tolerate for some time, but it will give us an early idea of what users want to see and use. The risk is worth pursuing,” Ralf says. He has learned the lesson from three years ago, and he wants to make sure that the new mobile.de iOS 7 application is an exquisite actor on the mobile stage where nowadays almost a million other applications seek time and attention from mobile users. He feels safe because by now he knows very well what to expect from the team. With the Kanban Method’s principles and practices in place with the mobile team, the next great feature is just a few experiments away.

About Kanban University Kanban University works to assure the highest quality coaching and certified training in Kanban for knowledge work and service work worldwide. Our Accredited Kanban Trainers™ and Kanban Coaching Professionals™ follow the Kanban Method for evolutionary organizational change. Kanban University offers accreditation for Kanban trainers, a professional designation for Kanban coaches, and certification for Kanban practitioners.

://www.kanban.university

© Copyright 2021 Kanban University