KANBAN AT MOBILE.DE Creating the Perfect Process, One Block at a Time - KANBANCASESTUDYSERIES - Kanban University
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
KANBAN AT MOBILE.DE
Creating the Perfect Process,
One Block at a Time
KANBANCASESTUDYSERIES
A pple’s App Store users gave it a one-star rating. The first entry by the online search tool for
buying and selling vehicles, mobile.de, on the portable devices arena 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 flow 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, Epic
visualization of invisible work and the “Do you actually think this is
taking between half a day and two
workflow process. Such transparency enough functionality to release the An-
days to complete, and were releasable
would also help in identifying blockers droid app?”
to the end users. The team’s Kanban
and dealing with them in a timely The derogatory question from the
board had just two columns—planned
manner. business people stung Holger and
and ongoing. They all agreed to spend
“I believed we were capable of caught him unprepared. By 2012 the
five minutes together in front of the
building the mobile applications Android OS had already gained signif-
board every morning. There was an
without too many plans and icant momentum in the marketplace.
additional one-hour planning meeting
documents in advance. I saw these More and more smartphone brands
every week to discuss and roughly
as constraints and overhead, so we were adopting it, and the user base was
prioritize upcoming user stories.
removed them from the start,” Holger substantial. It was the next logical step
In the first year, the focused team
says. for the mobile team, so more develop-
solved many problems such as what
All the communication that is ers were added to the team.
backend engine should drive the future
woven into Kanban—the daily stand- They were given time to learn the
mobile applications and whether or
up meetings, the planning sessions, Android environment while the user
not existing APIs should be part of
and the consequent retrospectives— stories were added to the team’s board.
the framework. The bitter taste of
would give the possibility for quick So, when the team presented what they
the low rankings for the initial iOS
resolution of problems, technological believed was the completed first ver-
app remained, and the backbone
or process related. sion of the Android app to the business
technology had to be impeccable. With
“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 Mobile Web 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
I n 2013, three years after the initial mobile application was created, the mobile team’s developers
have 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.
https://www.kanban.university
© Copyright 2021 Kanban UniversityYou can also read
