As the tech industry got its start, we began using a process known as waterfall, and this allowed us to organize our entire technical project on one giant board to get out the perfect product. However, as it turns out, we lose sight of what our customers truly are looking for in their product by lumping everything together and working on it non-stop till completion. This means our finished project may be obsolete, and we then have to start over. Frustrating right?
With the frustration of being stuck to an entire board till the project was finished, many developers clamored for a way to simplify their work process and lower the time it takes to launch code that is potentially shippable to a customer. Agile software development was thus born as a way to lower restrictive barriers and ensure a continuous feedback loop is available to everyone working on the project so that the product being built meets the needs of the customers by the time its finished.
The approach of waterfall was looking at the project as a whole, but you’ve probably heard the saying that:
“Customers don’t know what they want until we’ve shown them.” ~ Steve Jobs
However, scrum would slightly change that statement when viewing the product owners desire to be, “the product owner won’t know exactly what they want, until they are able to see it in action.” Scrum requires development teams to breakdown a product or project into workable pieces that can be completed within a one to four week sprint. The team itself is cross functional and self organized with a product owner for priorities guidance and a scrum master for protection and facilitation.
This allows scrum teams to quickly churn out potentially shippable code within a month at the maximum, but teams usually average out to having around a two week sprint, which means it happens more quickly than with previous methods. The scrum team is thus able to present the product owner with a workable product or feature so that they can ensure their story points meet the desired customer needs before launching. Lets look at a quick overview of the scrum process.
Scrum in Action:
Before the process even starts, the product owner begins creating all the features and needs that (s)he would like to meet with their new product. This is a list or set of descriptions of what (s)he would like to see done during the first iteration of the product, or it may be a vision for the final product that the customer is able to use. When the product owner brings in the scrum team, (s)he quickly realizes that many of their goals may not be doable in one fell swoop so they have a sprint planning meeting to decide what is most important to the product owner and any stakeholders involved.
During the sprint planning meeting, the development team works with the product owner to break down epic stories or descriptions into achievable tasks, and the scrum master facilitates the prioritization and selection of what they can do within the time restrictions of their sprint. Once this meeting is completed, they will be ready to begin, and they might not see the product owner everyday, though (s)he are usually accessible in some way.
After the sprint starts, there can be no changes to the work load that was selected by the product owner and team, and it is the scrum masters job to defer this work into the product backlog until the next sprint. Each day the development team has a 15 minute daily standup where they discuss what they did yesterday, what they’re doing today, and if they have any impediments. This is the best feedback loop in the scrum process and carries over to many hybrids for product development processes.
Some teams may also use test driven development and pair programming from the XP or eXtreme programming development process, and this is another way to include continuous feedback as the team works towards the completion of their product. These two types of programming also raise the quality of their finished product.
Once they have completed everything in their sprint, they are ready for the presentation of their deliverable code to stakeholders, and this allows the product owner, beta testers, or investors to see the workable code and give feedback to make sure the scrum team is on the right track. Lastly (and some argue most important), they have a retrospective meeting to discuss how the sprint went and what they can improve on in their next sprint. Some teams measure velocity or use other metrics to see how they did and if they improved from their last sprint, but the measure used is usually up to the team and their manager.
Below, you’ll find an example of an in-progress sprint to give you an example of how the scrum team works through their process:
So what’s Scrumban, you ask?
Well to answer this question, we first need to go over an even more agile development process known as Kanban. Similar to scrum, Kanban was born out of the agile software development movement where constant feedback and learning are key components of the work process. Scrum limits a development teams work in progress by making them select exactly what they will work on over the next 1 to 4 weeks, and it restricts that work in progress to only items that they can resolve during the selected time frame. What do you think could make this better for the team, product owner, and stakeholders alike?
If you guessed more flexibility, then you’re on the right track! Kanban strips away the majority of what was described above in the scrum example, but it still uses the same layout for the team’s work board. Below is an example of a kanban board in action:
Can you see the difference?
There’s numbers, you say? You’re absolutely right! Each column aside from the Product Backlog area now has a number associated with its title, and you’ll notice that the backlog is listed as being fluid, which means the product owner is no longer restricted to changing the priorities after the development team has started working.
Kanban limits work in progress throughout the entire board by limiting the number of available slots for each column. This means that the team has decided how many projects it can handle at one time for each stage of development, while maintaining a high quality product. The example above would possibly work for a four to five person team. As you’ll notice, the limits on each column never exceed three, and this allows the development team to work at their own self organized pace, while opening up a continuous work flow by allowing the product manager to rearrange and reprioritize cards.
In kanban, the team will measure their progress by how quickly a card moves from “To Do” to “Done”, and this will be done repetitively to get an average number, which allows for forecasting by the product owner. While the meetings we discussed in scrum aren’t necessarily needed, many kanban teams follow a similar meeting schedule though slightly different as the board becomes a working measure on progress, due to it’s fluidity.
So similar you can only tell the difference by tiny numbers in the column!?! Why not combine them!
- Sprint Planning Meeting – held every two weeks or so, the team meets with the product owner to ensure they are still working on top priorities. The fluidity of the board allows the product owner to adjust priorities at anytime by taking something out of the “To Do” list and inputting the new priority from the “Product Backlog.”
- Modified Daily Scrum (or Standup Meeting) – the typical three questions for this meeting are still answered, but the team uses the board and not everyone goes through the questions individually. Now that the items on the board are not static, the team is able to use it as a measure of progress and to view impediments for moving items through to “Done.”
- Retrospective Meeting – held around every two weeks or so, this meeting allows them to review recently completed items and find out if they need improvement in their processes, but this is also something that they constantly work through as they find and correct bottlenecks in the workflow as they occur.
Many teams will also continue to use test driven development and pair programming to keep the quality level of their turn out at the desired high standards, and this is the dash of eXtreme programing that was mentioned above. Overall, the process of implementing scrum, kanban, or scrumban is up to the team based on their environment and the needs of their company. In all available information on the topic of which is best, the top suggestion is to remain lean and agile experiment, fail, and learn to find out what works best for you!
Kniberg, H., & Skarin, M. (2010). Kanban and Scrum: Making the most of both. S.l.: C4Media.
Hundermark, P. (2013, February 6). Kanban and Scrum – ScrumSense. Retrieved July 10, 2015, from http://bit.ly/1HgvPHS
Charron, T. (2012, July 4). Is Kanban the New Scrum? Retrieved June 10, 2015, from http://bit.ly/1grbjOn
Gambill, P. (2013, October 14). Scrumban: A different way to be Agile | Alliance. Retrieved June 10, 2015, from http://bit.ly/1J7gycL
Pahuja, S. (2012, April 8). What is Scrumban? – SolutionsIQ. Retrieved June 10, 2015, from http://bit.ly/1kUij1t