Software Development

Document Sample
Software Development Powered By Docstoc
					               Innovation in Software Development Process
               by Introducing Toyota Production System

               V Koichi Furugaki V Tooru Takagi          V Akinori Sakata
               V Daisuke Okayama
                                                              (Manuscript received June 1, 2006)

               Fujitsu Software Technologies (formerly Fujitsu Prime Software Technologies [PST])
               has been conducting activities since 2003 to improve productivity using the Toyota
               Production System (TPS). An agile development process and a store management
               method were introduced to implement the basic concepts of TPS in the IT software
               field. We included the basic concepts of TPS (elimination of muda [waste], heijunka
               [leveled production], and jidoka [automatic detection of abnormal conditions]) and
               visual management in the agile development process and store management method
               as practical techniques. PST introduced this agile development process to its soft-
               ware development process and the store management method to support its
               maintenance process. As a result, PST achieved significant improvements in both
               processes and in its organizational climate. This paper introduces the TPS concepts
               employed in the agile development process, describes how heijunka is used in the
               store management method, and examines the effects of implementing agile develop-
               ment and store management at PST.

1. Introduction                                            and the store management method, which employ
     Fujitsu Software Technologies (formerly               TPS, have both been introduced. This paper
Fujitsu Prime Software Technologies [PST]),                describes agile development and store manage-
following the burst of the IT bubble in 2000,              ment and the effects of their introduction.
introduced the Unified Modeling Language (UML)
and intensified its project management to improve          2. Agile development and
the productivity of software development. These               process improvement
efforts improved productivity, but not enough to                In general, agile development is regarded as
overcome IT deflation. To break through this               the extreme opposite of waterfall development. In
situation, the Toyota Production System (TPS),1)           waterfall development, each process (e.g., plan-
which has already proven its effectiveness in              ning, analysis, design, implementation, and
hardware manufacturing, was introduced experi-             testing) is performed only once and in sequence.
mentally to the software development processes.            In agile development, a series of these processes
This means that the concepts of TPS such as the            is repeated in what is known as repetition devel-
elimination of muda (waste), heijunka (leveled             opment (Figure 1).
production), jidoka (automatic detection of                     Compared to the repetition style of agile
abnormal conditions), and visual management are            development, waterfall development has the
practiced in the software development processes.           following drawbacks.
To implement these concepts, the agile develop-            1) Waterfall development assumes that no
ment process (hereafter called agile development)               changes will be made halfway through

FUJITSU Sci. Tech. J., 43,1,p.139-150(January 2007)                                                      139
K. Furugaki et al.: Innovation in Software Development Process by Introducing Toyota Production System

                          Scope                              Scope            detected at an early stage.
                                                                              Unlike other industrial products, a software
                                                                         product is not continuously manufactured. Also,
               Analysis                                                  in waterfall development, the series of processes
                                                                         is performed only once during the development
                Design                                                   period. Therefore, in many cases, lessons that
                                                                         were learned from the successes and failures that
                                                   Planning              occurred during development will not be applied

                  Test                                                   to the next project. Consequently, it is hard to

                                                                         execute the plan-do-check-act (PDCA) cycle.
 Time                             Time                                        On the other hand, with agile development,
      (a) Waterfall development          (b) Agile development           a series of software elements are developed
                                                                         repeatedly by almost the same people using the
Figure 1
Comparison of waterfall and agile development.                           same material and in the same environment.
                                                                         Therefore, the lessons learned from the develop-
                                                                         ment processes will likely be used in the following
                                                                         development processes.
     the planning; therefore, the additional                                  As a result, there are opportunities for the
     person-hours required for track back will be                        PDCA cycle to be executed. This is the true
     significant if any changes are made.                                advantage of agile development.
2) Bugs are detected at the review of each
     process end and during the test of lower                            3. Agile development and
     processes. If any bugs are detected, the                               concept of TPS
     additional person-hours required for track                               Agile development includes many of the TPS
     back will be substantial.                                           concepts. The following are some examples.
