Every software development team is unique in people and dynamics. And yet, we all know an idealist and we’ve all had to deal with a rockstar at some point. So then how unique are we as a development team? I’m not sure, but we’re apparently unique enough not to fit the suit of Scrum. But why? How did we get here and more importantly: what suit do we fit?
Scrum 101
Scrum is great: it’s well thought through with over twenty-five years of practice in almost all types of organizations. It groups the software development process in short iterations, called sprints. These sprints are between two and four weeks in length and there is one simple rule: every sprint has to deliver a shippable product that adds business value.
Work is provided to the team by a product owner; they manage all the stakeholders and maintain the backlog. At the start of every new sprint, the team pulls in items from the backlog that they can work on. As a multidisciplinary team, they are able to work on all items, they commit to the product owner to finish all that work within the sprint.
As Scrum is an agile method, the team has to improve itself.
During the sprint, the team manages itself with a little help from the Scrum Master. They oversee the Scrum process, train the team in Scrum and resolve any impediments the team may experience. The Scrum Master also facilitates all the necessary meetings, for example the daily Scrum (also known as daily stand-up), during which the team discusses the sprint, whether they are on track and/or if there are any impediments that block their work.
As Scrum is an agile method, the team has to improve itself. They do so by holding a retrospective meeting at the end of every sprint. From that meeting, at least one improvement item is selected and placed directly in the upcoming sprint. An improvement item can basically be anything, like putting up a physical whiteboard to keep track of the items or doing the daily Scrum at a different time.
Different strokes for different folks
So why didn’t this work for us? First of all, we are a security company, so we need to deliver quality in every way we can. Scrum doesn’t prevent this of course, but we found ourselves struggling with all the work within a sprint. Every so often, some issue just required more work than we expected: we needed to do it right and secure. Yet spending more work than estimated on one issue would of course jeopardize finishing all the other issues.
We experienced a lack of quality in these other issues. Functional testing would be squeezed into the developers’ tasks and a finished feature was put into production without further testing, let alone a user acceptance test. We were faced with more and more unplanned work, fixing bugs in production, which in turn jeopardized the sprint commitment once again.
We were looking for a process to which people had to adjust, but what we really wanted was a process that would fit the team.
Last but not least, we had no flow in our issues and the estimations were going in every direction imaginable. It was hard to measure velocity (the amount of work the team can pick up in a sprint) so we would over-commit / under-commit every other sprint. Issues were “in progress” for a very long time, most of the time for very good reasons, but the developer working on that issue was unavailable for the rest of the team. Whenever user acceptance testing was done in production, the results were not good, so we had to fix things quickly.
Back to basics: what do we need
We thought about the process and problems for a long time. We didn’t want to rush into some other method only to find out it also has issues. So, a lot of scenarios were considered, looking at their advantages and disadvantages in every way we could. And suddenly it hit us, we were thinking in completely the wrong direction. We were looking for a process to which people had to adjust, but what we really wanted was a process that would fit the team.
As unique as we are, we hate change, especially in our way of working. So, we went back to the drawing board, sat down with all the developers to find out their strengths, and figured out a process that fits the existing flow.
We are no longer bound to sprints, instead; developers continuously pick up work from the backlog.
What we need is for all work to be visible, so no secret tasks via email, chat or someone at the desk of a developer. We also need more quality, we need to know if something is broken in production, but more importantly we need to know if we’re going to break something in production. Last but not least, we need flow to get things done all the way, so including the verification of issues in production.
With Kanban we can
After all this research we found that Kanban would serve our needs perfectly. We are no longer bound to sprints, instead; developers continuously pick up work from the backlog. The power of Kanban for us is in two important aspects: we made solid and non-negotiable agreements to transfer issues to the next phase and we agreed upon a maximum number of issues per phase.
With Kanban you often start with a limit for the number of issues in progress that is a bit higher than the number of developers.
This last agreement is called the “work in progress” limiting. A limit on each phase means there can be no more issues transferred to that phase. So, if we have a limit of five on the functional test phase and there are five issues in that phase, no issues can be transferred from the phase before. In practice it means that developers will have to do functional testing or help the tester to get that number below the limit of five, before they can transfer a new issue.
With Kanban you often start with a limit for the number of issues in progress that is a bit higher than the number of developers. You don’t want to push things too hard. But when the flow starts to come, you might want to play with the numbers to see if they can be more restrictive. The team becomes the owner of the flow; they need to finish things before picking up new issues to work on.
No such thing as a perfect solution
Of course, the new situation isn’t a perfect world.
We will have external dependencies, especially in user acceptance testing. And there will be rework from the testing phase, so what happens if an issue in the testing phase has bugs, but the limit for the “in progress” issues is already reached? Do you put it back or do you keep it in the testing phase? What if the “in progress” phase is at its limit and a critical bug in production is reported? Can we only work on it once we finish some nice new feature.
Kanban turned out to be our suit. But this might not be true for your organization.
We haven’t got all the answers yet, but luckily Kanban is just as agile as Scrum. So, we work together as a team and evaluate the process and ourselves to try and be a better team every day.
Kanban turned out to be our suit. But this might not be true for your organization. Try to work with the team to really dive into their strengths and the problems they experience. Make them your starting point to find (or even design) a process that fits and makes your team perform.
Feel free to contact us for more information on this topic or our organization. If you are a PHP or GoLang developer and are enthusiastic about ON2IT or the way we put developers first, check out our vacancies and feel free to apply, we’d be happy to talk to you.
Peter van der Leek
Teamlead DevOps
