Sometimes you want something different from the rigorous top-down software development method known as the Waterfall method, which you’ve been taught in university. After all, it’s very rigorous and does not adapt well to changes that might come up. That means that there is little space for the input of outsiders as the process continues. If you are not a famous computer scientist yet, but you want to know more – this article is for you.
Fortunately, there are more flexible methods. For example, have you heard of the Agile method? These are a completely different way to organize software development so that it is more organic and more flexible.
In case you’re not familiar with the practice, Agile software development encompasses a group of software development strategies that rely on iterations to develop software. The idea is that what needs to be done and the solutions to the problems that arise naturally develop through the collaboration of teams that are self-organizing and cross-functional.
The great benefit of these systems – despite having different team structures – is that they all promotes teamwork, self-organization, and accountability, without sacrificing a disciplined and well-organized management process. In fact, quite often they heighten this, as people take more responsibility for what they’re doing. The Agile formula creates a set of best practices for engineers, which allows them to create high-quality software in a very short time while allowing them to adjust to what is happening and what is changing around them.
Scrum, Kanban, and Scrumban
These three strategies are different approaches to the Agile method, with very different approaches to solving the same set of problems.
In the Scrum method, for example, you work in timescales of about 1 to 4 weeks (usually), which are referred to as Sprints. These timescales and deadlines are important and heavily respected, making for a quite formal system.
Kanban is quite different. You could imagine it as a visual to-do list, where the list is adjusted and modified organically as you proceed onwards so that the workflow is constantly updated and modified. Nor are there hard deadlines here. Instead, you generally work towards a release or a wider goal.
Scrumban is a mixture of these two methods. It tries to take the best of the two techniques and tries to ditch what doesn’t work so well. In this case, that means it keeps the Sprints of the Scrum method and adds the organic flow of the Kanban method.
At the Core
One of the key differences between the Scrum and Kanban philosophy is what is at their core. With the Scrum philosophy, it is the Sprint and the time box which are the core of the project. With Kanban, it is the project and its needs that rest at the heart of the process.
Another difference is that Scrum is better suited for companies where development is constant rather than episodic, even while Kanban changes the method of project management through the non-project environment for its organization.
This means that the two approaches are suitable for quite different companies and the different problems that you’re trying to solve. For example, Kanban is the more linear approach of the two, while Scrums are multi-threaded and advance simultaneously no numerous fronts.
Similarly, Scrum assumes that the work on both the system and the product is constant and always ongoing, even while Kanban is focused on the process from the project perspective.
The Key Is in the Visuals
One of the big tricks and secrets to all three methods is the visual aspect. This is at its most eloquent in the Kanban method. Here a board is put up – either an old school white board or one on your computer – and the area is divided into thirds. This is the ‘input,’ the ‘work in progress,’ and the ‘output’ section. You can also refer to them as the ‘to do,’ the ‘doing,’ and the ‘done’ sections.
The areas are further subdivided into different columns (such as development, test, and completed). Similarly, the board is also subdivided into rows, with each row consisting of a person.
Tasks, which are generally put up on sticky notes, move from left to right across the board and get added on the left as they become necessary and dropped off on the right when they’ve been completed.
The great advantage of this system is that you can easily see where there are bottlenecks. Is one person doing far more of the work than other people? Is the work not able to progress because a vital component isn’t getting completed?
I’d venture to say that the Agile methods in large part depend on the accurate and correct maintenance of these boards, so make sure your visual skills are all in order and that you improve your content.
Tracking the Work
Similarly important (and similarly visual) is the way the work that has been completed is tracked. This allows you to measure progress and see if you’re actually ahead, on target, or behind a deadline.
The burndown chart is how the process is measured for Scrum. It basically tracks the tasks that are getting completed on time (with time being tracked along the bottom and the amount that’s done measured along the left-hand side). The chart generally comes with a handy dotted line which shows you how fast you should be progressing. In this way, it’s easy to see whether you’re falling behind or are keeping up with your deadlines.
The Kanban method, in the meantime, measures progress in two ways. These are the cumulative flow and the cycle time. The first of these shows how many items are currently in progress, while the cycle time lets you see how much time is necessary on average to complete a task so that you can extrapolate how long the project as a whole will take.
So Which One Should You Use?
Honestly, the answer is 'it depends.' What does your company need? What kind of projects are you working on? How complex is the task?
For example, the Scrum Alliance argues that Scrum is generally more useful for highly complex projects, as its Sprint focus means that it is better suited to staying on top of a lot of requirements and delivering products when a deadline is due.
The Kanban method isn’t quite as good at that. Instead, it is better suited for teams where you’ve got a steady stream of work that is constantly flowing in and has to be dealt with in a timely manner. In other words, this would work well for if you’re trying to keep a complex piece of software running and removing the bugs that are discovered quickly and efficiently.
Scrumban, in the meantime, is much better suited for smaller teams, as here you’ve got both the flexibility and the deadlines, allowing you to work on creating new software or mechanisms, as well as keeping the business operational. In other words, this might work well in a situation where a small group of people is running a startup and has to do everything together.