KANBAN AT MOBILE.DE Creating the Perfect Process, One Block at a Time - KANBANCASESTUDYSERIES - Kanban University

Page created by Debbie Henderson
 
CONTINUE READING
KANBAN AT MOBILE.DE Creating the Perfect Process, One Block at a Time - KANBANCASESTUDYSERIES - Kanban University
KANBAN AT MOBILE.DE
Creating the Perfect Process,
One Block at a Time

                     KANBANCASESTUDYSERIES
KANBAN AT MOBILE.DE Creating the Perfect Process, One Block at a Time - KANBANCASESTUDYSERIES - Kanban University
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–
KANBAN AT MOBILE.DE Creating the Perfect Process, One Block at a Time - KANBANCASESTUDYSERIES - Kanban University
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–
KANBAN AT MOBILE.DE Creating the Perfect Process, One Block at a Time - KANBANCASESTUDYSERIES - Kanban University
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–
KANBAN AT MOBILE.DE Creating the Perfect Process, One Block at a Time - KANBANCASESTUDYSERIES - Kanban University
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–
KANBAN AT MOBILE.DE Creating the Perfect Process, One Block at a Time - KANBANCASESTUDYSERIES - Kanban University
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–
KANBAN AT MOBILE.DE Creating the Perfect Process, One Block at a Time - KANBANCASESTUDYSERIES - Kanban University
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–
KANBAN AT MOBILE.DE Creating the Perfect Process, One Block at a Time - KANBANCASESTUDYSERIES - Kanban University
Figure 3 - The Android team’s Kanban board.

Figure 4 -The Mobile web platform’s Kanban board.
                                                    –8–
KANBAN AT MOBILE.DE Creating the Perfect Process, One Block at a Time - KANBANCASESTUDYSERIES - Kanban University
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–
KANBAN AT MOBILE.DE Creating the Perfect Process, One Block at a Time - KANBANCASESTUDYSERIES - Kanban University
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 University
You can also read