3) If the quality of design and implementation                           1) Pull system
     are not good, the person-hours needed for                                The concept of the pull system is embodied
     testing (debugging) will increase.                                  in the acceptance test of agile development. The
4) Operable software cannot be obtained until                            acceptance test tests whether the software meets
     the final process is completed.                                     the customer’s requirements. This test drives the
     Agile development has the following advan-                          implementation, which is very different from the
tages to offset the issues inherent in waterfall                         situation in traditional development, in which the
development.                                                             incoming specifications from the upper processes
1) Analysis, design, implementation, and                                 drive the implementation.
     testing are repeatedly performed in                                 2) Just-In-Time
     smaller units; therefore, it is more tolerant                            The Just-In-Time concept prioritizes the
     of changes and additions to the planning                            customer’s needs and implements the prioritized
     (requirements).                                                     functions sequentially. Also, this is described as
2) To complete the required implementation and                           You Aren’t Going to Need It (YAGNI).
     testing requirements, operable software can                         3) Visual management
     always be obtained, even if the scope of the                             In agile development, “mirroring,” which is
     implemented features is small.                                      a practice of Extreme Programming (XP), embodies
3) By repeating the regression tests every time                          the visual management technique, which makes
     a small unit is implemented, failures can be                        a project’s status self-explanatory using analog

140                                                                                      FUJITSU Sci. Tech. J., 43,1,(January 2007)
                       K. Furugaki et al.: Innovation in Software Development Process by Introducing Toyota Production System

media and encourages much faster feedback in                      second iteration is terminated, the operable
the action level.                                                 software is output in the same way as in the first
4) Heijunka/multi-skill development                               iteration. This software has the functions that
     Multi-skill development, which gives each                    were implemented during the second iteration as
worker multiple work skills, and heijunka, which                  well as the initial function scope.
reduces each worker’s working hours, are the                            As each iteration is executed, the software
principles of agile development.                                  is developed and the implemented scope is
4. Agile development                                                    Also, the software can be released to the
      In agile development, the development                       customer whenever an iteration is complete.
period is divided into units called iterations. An                      Figure 2 shows the development procedure
iteration is a period in which processes are                      within an iteration. The customer requirements
executed to develop the scope of a function.                      entered when the iteration starts are sorted in a
      The first iteration starts at the beginning of              simple, single function called a story. It is prefer-
development. At this point, the prioritized                       able if the customer creates a story on their own;
customer requirements are clearly indicated to the                however, in many cases, a role called the
development team, which implements them                           okyakusama (customer) proxy is set within the
according to their priority. Also, the end date is                development team. The customer proxy consists
decided when the iteration starts. The time                       of one or more team members who represent the
period is typically from one week to a month.                     customer’s interests. The members who best un-
Even if the requirements have not all been imple-                 derstand the customer’s position undertake this
mented, the end date is given priority. Any                       role, and the requirements of stories always have
requirements that have not been implemented                       top priority.
(lower priority) are postponed. If all the require-                     The created stories are divided into units
ments have been implemented before the end date,                  called tasks at a staff meeting called a planning
new customer requirements can be worked on.                       meeting (or planning game). A story is a function
Therefore, although all of the functions might not                unit from the customer’s viewpoint, and a task is
be implemented as originally estimated, the                       an implementation unit from the developer’s view-
provision of outcome will not be delayed. There-                  point. In other words, the planning meeting can
fore, the delivery date is given priority over the                be described as the design task. This planning
function scope. Once the iteration is terminated,                 meeting is held when the iteration starts.
even if all of the customer requirements have not                       Tasks that have been divided at the planning
been implemented, the high-priority functions will                meeting are assigned to the developers at the
have been implemented, and operable software                      stand-up meetings (brief all-staff meetings) that
can be output.                                                    are held every morning. The tasks are often
      As soon as the first iteration is terminated,               assigned according to the developers’ own choices
