An agile wind

Why Stormpath converted to Kanban

Elliot Bentley
kanban1

Burnt out by Scrum, engineers at user management startup found enlightenment in deadline-free Japanese methodology.

Adherents of software
development methodologies can often seem religious in their zeal,
so it’s always interesting when a company converts.

Alex Salazar, CEO of user management-as-a-service startup
Stormpath, has written
a long
blog post
about his company’s poor experiences with Scrum. The
popular agile methodology left staff members exhausted and
demoralized, said Salazar.

However, while Kanban – which was created by Japanese company
Toyota – resolved many of these issues for the better, it also
brought problems of its own.

Scrum involves a cycle of planning meetings, controlled-length
‘sprints’ and retrospective meetings designed to promote a more
agile style of software development. However, each of these stages
was causing issues at Stormpath, reducing productivity both short
and long term. “It was too rigid, created too much overhead, and
started to cause burnout on our team,” said Salazar.

The planning meetings, for example, took up half a day
(plus preparation), forcing engineers to sit around listening about
unrelated systems. As a young startup, Stormpath has a “very
limited set of resources”, and this was a drain on time and money
that could be spent elsewhere.

This first phase is supposed to help determine the length of the
following sprint, but the engineers found themselves “gaming the
process” due to the difficulty of predicting how long each task
would take. Changes to the software’s requirements mid-sprint only
accentuated this problem.

This mismatch meant that code quality suffered and management
felt that promises were not being kept. “Business felt engineering
missed their targets, Engineering felt business kept moving the
ball,” said Salazar. “Everyone’s morale suffered.”

Worse, these sprints frequently left the team burnt out as they
rushed to complete tasks, leading to a productivity drop towards
the beginning of the next task. The result, as illustrated by this
graph, was a very uneven distribution of effort over time:

Enter Kanban, a software development methodology that
prioritises focus over speed by limiting the number of tasks active
at one time. Salazar decided to test it out within Stormpath, and
after a transition period of two days it began to make his team
“very happy”.

The time-consuming planning meetings were no longer
necessary, and blame-placing retrospectives were replaced with
forward-looking ‘Kaizen’ meetings where future improvements to the
process are considered. Free of artificial time constraints, the
engineering team was also able to concentrate on code quality.

“Under Scrum, there was always a temptation to cut
corners in order to get things into the Sprint and then shove the
missing work into the Tech Debt backlog, like skipping a code
review, approving 70% code coverage when our standard is 95%,
etc.”

However, Salazar admits that the removal of deadlines
risks slowing the process. “We’ve had to impose a sense of urgency
in our team through culture and management,” he said. It’s “harder
but hopefully healthier.”

This is a minor downside compared to what the company
has gained. “Ultimately, we ended up with a happy team, higher
productivity, less tension between the business and engineering,
higher quality software, and A LOT less overhead. Win.” It sounds
as though the company is unlikely to lapse anytime soon.

Author
Comments
comments powered by Disqus