An agile wind
Why Stormpath converted to Kanban
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.