working for a venture company, Masashi Kaneda joined Yahoo! JAPAN in 2012. Kaneda had worked on the development of the top page since 2013 and was also involved in the renewal of the top page in 2015. While experiencing management positions, Kaneda mainly uses Kanban for the improvement of development organizations and processes. After receiving XP training at Pivotal Labs in 2017, Kaneda engaged in improving organizations and processes by combining Kanban and XP on Yahoo! JAPAN App and Yahoo! JAPAN Top Page for the Smartphone Browser. Currently, Kaneda is improving Yahoo! Weather / Disaster Prevention. The person Kaneda respects is Taiichi Ohno.
• A large-scale development system is required to develop many functions in parallel. • Inevitably, the target business areas and competition are wide-ranging, and the environment is changing very rapidly. • We have to compete in search, weather, news, and timeline all at the same time • The need to respond quickly to competition and market trends is higher than for single-function apps • Used by a large number of users • Maintaining high quality is necessary to ensure safety and peace of mind
app and Smartphone web • Since the full renewal in 2015, heavy users have been inducted to our app from the web, with our guidance • I want to reduce the user's sense of discomfort when switching over • Since we often develop the same function across platforms, it is based on each area instead of each platform.
charge of each product • Development is done in order of priority for each area • As for the product as a whole, there are things that we want to release earlier. • Often specific optimizations • Development needs to be concentrated in specific areas due to changing circumstances • Get help from other teams • The team that gave the help stops development • For overall optimization and prioritization • Development flow that allows flexible priority changes • Scale-out structure that accepts help
from the Toyota Production System • Only two main rules • Limit work in progress • The team with some time to spare can Pull the item from the top of the ToDo column • I considered using Scrum, but the situation changed significantly during the sprint and I needed to make changes.
• The order of priority must be earnestly determined • Every day, we set up a forum for people in charge of each area to gather and explain and make decisions. • Changing the priority of things that have not been started is welcome even on a daily basis
iOS, Android, and Backend engineers • 2-3 people in each area, about 8 people in total • In order to make decisions from a business perspective, planners are also included as owners • Set up a TechLead for each area to unify policies across areas • Web • Basically, all engineers can handle from Frontend to Server Side • About 5 people per team
sticky notes • A huge thing that fills the wall • Very high perspicuity and information radiation • Thinking in front of the Kanban can lead to conversations • Digital Kanban is also operated in parallel as a digital twin for the automation of metrics aggregation After the COVID-19 • Switched to digital Kanban as main and transitioned without major disruption
Pivotal Labs in order to achieve both development speed and quality • Typical practice • Pair programming • Pair programming is mandatory for code released to production • Pairs rotate every day within the team • Continuous Integration (CI) • Code is necessarily committed and pushed every day to rotate pairs • Test Driven Development (TDD) • First, write a unit test that fails (RED) • Have a minimal implementation that passes unit tests (GREEN) • Refactor while keeping GREEN
data of card movement is accumulated and automatically aggregated using BI tools. used in various judgments • Tools • Build Kanban with Github Project or Trello • Extract data through API and register to RDB such as MySQL • Visualization with BI tools such as Tableau or Superset
Business • That which provides direct value to the user • Technical improvement • Indirect positive contribution to value proposition. It adds to the status quo. • Maintenance/Operation • Avoid damage to future value proposition caused by inaction. Maintain the status quo • Incident/malfunction/failure • Things that restore the damage that has already occurred to the value proposition. Improve upon the negatives
size (Called “Scale” or “Super rough estimate”) • just a basis for judging the feasibility and priority of implementation at the time of submission of project proposal. • Here, as promptness and simplicity are given more importance than accuracy, a schedule cannot be made based on this. • Detailed estimate • After the project is Pulled by the development team • T-shirt size • S: less than 1 man-week. 1 point • M: 1 to 2 man-week. 2 points • L: 3 man-week to 1 man-month. 4 points • XL: 1 man-month or more. 8 points Extra Large and Super Extra Large are usually not launched as they are, but are required to split the scopes and phases.
Comparing the results of the previous term and progress of the current term • Whether it is biased towards business or whether technical improvements are being made • Are you spending too much time on maintenance and operation work? • Are accidents/defects/failures increasing?
progress • Many starts but few completions, and the amount of work in progress is increasing. • Is it Push instead of Pull? • Many completions, but there are few starts, and the number of work in progress is decreasing. • Are there too few cards available? • Both start and completion are stable, but there are many work-in-progress • Is parallel operation becoming the norm and lead time increasing? • Both start and completion are high, and work in process is stable and low
completed cards divided by business days • Add rate: Points total for added cards divided by business days • Calculated from the number of completed/additional points in the previous period and last month • You can calculate how many cards you can complete this season • Strategic prioritization of business objectives and required maintenance operations • No planning cost for cards that are unlikely to start
Is there anything wrong with the working condition of the team? • Which card is likely to end when • Since it is based on the average value, it may vary greatly • This is only a guideline, so it is prohibited to plan a schedule based on this • Can you meet the expiry date on your card? • Order to start to meet the deadline • If I add this, what can I not do instead
quickly and flexibly to changes such as changing priorities and scaling out the team through pull-style workflows in Kanban and small teams. • Through XP practices, both speed of development and maintenance of quality are achieved. • By classifying Kanban cards and automatically calculating metrics from performance data, you can visualize the health of processes, team status, resource allocation, prediction of start timing, etc., and make product decisions based on objective information. It can be carried out
with Kanban~ • https://pragprog.com/titles/hklean/lean-from-the-trenches/ • Kanban in Action • https://www.manning.com/books/kanban-in-action • Agile Project Management with Kanban • https://www.microsoftpressstore.com/store/agile-project-management-with-kanban- 9780735698956 • Extreme Programming Explained: Embrace Change, 2nd edition • https://www.pearson.com/store/p/extreme-programming-explained-embrace- change/P200000000118/9780321278654 • Planning Extreme Programming • https://martinfowler.com/books/pxp.html • Kanban and Scrum - Making the Most of Both • https://www.infoq.com/minibooks/kanban-scrum-minibook/ • Scrum and XP from the Trenches - 2nd Edition • https://www.infoq.com/minibooks/scrum-xp-from-the-trenches-2/