Arello Mobile and Pushwoosh are two sister companies based in Novosibirsk in Siberia, Russia. 3 years ago, the workplace was stressful and the days very long. Managers and clients were constantly fighting, while teams failed to meet delivery dates. We chose to pursue Kanban to address these challenges. Adoption at Arello was relatively easy and the maturity of the implementation is now quite deep. Pushwoosh has been another story. There was skepticism and resistance. This talk describes in detail what has been achieved at Arello, a mobile application development company of around 50 people, and contrasts it with the challenges at Pushwoosh, a push notification service with a similar number of staff. Both companies have the same owners and share some common staff and resources, however, cultural reaction to Kanban was very different. Some of the latest Kanban coaching concepts including use of the Kanban Maturity Model are now being applied at Pushwoosh. There are indications this measured and thoughtful approach is likely to succeed.

1. A Siberian tale
of two Kanban implementations
LeanKanban Central Europe, 2017
Katya Terekhova

2. Introduction
2
Arello Mobile - 8 year old
outsourcing company,
specializing in mobile
development
Pushwoosh - top-3 push-
notification service

3. Initial state: ‘night is not an obstacle to work’
• ~20 developers, 5 testers, 4 managers
• 15-20 ongoing projects
• 10-12h working day
• People often work late
• Lack of trust between us and clients as teams failed to meet
delivery dates
• Deterministic planning
• Multitasking is great!
• Time-consuming estimates
• Resource utilisation trap
3

5. Scrum Revolution
• Massive resistance
• Developers were sabotaging meetings and trolling Scrum
• Scrum activities sometimes were no more than rituals
• Question: “What could we do differently” was sometimes
answered “Stop doing Scrum”
• Developers overestimated features in order to have greater
focus factor
5

6. Theory of Constraints
• Got the knowledge of flow,
bottlenecks, inventory
• Unfinished things didn’t
have value
• Stopped falling into
resource utilisation trap
• Didn’t know how to put it
into practice
6

7. Kanban ‘discovery’
Estimates are not deterministic, you cannot know exact
answer to the question “When this item will be done?”

8. Board design
8

9. 9
Default workflow

10. 10
New workflow

11. Transparency
• There was initial period of resistance
• Eventually people admitted that it is more convenient for everyone:
managers saw actual status of work items, while developers were not
distracted by questions from managers
• Around 250 work items in progress (!)

12. Classes of services
• A tool to fight homogeneity
• 50% of all tasks were expedite request in the very
beginning
• Gradually their amount decreased to 10% and less
12

13. Bottleneck detected: QA
13

14. “Side-effects”
• Long useless planning
meetings fade out since
people got their plans
from the board
• Fixed-date requests
almost disappeared
(they were a
consequence of no trust
between us and clients)
14

15. Irrefutable demand

17. Then vs Now
17
Then Now
Overburdening
People were often under deadline pressure, long
working day, people work late, multitasking, heroic
efforts WiP limits -> relief from overburdening
Meet SLA
Teams constantly failed to meet delivery dates, it
was difficult to provide clients with reliable ETA
Trustworthy forecasts, most of the time teams manage
to deliver on time
Trust
Lack of trust, both between us and clients and
between developers/managers
Higher trust: fake expedite requests and deadlines
disappeared
Estimates Time-consuming 'guesstimates' Estimates, based on historical data
Transparency
Lack of transparency, actual status of works items
was not clear, couldn't see our bottleneck
Status of work items is clear for both managers and
clients, we are able to see queues, bottlenecks and
make decisions based on this
Customers
Claiming for detailed long-term plans, abusing
words 'Urgent', 'ASAP'
Happier clients, consider our opinion, some are even
open to experiments
Collaboration
Tense relationships, developers did not trust
managers, were sabotaging meetings
Improved collaboration, developers and testers are also
involved in process improvements
Scheduling
Long useless planning meetings, people got their
plans but they immediately became irrelevant
Dynamic scheduling, people get their plans from their
boards

18. Pushwoosh
• Separate product company
• Urgent need for a change - it was the only way to survive
• Used similar approach and steps we did in Arello
• System lead time (85%) is ~1 month instead of 3
18

19. Thank you