the second iteration begins. At this time, as with                rather than as instructed by the manager or
the initial iteration, the prioritized customer                   supervisor. The developers are required to un-
requirements and the operable software from the                   derstand the entire development picture and
initial iteration will be entered. This iteration is              determine what should be done and take action
often set to the same length as the initial itera-                on their own initiative.
tion. Repeating the same time period is an                              Also, when the pair programming phase is
effective way for the team to learn the develop-                  executed, the pairs will be decided at the stand-up
ment rhythm within the time frame. When the                       meeting on that day. Ideally, the pairs are

FUJITSU Sci. Tech. J., 43,1,(January 2007)                                                                               141
K. Furugaki et al.: Innovation in Software Development Process by Introducing Toyota Production System

                                                                                                                Feedback to processes
                                                      Iteration (about 2 weeks)

                                                                                         Pair programming

                                                     Task                                                        Code

                                                                                                                                                                   Completion of story

                                                                 Stand-up meeting
                                  Planning meeting

                                                                                                                              Acceptance test

                                                                                         Pair programming         Test

      Okyakusama                                                                         Pair programming        Code
      (customer)                                     Task                                                         Test
                                                                                         Pair programming

                            All developers                  All developers                                                                      All developers
                                                                                             Daily repetition
                                                                                    Daily checking at stand-up meeting

      Figure 2
      Agile development procedure.

switched every day. Pair switching encourages                                                    completion of the story by the acceptance test are
the spread of knowledge and therefore can                                                        repeated daily.
provide a higher learning effect within the                                                           At the end of an iteration, a meeting called
development team.                                                                                the kaiko (retrospect) is held, in which all the
     Also, by making the program code and                                                        developers participate.
components available to the whole team instead                                                        In the kaiko, all of the details relevant to the
of allocating it to specific persons, “unbalanced                                                iteration are reviewed, for example, the coding,
intelligence” about the software development can                                                 testing, and meetings and even the air ventila-
be prevented.                                                                                    tion, lighting, and telephone manners of team
     The test program is created at the same time                                                members are reviewed.
as the code is developed by the pairs.                                                                Then, the staff do the following.
     The developed program is tested by this test                                                1) Review the activities that will continue in the
program, and the tasks are completed. When all                                                        next iteration
of the tasks that compose a story are completed,                                                 2) Discuss any problems that occurred, find
the completion of the story is tested by the accep-                                                   their solutions, and confirm their implemen-
tance test, which is a test program created by the                                                    tation in the next iteration
customer or customer proxy.                                                                      3) Reach an agreement about new efforts that
     From another viewpoint, this is a test                                                           must be made in the next iteration.
procedure in which the criteria for completion are                                                    Bringing the resulting feedback from this
clear. The story is completed by passing the                                                     kaiko meeting into the development process drives
acceptance test. Within an iteration, procedures                                                 future improvement.
from the implementation of the tasks to the

142                                                                                                                   FUJITSU Sci. Tech. J., 43,1,(January 2007)
                       K. Furugaki et al.: Innovation in Software Development Process by Introducing Toyota Production System

5. Implementation of agile                                        11) Customer proxy
   development                                                    12) Refactoring
     The following is an example implementation2)                      Test-driven    developments    were     not
of agile development.                                             performed because, since this was the first agile
     In this example, a prototype system was                      development for the staff members, certain
developed for the manufacturing industry with a                   technical risks had to be avoided.
development period of about two months. The
system is an infrastructure Web application that                  6. Evaluation of agile
uses server-side Java (servlets). There were nine                    development
members in the development team.                                        The evaluation of the agile development
     The following lists the amount of                            conducted in the example implementation
