So you feel like your software development team is stagnating, and output isn’t where you want it to be. There must be a better way, right?
Should you try Kanban or maybe make a switch to two-week sprint cycles? How do you know which will be a better fit for your team before investing the time and heartache to implement a change?
As with most concepts of software development, there is no one-size-fits-all solution to achieve your goals, so it shouldn’t come as a surprise that the framework in which we go about organizing the team is no different. Fear not! Help is here to identify the benefits and drawbacks from both approaches, which I’ll outline to help make the decision to alter your methodology or leave it alone.
Related Article: Disrupt the Market, Not the Users With Iterative Development
Kanban
Kanban is a process of just-in-time delivery popularized by Toyota in the 1940s, but was introduced to knowledge work in the first decade of the twenty-first century. Kanban's simple approach involves a prioritized task queue that the team can choose. Each task moves through various process steps to delivery before moving on to the next, much like a car would move down the assembly line.
Advantages of Kanban
Kanban limits the amount of items that can be in progress at any given time and slots open up as tasks move from one stage of completion to another. Limiting the amount of work in progress is a very useful technique to avoid the pitfalls of multitasking.
In knowledge work such as programming, shifting from one task to the next wastes a significant amount of time by mentally having to shift gears and re-immerse oneself back into a problem. By focusing on a few things at once, the team can move items quickly from architecture to deployment.
Another benefit of switching to Kanban is that completed items don’t sit around waiting to deploy. When the work passes QA and is signed off by the stakeholders, it can be released post haste.
By keeping releases as small deployments, they have fewer merge conflicts, less amount of testing and take way less valuable time. Depending on the sophistication of your continuous release process, the time from sign-off to features entering your users’ hands can be a matter of minutes as opposed to days, weeks or even months.
Disadvantages of Kanban
When conditioned to look only at items at the top of the priority queue, individuals tend to get into lone wolf mode and focus on only the task at hand with little regard for items to come, or what the rest of the team is working on. The proper time for architecting a bigger picture solution is usually the first casualty when teams move to Kanban.
This can be combated by regularly meeting with the team to review medium-term upcoming work. If you turn the team loose on a huge backlog without these regular vision quests, expect there to be a great deal of refactoring in your future.
Another shortcoming that we’ve found utilizing a Kanban workflow is the lack of forecasting. While forecasting is difficult in all areas of software development, Kanban seems to encourage the “we’re delivering the most important items continually; it’ll be done when it gets done” mentality.
While this is true that priority items are always in progress, management likes to have a roadmap. One solution in dealing with this is by measuring the number of issues you’re able to deliver over time and using that for forecasting, but the trouble with this approach is it only works if items in your queue are of similar size.
For those familiar with building software, we know that some tasks are bigger than others and that estimation is close to impossible, and frustrating for everyone at your company.
Related Article: Why Your Tech Team Missed Their Deadline
When Should My Team Use Kanban?
Our development team uses Kanban when there are a large amount of small-to-medium sized tasks that are unrelated to one another. In this scenario, Kanban allows the team to put their heads down and focus on pounding out one task after another without putting too much concern into what’s coming next.
Kanban is great for digital agencies who work with multiple clients that have many day-to-day tasks. Management will love having features continuously being released, and developers will be motivated by the feeling of regular progress.
Sprints
Another very popular software development methodology involves the team coalescing around development cycles called sprints. Usually a period of two weeks, a common sprint begins with a planning meeting where the team makes a commitment of items they will complete for release and ends with a planned single-event release of all items.
Advantages of Sprints
By having the introductory planning meeting, the team can discuss, question and plan how all of the features are going to work together. This provides a useful time to get some key architecting out of the way before any code is written.
Another key feature of sprints is having the team determine what it believes it can deliver on. It gives the team a shared goal to work towards for each iteration. If the team can deliver everything they set out to, great!
If they are unable to complete their work by the deadline, the team can have an honest and open discussion into what went wrong. Since we learn from our mistakes, failure is readily embraced when working in this framework (as it should always be, really).
Disadvantages of Sprints
The team is expected to begin the iteration by defining a shared goal; often called a commitment. While there is nothing inherently wrong this, the term "commitment" in software development is so contentious that the Scrum founders scrubbed it from their 2011 Scrum Guide.
There are simply so many unknowns in software that seemingly simple tasks can become gargantuan undertakings. Trying to pin the team down with a commitment and then looking down on them if things become difficult and time-consuming is a great way to create ill-will.
The most challenging aspect of sprints comes at the very end of the iteration: release. Release management is the most underappreciated facet of software development and throwing together weeks’ worth of sometimes disparate code is always a juggling act of the finest order.
Merge conflicts are a lingering danger for every release so the more items you’re trying to release at once, the more time-consuming your deployments become. Often, our sprints were capped with a frustrating all-hands release war room that would often take hours to get out alive.
Since these challenges come at the end of the sprint, it’s easy to have a negative mood permeate the retrospective team meeting, thus hampering morale.
When Should My Team Use Sprints?
Sprints are best served for when the team is working on a complicated or long-term project that requires a considerable effort discussing architecture and a shared plan of attack.
When items are tightly related it’s important that the team has a better idea of what everyone is working on and how their parts all fit into the bigger picture. This is where sprints shine. They also work well when many features need to be deployed together before they can be reasonably released to your users.
Teams that work on applications that have regular release schedules will do well by sticking to sprint cycles.
So What Methodology is Best?
As with anything in software development, the best solution for your team is the one you arrive at through lots of trial and error and regular retrospectives.
Software processes are for the team, so it is best that the team creates it. You’re not likely to find any good development team that has implemented a textbook version of either agile methodologies. You’ll instead see that these teams take features from many different areas to create the best fit for them.
I encourage your teams to keep experimenting with process changes and throw away what doesn’t work. This will empower your team to continue to improve and will increase the accuracy and speed of development.