KANBAN AT MOBILE.DE Creating the Perfect Process, One Block at a Time - KANBANCASESTUDYSERIES
←
→
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.
-2-
Background
Holger first started working Kanban Method practices were the iOS platform was obvious.
for the Berlin-based company introduced on top of Scrum in the “We had objections toward
mobile.de in 2007 as a freelance following years. With time and the visuals and user experience of
developer, and he later accepted a the help of the external coaches the product the agency delivered,
permanent position. from IT-Agile, the practices of but we decided to introduce it to
The Internet platform hosts visualizing the knowledge work Apple’s App Store anyway. We
more than a million offers for and instituting process changes wanted to see if there would be
vehicles from both private owners to make it flow more smoothly— interest, but we didn’t realize how
and dealers. Used primarily in both on the team level and on the weak the underlying technology
Germany, as well as in many other portfolio-management level— of the proposed application was,”
Central and Eastern European were successfully implemented. Ralf recalls.
countries, it receives up to 2,000 By 2010, with an already Experienced mobile users,
queries a second. reengineered browser experience, curious and enthusiastic for the
The business was established Ralf and the rest of the senior- product, quickly found an array
in 1996 and was acquired by the level managers decided to pursue of glitches in the app. Ralf soon
giant eBay Inc. in 2004. Soon the mobile domain and extend realized that no shortcuts were
after the acquisition, the company the company’s services in that allowed in mobile.
grew and had to scale up to meet direction. At the time, it made “Seven million people use
the consequences of increased more sense to hire an experienced mobile.de. We had to face the
user demand, as well as deal external agency to produce the fact that many of them were now
with the side effects of having a application rather than build a wanting to look for their next car
bigger team. The development team from in-house developers, as on their mobile devices. If we
teams realized as they faced these they would have had to learn the wanted them to continue using
challenges that something in their platform first. mobile.de, we had to provide a
process had to change. In 2010, Apple’s iPhone and smooth experience for that,” Ralf
Facing a major reengineering, its mobile App Store were far says.
mobile.de was advised by the more advanced than any others in The mobile application needed
German consulting company the market, so the choice to go for to carry the spirit and philosophy
IT-Agile to adopt emerging Agile
practices such as Scrum1. At the
time, companies worldwide were
reporting improved delivery rates
for software and significantly
greater commitment from team
members through the increased
involvement and empowerment
such Agile practices provide.
Scrum helped the teams
become more effcient, but a few
things seemed to be missing in
the new Agile reality: the flow
of ideas, a picture of all ongoing
projects, and the important
combination of both a viable plan
and predictable feature delivery.
In the search for something
that could address all of these,
1
Scrum is an agile software development model based on multiple small teams working in an intensive and inter- dependent
manner. There are a few defined roles, such as product owner and Scrum master, and all the teams have to work in set timeframes,
or iterations.
-3-
that made mobile.de so popular. transparency that Kanban process would stem from the help
Internal developers knew provided that gave such detailed of transparency—visualization of
best how to do that. Learning insight. invisible work and the workflow
and adapting to the mobile He began reading more about process. Such transparency would
environment was the easier part of the Kanban Method and became also help in identifying blockers
the equation. fascinated with another aspect of and dealing with them in a timely
“We figured out that the it: Some argued that estimating manner.
only chance for a good mobile delivery time might not be “I believed we were capable of
application to pop up was if a necessary. Delivering features building the mobile applications
team was created and nurtured in a reliable and constant flow without too many plans and
in its own space with only that seemed to be much more vital documents in advance. I saw these
priority in mind,” Ralf explains. than estimating. How much time as constraints and overhead, so
During this time, Holger was that actually took was a matter we removed them from the start,”
a software engineer on another of measuring the progress of Holger says.
team. Through the years he had tasks in real time. He had tried to All the communication that
developed a particular interest in convince his team leads to try the is woven into Kanban—the daily
the Kanban Method. While he was approach, but they never agreed, stand-up meetings, the planning
on a Scrum team he noticed other thinking that it interfered with the sessions, and the consequent
teams that visualized their work underlying principles of Scrum. retrospectives—would give the
on whiteboards referred to as possibility for quick resolution
Kanban boards. of problems, technological or
Those boards were divided The Beginning process related.
into columns that represented “This was our chance to
the individual process steps that The mobile development experiment with Kanban and we
a piece of work underwent from team was established in 2011. took it,” Holger says.
input and ready-for-development Holger was assigned as the Team Such an approach had its risks.
to deployment and release. The Lead. Initially there were two Holger and the team were ready
work items were written on developers, a Quality Assurance to take responsibility for those
colored post-it notes and put on engineer, and a Product Owner. risks. The question was, would the
the board. “We were all very experienced managers above agree?
Holger saw his colleagues in building a high-traffic Projects in mobile.de were
on the other teams attend stand- e-commerce website, but we knew usually executed with clear
up meetings every morning. He little about how to do mobile milestones and accountability
overheard them discussing tickets, applications, and it was certain for the investment of resources.
especially the ones that were not we would run into pitfalls and Previous Kanban Method
moving along the board as easily issues along the way where the adoptions had improved delivery,
as others. answer could not be found in the but they came on top of existing
Holger paid attention and saw codebase. We might have had release plans and processes. The
something particularly interesting: to spend the first few months mobile team was the first ever to
Nothing in the process stayed the outlining ideas and preparing a start from scratch with Kanban;
same, and over time, many things solution, but such preparation felt they insisted on no iterations, no
changed. Names of the columns, like a complete waste,” Holger estimations, and no deadlines, just
numbers of tickets per column, says. a constant flow of communication,
people present at or moderating The project had strategic learning, and delivery.
those daily meetings—nothing value for the company, not only in “It did require a leap of faith
was ever a constant. He loved economic terms, but also in terms that this team, with no track
the idea of such freedom. His of proving mobile.de’s ability to record, would succeed from the
colleagues told him that with each be an innovative and fast-moving start, without metrics to hold them
change the process became better. company. The team had to start accountable, using just a Kanban
He was particularly interested developing immediately. board,” Ralf says.
in seeing that even to an outsider To ensure their endeavor, they The team made a commitment
like him, all these things seemed decided to rely on the Kanban to experiment with various
easy to spot. It was the inherent Method. They believed the right solutions to each of the design and
-4-
software architecture problems and consequent resolution. In the over: a new mobile platform was
they came across until they found case of the backend technology, growing hungry for apps.
the best solution. the choice was obvious.
To help the flow and “It might have taken us
reliability, individual work items less time if we had selected an The Android
were small, taking between half existing framework and made
a day and two days to complete, it work for us. We all shared App and the
and were releasable to the end high expectations that the user
users. The team’s Kanban board base would grow exponentially. Epic
had just two columns—planned Without a tailor-made backbone
and ongoing. They all agreed to to meet that, chances were that the “Do you actually think this is
spend five minutes together in servers would crash and annoy enough functionality to release the
front of the board every morning. users,” Holger explains. Android app?”
There was an additional one-hour Within a few months the The derogatory question from
planning meeting every week to backend was built. the business people stung Holger
discuss and roughly prioritize With the help of external and caught him unprepared. By
upcoming user stories. developers from IT-Agile, the 2012 the Android OS had already
In the first year, the focused team tried to salvage the iOS app. gained significant momentum
team solved many problems They realized it had to be rebuilt in the marketplace. More and
such as what backend engine from scratch to make it user- more smartphone brands were
should drive the future mobile friendly, stable, and maintainable adopting it, and the user base was
applications and whether or not in the long run. substantial. It was the next logical
existing APIs should be part of the Part of the team took on step for the mobile team, so more
framework. The bitter taste of the rewriting the iOS app and a little developers were added to the
low rankings for the initial iOS over a year after the team was first team.
app remained, and the backbone assembled, many iPhones owners They were given time to learn
technology had to be impeccable. in Germany had a much better the Android environment while
With such a small team, it was way to look for their next car. the user stories were added to the
easy to have focus, discussion, But the endeavour was far from team’s board. So, when the team
-5-
presented what they believed was The team was coming across a he believed held the answer— the
the completed first version of blockage in the system that was Kanban board.
the Android app to the business not the usual pink ticket, like a He looked at the columns,
people, they were taken aback missing requirement. The problem he looked at the colorful array
by the negative reaction and was bigger, and they wondered of sticky notes arrayed in those
dissatisfaction. if the team’s isolation from their columns, and he wondered about
“But you could observe internal clients had something to the answer. He remembered
what we were building all along do with it. In their detachment how he had looked at other
and you never said anything from the business people, the team teams’ Kanban boards, studying
to indicate it was not enough,” had lost one of its main sources them with curiosity. And then
Holger replied. of validation that what they are it occurred to him. What the
From the very beginning, doing was right. team was working on was there;
the team tried to avoid the label After some discussion, a nothing was hidden, but it was not
“project.” A project meant plans, new definition of the Android graspable to an outsider.
documents, and expectations, all app’s first version was cleared. User stories alone were
of which was unnecessary waste The necessary additional small enough to create the sort
in a system whose main goal, functionalities were turned of constant flow he had wanted
after all, was to create a working into user stories, which were all along, but they were not big
mobile application. They believed written on sticky notes. Everyone enough for someone outside to get
that a user story on a ticket gave wanted to make sure that such a big picture of what the team was
the “who,” “what,” and “why” of misunderstandings didn’t occur in working on. In his drive for flow
a requirement in a simple and the future. and freedom of process he had
concise way and that it ought More meetings or definitive sacrificed context.
to be clear to everyone. No plans were certainly not the The team never stood a chance
additional layer of organization answer in an industry where to receive timely feedback on key
was necessary. technology developments changed functionalities for the Android
Now, for the first time, they constantly. To find a resolution, app, or for anything else for that
began to doubt their assumptions. Holger went to the one place that matter, because the business stake-
-6-
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.
holders didn’t understand what we were doing, but with time, the the first few months of Torsten’s
was going on. Epic helped our thinking on how tenure at mobile.de. A front-end
Soon after, the notion of an to drive demand,” Holger says. developer, he was the first who
“Epic” was introduced and a Eventually, the Epics also specialized in developing for
place for it was designated on the proved a way for the team to mobile to start work on the mobile
board (Figure 1). It represented a control their work-in-progress and team.
bundle of features, all connected multitasking—the rule was that a “I came from advertising
by a common idea, and was developer should be involved with agencies and startups and had
named such that everyone could user stories only in the context of been used to the notion of just
understand what it was and what one Epic. being productive. If something
to expect of it. The Epic, in addition, became blocked my current assignment, I
When formulating an Epic, a success and validation metric always put it aside and moved to
the team tried to make sure that and a way to evaluate the return the next thing on the to-do list,”
building it would not take more on investment, as it represented Torsten says.
than two or three weeks. The user a foreseeable addition to the That naturally had resulted
stories within it would still be in product. in a habit of working on multiple
a developer’s language, such as tasks at once, some of which were
“Input field for first registration Torsten and the forgotten in the haze of heated
date,” but the Epic would be called activity.
something like “Create form to Vision “During the first months I
insert a car by private clients,” found it really hard to focus on
which was language universally “You should feel the pain of one user story only, especially
understood by anyone at the firm. the problem and work to resolve when it was blocked. Fighting
“Initially, we did it to help it.” the urge to break that rule was
management understand what That piece of direction marked difficult,” Torsten says.
-7-
Torsten’s previous experience development was not as easy to it was at a different stage of its
stood in the way of adapting to the follow as it once was. Without development, it became evident
principle of not leaving any tasks the larger picture, dealing the common board had to be split
behind. Coming from a world with blockages first hand was into three separate Kanban boards.
that used the traditional software becoming harder, too. As good The iOS (Figure 2), Android
development lifecycle (SDLC) as it had sounded just to develop (Figure 3), and Mobile Web
model, he was used to a phase- in a flow, Epic after Epic, people (Figure 4) boards all had a Vision
gate approach to progressing needed a sense of direction and Ongoing column that served as a
through the lifecycle stages of what to expect to feed their preplanning phase.
of a product: First, the entire motivation. By that time, the team already
framework would be finished, Holger went again to the had its first product owner, who
then the whole UI; afterward, place where the answers lay—the defined the creation of the Vision
all the functionalities would Kanban board. The issue was as his territory. Only Epic-sized
be added, and in the end, all of addressed during a team meeting. tickets were put in the Vision
this would be merged with the “What do we need to do to Ongoing column, and after careful
backend. improve?” he asked. “It would evaluation from the product
“At mobile.de, my teammates help if we had the perspective owner, these were moved to
and I would work on a single of where we are going, side by Vision Done. From there they
functionality, ensuring it worked side with the Epics and the user would be moved to the Epic
on its own, before moving to the stories,” they agreed. column when a slot opened up.
next. In the big scheme of things, Soon after, the Vision—a The Vision helped Torsten
it did not make much sense, higher-level, concept-phase stick with a user story, but so did
especially when I had to focus on column—was introduced. By the constant communication.
a single user story even when it that time the team already had “I never felt left alone with
was blocked,” Torsten recalls. a third domain where it focuses the struggle of a blockage. We
As the mobile team scaled its attention: the Mobile Web solved blocks together, discussing
up, the overview of the various browser. Each of those domains them in meetings. I developed a
applications and features in had a different vision because responsibility to show progress
Figure 2 - The iOS team’s board
-8-Figure 3 - The Android team’s Kanban board
Figure 4 -The Mobile web platform’s Kanban board
-9-the next morning to the same desired. The question was whether was motivated to look for
people who had helped me with to push for more QA engineers so innovative, automated ways of
my problem the day before,” they could go on the way they had testing.
Torsten says. been working before, or to make With time, something else
As he slowly changed habits, some other kind of change. developed as well—the sense
he realized that with the Kanban “We sat down during a of responsibility for the quality
system he saw the fruits of his retrospective and talked about our of the code from the developers
work much sooner. He did not understanding of the QA role,” themselves. Whenever developers
have to wait six months for a Holger says. were unable to perform a test,
product to be completed fully and Retrospectives had proven they proactively collaborated with
delivered. Building the product to be a valuable source for testers from other teams. This
in this leaner way, functionality addressing issues that hindered evolutionary change of the QA’s
after functionality, made the the team. They got people to think role helped to return the flow to
applications more stable in the about the problems and come up where it had been previously.
long run. with solutions. In hindsight, the retrospective
Due to the fragile nature of During consequent meetings resolved many other
mobile applications and websites, retrospectives, the team began to glitches the mobile teams faced.
Torsten had often been frustrated reevaluate the notion of shufflng The daily stand-up meeting’s
with products crashing after work to the one QA guy. How fair quality had deteriorated when
changing and refactoring the code was that? The developers were the team scaled up. Without set
base. the original writers and creators policies, it often was chaotic and
“When I knew that I could add of code, so how could they help unfocused, oftentimes shifting to
a feature without the chances of resolve this bottleneck? As the non-development-related matters.
breaking the product, I felt more team pondered on these questions, After the problems with
compelled to finish it, even if I they agreed that something drastic ineffective daily meetings were
was blocked,” Torsten says. had to change. escalated during numerous
And it did—little by little, retrospectives, new rules were
Harald, the Quality Assurance put in place. The only people who
The QA and the engineer, began to consult were allowed to speak during
with the team about how they the daily were the developers.
Retrospective themselves could test more and Questions from other participants
therefore need less actual QA such as the product owner, Holger,
“We have always had this testing. He established practices or anybody else had to be taken
issue—more developers than for the team to be able to test their privately afterward.
Quality Assurance engineers. own work.
When the ratio became twelve to “Test cases2 are not something
one, we were in trouble.” Holger that I as a front-end developer The Lean
says. could create. I do not know the
Although development had appropriate programing language. Experiment and
increased substantially, the mobile But what our QA did was to come
team still remained with just one up with frameworks that made the Café Tests
QA engineer. As the team scaled, writing a test very easy. Running
testing and quality assurance them, I could see immediately “The next project should be
was on the verge of becoming a whether I had engineered my user an iOS app for mobile.de car
serious bottleneck. Developers story well.” Torsten says. dealers,” the business people said
were used to handing in their Manual testing sessions one day.
user stories to QA for testing, but were established, during which It was February 2013 and the
soon the flow was disrupted and developers from one team team was skeptical that the need
the team could no longer achieve tested the stories of another. existed. At that time, the mobile
the continuous deployment they Furthermore, the QA consultant development team already had an
2
A 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 originally 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.
-10-Figure 5 - The Epic ticket for the iOS 7 version of the application is already on the iOS team’s board.
iOS app for iPhone and iPad, as if the product has many defects. After two days, a click
well as Android apps in German The purpose of the test is to see dummy was created. After a few
and in English. whether these target users find more iterations and some pivots,
“We are sure the dealers need the application interesting and it became clear that they had
a service to help them keep track valuable. found valuable features, but that
of inventory,” the argument went. Instead of arguing with his most likely the business model
By that time two-thirds colleagues from the business would not work. In those four
of all car dealers in Germany side, the product development days, all participants received so
were active users of mobile.de. department cleared some budget much valuable feedback about
The mobile team’s process had and time for a field trip to the existing application that they
smoothed out to a large extent, Frankfurt to test the proposed came back to Berlin with a bagful
and Holger had more time to new application and validate the of user stories.
focus on non-process-related business model. Inspired by this experience,
issues. A group of user experience team members Lars and Max
Reading a copy of The Lean (UX) experts, product owners, (product owner and interaction
Startup,3 which he and all of his and developers volunteered to architect, respectively) set up
colleagues were given by mobile. do the experiment. Spending just lean and frequent validation
de, was one such thing. He was four days and starting off with a experiments.
fascinated with the argument for paper prototype, the five explorers For instance, once a week
early validation of the hypothesis visited the car dealers’ capital. Max takes his laptop and works
of customer needs. The process They knew this timeframe would from cafes around Berlin. He talks
to do that was simple—build be enough for the necessary to strangers there and asks them
something as minimal as possible iterations to create the MVP on to play around with a prototype.
that can still function as a viable the spot. They split each day into The quick user feedback, proper
product, or a minimum viable four iterations and each time metrics, and consistent validation
product (MVP), as it is known. presented an improved version of features fundamentally changed
This MVP should be taken based on the feedback they the way the team develops their
out into the field for testing with had received from the previous products.
example target customers, even iteration.
Ries, Eric. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses.
3
New York: Crown Business, 2011.
-11-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 Lean Kanban University
Lean Kanban University (LKU) works to assure the highest quality coaching and
certified training in Kanban for professional services work worldwide. LKU Accredited
Kanban TrainersTM and Kanban Coaching ProfessionalsTM follow the Kanban Method for
evolutionary organizational change and an alternative path to agility.
Lean Kanban University offers accreditation for Kanban trainers, a professional designation
for Kanban coaches, and certification and LKU membership for Kanban practitioners.
edu.leankanban.com info@leankanban.com
© 2014, Lean Kanban Inc.You can also read