software-development          experience        and               described in the previous section is detailed
object-oriented development experience (in that                   below.
order) in years for each member.                                        The viewpoints of this evaluation are produc-
Member X: Tracker and customer proxy: 9 and 8                     tivity, quality, cost, delivery date, and the opinions
Member Y: Manager and coach: 5 and 3                              from developers.
Member Z: Coach: 3 and 2
Member A: Developer: 3 and 1                                      6.1 Productivity
Member B: Developer: 3 and 1                                           The productivity in each iteration and the
Member C: Developer: 0 and 0 (new employee)                       productivity in the entire development are indi-
Member D: Developer: 2 and 1                                      cated below using a productivity index.note)
Member E: Developer: 4 and 1                                           Iteration 0: 0.760
Member F: Developer: 14 and 7                                          Iteration 1: 0.949
     Members E and F joined the project at the                         Iteration 2: 0.911
end of July. Also, none of the staff had previous                      Iteration 3: 1.962
experience of agile development. The introduced                        Average throughout: 1.268
practices of XP were as follows.                                       The productivity at the beginning of the
1) Iteration (iterative development)                              development was 24% lower than PST’s standard
     At the beginning, a five-day iteration was                   productivity; however, it was improved at the last
     used as a trial and then a two-week itera-                   stage and indicated a 26.8% increase throughout
     tion was set three times.                                    the agile development. The reasons for this
2) Kaiko (retrospect)                                             productivity improvement are examined below.
3) Visual management (mirroring)                                  1) The functions were implemented according
     Story cards, task cards, and a burndown                      to their priority so that unnecessary functions
     chart (graph of number of backlogs) were                     were not implemented. Also, stories were divided
     posted on a wall so the developers could check               into tasks and then developed one by one
     the progress in real-time.                                   (single-flow production) so that waste (i.e., untest-
4) Pair programming                                               ed programs) was eliminated. In addition, because
5) Co-ownership of source code                                    of the existence of the customer proxy, no inter-
6) Coding criteria                                                mediate output such as unrequested documents
7) Stand-up meetings                                              was created.
8) Continuous consolidation
                                                                  note)      A comparison of the number of source code
9) Unit testing
                                                                             lines written by each member per month
10) Acceptance testing                                                       against a standard PST value

FUJITSU Sci. Tech. J., 43,1,(January 2007)                                                                               143
K. Furugaki et al.: Innovation in Software Development Process by Introducing Toyota Production System

2) Because of the pair programming, the                                                      ask questions or discuss their concerns at any
necessary information was always available for                                               time. Also, the program can be reviewed at any
the developers. Also, by co-owning the source code,                                          time, which dramatically suppresses the creation
any developer could modify any program. This                                                 of bugs compared to the traditional method.
prevented lags due to modifications by other                                                 2) The automated regression tests reveal bugs
developers, which tends to occur during traditional                                          within a day. Also, the program code is immedi-
development.                                                                                 ately tested with the test program that is created
3) The daily progress was checked in the stand-up                                            at the same time and then debugged.
meeting every morning, which enabled the team
to provide a timely response to latency and                                                  6.3 Cost
optimize the task schedule.                                                                       Figure 3 shows the overtime hours of the
4) The kaiko meeting held for each iteration                                                 developers in each iteration.
implemented the PDCA cycle within the develop-                                                    As the iteration precedes, the difference in
ment process.       This meeting enabled the                                                 overtime hours between developers decreases,
development team to share their problems and                                                 which means heijunka is taking place.
give feedback for the next iteration.                                                             The heijunka of the working hours is affect-
     The above practices are considered to                                                   ed by the degree of multi-skill development of the
improve productivity.                                                                        developers. If any developer can work on any job,
                                                                                             the work hours can also be leveled. Figure 4
6.2 Quality                                                                                  shows the commitments of each developer to the
     Agile development is not like waterfall                                                 programs as measured using the commitment log
development, which is divided into processes such                                            of the Concurrent Versions System (CVS), which
as planning, analysis, designing, implementation,                                            is a configuration management tool. As can be
and testing, and therefore the quality cannot be                                             seen, each developer had multiple commitments,
verified by tracking down the occurrence of bugs                                             which indicates that multi-skill development was
at each process. However, developers are finding                                             occurring.
that agile development promotes high quality.                                                     In the traditional method, each developer is
1) With the pair programming, developers can                                                 in charge of a component or a program, which,

                               Iteration 0   Iteration 1     Iteration 2   Iteration 3
Average overtime (hours)

                                                                                             CVS commitment ratio (%)

                                                                                         A                                                                          A
                                                                                         B                              60                                          B
                           2                                                             C                                                                          C
                                                                                         D                                                                          D
                                                                                         E                              40                                          E
                                                                                         F                                                                          F

                                        E and F joined
                                        at the end of July                                                                       Developed programs

Figure 3                                                                                     Figure 4
Developer’s overtime hours in each iteration.                                                CVS commitment ratios of developers.

144                                                                                                                          FUJITSU Sci. Tech. J., 43,1,(January 2007)
                           K. Furugaki et al.: Innovation in Software Development Process by Introducing Toyota Production System

consequently, has the idiosyncrasies of the                              were clear since the beginning of the development,
developer.                                                               and the remainder were received sporadically
     Co-ownership of the source code and pair                            during the development. Also, many requirements
programming help implement multi-skill                                   disappeared from the list. New requirements
development. No one is appointed to work on a                            from the customer were implemented in the
specific program: each day, the developers work                          order they were received, and all the requirements
on a different program and with a different                              were implemented by the release date. The
partner so that the experienced developers pass                          average time between the arrival of a requirement
on their knowledge. This mechanism facilitates                           and its implementation was one week. In fact,
multi-skill development.                                                 on average it took as little as one week to
     In this agile development, compared to the                          implement a requirement after it was received.
previous waterfall development of a similar                                   This rapid rate of implementation was
system, the cost rate was reduced by 16% (cost                           achieved due to the practices of customer proxy,
reduction).                                                              iteration, and stories. The requirements were pri-
                                                                         oritized, the implementation of single-flow
6.4 Delivery date                                                        production shortened the delivery date, and the
     Figure 5 shows the transition of the num-                           regression tests were performed in an environment
ber of customer requirements and implemented                             of continuous integration. Including refactoring,
requirements in this agile development.                                  we think we have formed a development process
     Fifty percent of the customer requirements                          that ensures quality and also allows additional

                            Occurred stories                              Digestion point
                                                                          Cumulated stories
                            Extinct stories                               Burndown chart

             180 Iteration 0         Iteration 1                Iteration 2                   Iteration 3
             110                                                                                                       Delivery
             100                                   Digested requirements                                               date

              90                                   (Back log)
              50       Occurrence of
              40       requirements
                                                                                                                   Release date
                 7/5         7/12                        7/26                    8/9                        8/23    8/27
             -10                     Extinction of
             -20                     requirement               Month/Date

     Figure 5
     Transition of customer requirements and implemented requirements.

FUJITSU Sci. Tech. J., 43,1,(January 2007)                                                                                        145
K. Furugaki et al.: Innovation in Software Development Process by Introducing Toyota Production System

requirements to be implemented.                                  example, the implementation method and the
                                                                 verification of quality, before agile development
6.5 Opinions from the development                                can be applied to large-scale projects involving
    members                                                      more than about 20 people and the
     The following are some of the opinions of the               development of mission-critical systems. However,
development members in the agile development                     there seems to be many procedures in agile
project.                                                         development that can also be effective in
1) “In the past, when I became overloaded, I was                 waterfall development, for example, visual
     under pressure and did not want to come to                  management; the iteration/retrospection meeting
     work. However, this time, even if I was over-               (kaiko), which implements the PDCA cycle
     loaded, I did not feel under pressure.”                     within the development process; and the use of
2) “It was easy to see the quantity of work per                  pair programming, which levels the loads and
     day at the task allocations in the stand-up                 abilities of the developers. In the future, the
     meetings.”                                                  implementation of agile development practices
3) “It was good to have a coach. We could ask                    will be expanded step-by-step into traditional
     the coach questions at any time.”                           development processes such as waterfall
4) “The atmosphere of the entire team has been                   development.
     good, and the members’ motivation remained
     high until the end of the development.”                     8. Process improvement by store
5) “The pair programming system prevented the                       management method
     work from becoming stuck.”                                       Agile development is intended for software
6) “During the pair programming, we worked                       development processes; however, the store
     while talking about things we knew or did                   management method is intended for much larger
     not know. So eventually we learned new                      processes.    The store management method
     things.”                                                    improves a process by implementing the TPS
7) “Due to the pair programming, the skills of                   concept of leveled production. In this section, we
     the team quickly improved.”                                 describe this method using the work model shown
8) “The pair programming reduced mistakes                        in Figure 6 as an example.
     and facilitated efficient work.”                                 This work model has three types of opera-
     These quotes show that the developers kept                  tion works that require randomly generated work
their motivation high and were able to work with                 hours and abilities (a, b, and c) and a person in
a stable mental state during the entire develop-                 charge of each operation to process the work
ment period.                                                     sequentially.
                                                                      Generally speaking, regarding the work
7. Expansion of agile                                            generated in the operation processes, workers are
   development                                                   assigned to each operation and perform the work.
     This example of agile development described                 However, when work is done in this style, the work
in the previous section was a relatively small                   capability and the workload depend on the
development for a prototype system. It was                       operations, which reduces the overall perfor-
performed on an XP basis and was suitable for                    mance. The store management method improves
what is generally considered the proper range of                 the overall performance by gathering the instruc-
XP (i.e., for software that is not life-critical and             tion management for the work and minimizing/
with a team of less than 20 people).                             heijunka the workload differences and work
     There are many issues to be solved, for                     capabilities between workers. Figure 7 shows

146                                                                                 FUJITSU Sci. Tech. J., 43,1,(January 2007)
                                             K. Furugaki et al.: Innovation in Software Development Process by Introducing Toyota Production System

the heijunka improvement that was achieved in                                                            nomic heijunka control
this example.                                                                                            These practices are described below.
     The following heijunka practices were                                                          1) Work execution using the store pull system
implemented.                                                                                             As shown in Figure 8, the work generated
1) Work execution using the store pull system                                                       in the operations were managed in work instruc-
2) Single-queue workload management                                                                 tion boxes called Store-IN boxes. The workers
3) Visual management of workload and auto-                                                          chose one work item and then started working on
                                                                                                         It is important that the workers focus on one
  <Generation of work>                                        <Completion of work>
                                                                                                    work item at a time (single-flow production).
                                                                        a a a a                     Otherwise, they will waste time switching
                                                                                                    between work items and might, as a result, be
               c                                       In charge of
                                     a                 operation A                                  unable to complete them within the allocated
   a           b
                                     c                                                              amount of time, leading to a reduction in overall
       b                                                                 b                b
                            a            b                                                          lead-time.
           a                     a                     In charge of                                 2) Single-queuing workload management
                                                       operation B
                                                                                                         As shown in Figure 9, when work items were
               a : Operation work A
                                                                                      c             generated, instead of assigning them in equal
           b            : Operation work B
                                                       In charge of                                 amounts to each worker, they were managed
       c                : Operation work C             operation C
                                                                                                    using a single queue of Store-IN boxes and
Figure 6                                                                                            processed in sequential order. When randomly
Work model for store management.                                                                    generated work was processed, this method greatly

                                                   b                                                                                   b
                                     a                                                                                     a

       time                          a                                                                                     a                      a
                                                   b                                                                                   b
                                     a                                                                                     a
                                                                                              Heijunka                                            b
               Work hours

                                     a                                                                                     a
                                                   b                                          Poor distribution of                     b
                                     a                                                        work capabilities and        a
                                                                                              workloads between
                                     a                                                        workers is eliminated.       a
                                                   b                                                                                   b
                                     a                          c                                                          a                      c

                                     a                                                                                     a
                                                   b                                                                                   b
                                     a                                                                                     a

                                Person in       Person in   Person in                                                  Person in   Person in   Person in
                                charge of       charge of   charge of                                                  charge of   charge of   charge of
                                A               B           C                                                          A           B           C

       Figure 7
       Heijunka improvement by store management.

FUJITSU Sci. Tech. J., 43,1,(January 2007)                                                                                                                 147
K. Furugaki et al.: Innovation in Software Development Process by Introducing Toyota Production System

   Store-IN                                                                       Store-IN                                                                Closing time

        a     a       a   a         b        b               c                    Operation A       a       a     a       a   a       a       a       a     a

                                                                                  Operation B           b             b           b               b             b

                                                                                  Operation C                     c                       b           a

      In charge of                In charge of         In charge of
      operation A                 operation B          operation C
                                                                                         In charge of                 In charge of                         In charge of
                                                                                         operation A                  operation B                          operation C
              a       a                 b                        c
                                                                                     a          a                b                    b                             c

Figure 8
Work execution using store pull system.                                          Figure 10
                                                                                 Visual management of workload and autonomic heijunka
Equally assigned work
                                                       Work lead time
                              a    a    a
                                                                                 to maintain the balance between the workload and
Work                                        Person 1
instruction                                                                      work capability. By solving the issues generated
                              a    a    a                                        in the course of implementing these practices
                                            Person 2                             one-by-one, the operation process was improved.
Single-queue work
                                                                                 9. Effects of introducing store
                                            Person 1
                  a       a a a a                                    Shortened      management method
                                                                                      PST’s software maintenance support busi-
                                            Person 2                             ness is not suited to agile development. However,
Figure 9                                                                         PST improved the operation of this business by
Shortened lead time by single-queue workload                                     introducing the store management method. The
                                                                                 problems affecting the traditional operation of this
                                                                                 business and the advantages of the store manage-
reduced the work lead-time compared to the                                       ment method are described below.
equally-assigned work method.                                                         The problems were as follows.
3) Visual management of workload and auto-                                       1) The workload tended to be concentrated at
     nomic heijunka control                                                      the end of the week and in the late afternoon.
     As shown in Figure 10, the Store-IN status                                  Therefore, workers frequently had to work over-
was displayed in an easy-to-visualize way on                                     time and on holidays.
boards and other media (visual management) so                                    2) Because of the workers’ differing abilities,
workers could see what work was pending for each                                 some workers had an especially high workload.
operation. By checking the load status of the                                         Implementing the store management meth-
queued work on the boards, workers could deter-                                  od had the following effects.
mine whether any additional workers were                                         1) Visual management of the workload status
required or whether certain workers should be                                    enabled the team members to always understand
switched to different workers. Heijunka was                                      the distribution status of the workload and to
implemented by the workers acting independently                                  level the workload independently. Since the store

148                                                                                                             FUJITSU Sci. Tech. J., 43,1,(January 2007)
                                                  K. Furugaki et al.: Innovation in Software Development Process by Introducing Toyota Production System

management method was introduced, none of the                                                10. Conclusion
current team of workers has had to work during a                                                  When implementing the TPS concept using
holiday.                                                                                     agile development and the store management
2) The difference in overtime hours was reduced                                              method, we found it is useful to return to the
to about 30% by leveling the workload between                                                fundamental principle of “manufacturing” in the
workers.                                                                                     software field and to improve our software
3) The teamwork capability was enhanced by                                                   development process.
about 20%.                                                                                        The concept of TPS was introduced to some
     Before the store management method was                                                  of the divisions experimentally in 2003, and by
introduced, there were no methods to measure the                                             the end of 2004, it had been introduced to every
quantity of work in the software maintenance                                                 PST division. PST’s profits stopped declining in
support operation; therefore, it was not possible                                            September 2004, and the company has been on a
to understand the work capability quantitatively.                                            gradual recovery since then.
However, after the introduction of the store
management method, all of the work has been                                                  Acknowledgement
recorded on work cards so the work capability can                                                 We are very grateful to Mr. Junichi Matsui
be understood and evaluated by analyzing and                                                 of Consultsourcing Co., Ltd. for his help in intro-
aggregating these work cards. This is another big                                            ducing the store management method to PST’s
advantage of the store management method.                                                    software development process.
     Figure 11 shows the number of work cards
that were written during a five-month period                                                 References
after the store management method was imple-                                                 1)    T. Ohno: Toyota Production System: Beyond
                                                                                                   Large-scale Production. (in Japanese), Diamond,
mented in the operation management division of                                                     1978.
PST. The figure gives a quantitative indication of                                           2)    A. Sakata: Agile Practice. Is agile management
                                                                                                   the Toyota Production System? — Attempt of
how the work capability improved.                                                                  Software Multi-Skill Development. (in Japanese),
     By introducing the store management meth-                                                     Developers Summit 2005 (presentation materi-
                                                                                                   al), 2005.
od, productivity was improved by about 80% in 4
Number of cards/persons per day

                                  4                                          3.62
                                              2.13       2.27
                                  2   1.96


                                      March   April      May       June       July

Figure 11
Quantification of improvement based on number of work

FUJITSU Sci. Tech. J., 43,1,(January 2007)                                                                                                          149
K. Furugaki et al.: Innovation in Software Development Process by Introducing Toyota Production System

                        Koichi Furugaki, Fujitsu Ltd.                                   Akinori Sakata, Fujitsu Software Tech-
                        Mr. Furugaki received the B.S. and M.S.                         nologies Ltd.
                        degrees in Chemical Engineering from                            Mr. Sakata received the B.S. degree in
                        Tokyo Institute of Technology, Tokyo,                           Engineering from Yamanashi University,
                        Japan in 1974 and 1976, respectively.                           Yamanashi, Japan in 1989. He joined
                        He joined Fujitsu Ltd., Kanagawa,                               Fujitsu Aichi Engineering Ltd. (currently
                        Japan in 1976, where he has been                                Fujitsu Software Technologies Ltd.),
                        engaged in development of mainframe                             Aichi, Japan in 1989, where he has
                        operating systems.                                              been engaged in research and devel-
                                                                                        opment of mainframe operating
                        E-mail:                          systems. He was also engaged in
                                                                  development of Web systems as a developer from 2000 to 2003.
                                                                  He promotes software development based on the Toyota
                                                                  Production System.
                      Tooru Takagi, Fujitsu Software Technol-
                      ogies Ltd.                                  E-mail:
                      Mr. Takagi received the B.S. degree in
                      Engineering from Ritsumeikan Univer-
                      sity, Kyoto, Japan in 1985. He joined
                      Fujitsu Aichi Engineering Ltd. (currently                         Daisuke Okayama, Fujitsu Software
                      Fujitsu Software Technologies Ltd.),                              Technologies Ltd.
                      Aichi, Japan in 1985, where he has                                Mr. Okayama received the B.S. degree
                      been engaged in research and                                      in Engineering from Yamanashi Univer-
                      development of OS subsystems. He                                  sity, Yamanashi, Japan in 2002. He
                      was also engaged in development of                                joined Fujitsu Prime Software Technol-
Web systems from 2000 to 2003 as an SE. He promotes                                     ogy Ltd. (currently Fujitsu Software
software development based on the Toyota Production System.                             Technologies Ltd.), Aichi, Japan in
                                                                                        2002, where he was engaged in devel-
E-mail:                                                     opment of Web systems as developer
                                                                                        from 2002 to 2003. He was then
                                                                  engaged in development of a financial accounting system until
                                                                  2004. He promotes software development based on the Toyota
                                                                  Production System.


150                                                                                   FUJITSU Sci. Tech. J., 43,1,(January 2007)