First thing first, you may know why Agile methodology exists. And you are right, because we need more flexibility, cardio exercises and executives performing pull-ups while dressed in a power suit.
Okay, maybe I’m talking about a different kind of agile here, rather than the concept that arose from the limitations of traditional project management models such as Waterfall. I am sorry, it happens from time to time..
Of course, everyone knows that Agile came as an improvement for Waterfall, right? I hear you saying – tell me something that I don’t know (and stop talking about office gym!).
Ok, no problem – do you know where Agile originated? Where did it all start? When IT behemoths such as Microsoft struggled to deliver projects on budget and on time, the natural (at the time) question of planning came into focus.
Their conclusion was that they had not planned well and that they needed to plan better for the coming year. Boy, were they wrong.
This was one of the major events in the history of Agile development (Agile was developed before Microsoft encountered issues, allowing companies and teams to be flexible and adaptable to changing circumstances in order to deliver the highest value possible incrementally.
Before we get into the specifics, keep in mind that while Agile methodology is simple, its application is complex, which is why there are so many frameworks available. This is why it is critical to first understand your goals and then choose the right framework for your project (stage).
In this article, I will walk you through a project development example to show you which framework is appropriate for which stage of the project.
Developing Stage – Scrum (Or Maybe Extreme Programming)
Let’s say we are developing a video-streaming platform’s MVP (minimum viable product). We begin by developing a certain minimum number of features that must be delivered via this MVP. What should we do?
For projects where an increment can be planned during a single sprint and when new features are being developed on a project, Scrum can be an appropriate framework. Let’s imagine our features.
For example, the first feature that must be developed is the option to play an uploaded video. Allowing others to leave comments on each video, can be another feature. You might want to include a related video feature as a suggestion for future videos, and so on.
All of these features should be added to your product backlog so that you can work on them sprint by sprint. When you have a list of tasks/features to work on, you can calculate their ROI and execute based on the highest value.
In our case, the ability to play an uploaded video is critical to our platform, so we should prioritize delivering that feature as first increment over everything else. After we deliver that feature, we can move on to the next most valuable feature – the ability to leave comments.
Of course, there may be some changes between sprints that impact how we prioritize tasks. For example, we determine that delivering related videos is not the next most valuable feature, but that improving the comment section is. Therefore, this should be our next sprint goal.
The agile component of the Scrum framework is related to the ability to prioritize all tasks in the product backlog at any time, as well as reorganize tasks within a single sprint. You shouldn’t, however, change the scope of an active sprint, i.e. add new tasks from the backlog or remove existing tasks from that sprint.
Apart from software development, Scrum is also useful for other industries that are undergoing change and have a competitive environment in which to develop products or services.
One example where Scrum can be applied is marketing. Agile marketing is a well-known concept and marketers have been using Scrum to organize their work for quite some time.
For example, you can organize your marketing tasks, such as social media posts, emails, and blogs, in a product backlog and then execute them in sprints. A product owner could be, for example, a social media manager who is in charge of the whole process.
Problems With Scrum
Scrum is not the best framework for handling maintenance projects. But there are potential traps that can trick you into believing that your project is not a good fit for using Scrum. One of the reasons for the belief that Scrum is inadequate can be an inexperienced product owner.
An inexperienced product owner can make a mistake and miscalculate the real value of all bugs and improvements, especially when compared to delivery of potential new features that could bring greater value.
In this case, the PO accepts perfectionism, instead of focusing on real maximum value the product brings to its users. This can occur when a client insists on fixing something that he believes is critical but is not of high overall value.This results in time waste as we fix or improve insignificant things that add no real value.
Alternative to Scrum – Extreme Programming
In projects where Scrum is not suitable since additional programming practices are mandatory, extreme programming is used as an alternative (this applies only to software development projects, obviously).
Consider the development of a payment provider. Here, the business logic is so complex that you require full coverage in terms of automated tests, with multiple developers working on the same code.
In xtreme programming, you are constantly presenting to the customer (a role here). Which is why it is critical to have a suitable customer, as it is the customer who provides continuous feedback on the product.
You are constantly adapting as a result of that feedback, which is why extreme programming is not suitable for projects with a long list of tasks. It’s an iterative process on your main feature or product that is constantly being refined.
One disclaimer: we’ve only seen xtreme programming used in a few cases, which is why we can’t tell you much more about it.
We witnessed the successful application of extreme programming in the development of an internal platform for a large shipping company. Xtreme programming was used to successfully organize their entire development.
However, we have yet to fully understand why this framework was chosen for this project rather than another, because Scrum could have been equally successful in the same environment if some of the xtreme programming techniques had been used inside of the Scrum process.
The company desired maximal test coverage and that could have been achieved with TDD (Test Driven Development), incorporated in Scrum.
They had an internal company representative act as a customer (a role in XP, they were building the product for themselves), which helped them facilitate XP, but they could have achieved the same if they had a good internal Product Owner along with the other internal stakeholders.
High code quality could have been achieved through the use of quality team code reviews or pair programming as part of the Scrum process.
Stability Stage – Kanban
Let’s go back to our platform. Because of our marketing promotion, we anticipate a large number of users on the platform during the first release of the MVP. The most important thing here is to keep the platform stable. Kanban is the right framework for this situation.
Assume you are not currently working on large projects with numerous features, but there are numerous instances where bugs must be fixed on a regular basis and improvements must be implemented. Fixing bugs, making improvements of existing features and so on are the priority now.
Using Kanban in this situation makes sense because we can always reprioritize and work on the tasks that bring the highest value in our case, work on improving the video quality (the priority is determined based on what brings the highest value – check our article on why value is so important in product development).
When we’ve finished fixing the video, we can return to fixing the bugs in the comments section. In Kanban, there is always a list of tasks listed in order of priority and the list is constantly changing.
Kanban thrives in the dynamic environment of the ever-changing priority of work. Keep in mind that Kanban evolved from the Toyota lean process and can be used to implement agile principles.
It is based on workflow management, specifically on visualizing the flow of work, limiting work in progress and emphasizing completion over beginning.
Kanban allows you to change the scope at any time and quickly adapt, whereas Scrum does not allow you to add new things and reprioritize them within a single sprint.).
One of the most important advantages of Kanban over Scrum is speed. This framework encourages you to release the items as soon as you’ve finished them. In that sense, you can deliver bug fixes as soon as they are completed, rather than waiting until the end of the sprint.
Kanban’s metrics are throughput and cycle time, or the number of tickets/work delivered in a given period of time and the time an item travels from To Do to Done on average.
Kanban is best suited for projects where tickets represent admin requests such as adding a new user, setting up deploy, and so on.
Problems With Kanban
Kanban is almost indifferent to the size of a work item. Unlike Scrum, where we always strive to deliver the highest possible value within a release cycle (one sprint), Kanban can prevent you from delivering any work because you were working on a task too large.
A strong and mature CI/CD process is required to obtain any real value from Kanban. If you’re using Kanban to pile up a bunch of done features every two weeks so you can do manual regression testing, you’re not reaping the benefits of this framework.
If we used Kanban for a product with features like playing video and a section for comments that we wanted to deliver in a specific time frame, there is a good chance that we would need to constantly improve our first feature (video), which means we would waste too much time before we could work on comments.
This leads us to our next development stage of our streaming platform project.
Maintenance and Delivering Stage – Scrumban
Ok, we have released and stabilized the platform. Now, we want to continue with having a healthy balance of improvements and delivering new features, what should we use? We should use Scrumban.
As the name suggests, Scrumban is a combination of Kanban and Scrum. By using Scrumban, you can follow a predetermined plan and deliver larger chunks of work while also responding to customer demands or dealing with unplanned tasks that become priorities.
Remember that Scrumban is still a relatively young (in comparison to Scrum and Kanban) and quite advanced framework, so there is no orthodoxy in the sense of a universally accepted guide (even though it all started in 2008 when Corey Ladas published a book about it).
We can imagine different applications of Scrumban. From using Scrumban by means of utilizing the fast lane – taking tasks from the top and pushing them to production as soon as possible without estimates or planning.
However, we can envision a different application in which there are Scrum ceremonies such as Sprint Planning but also pull techniques such as WIP (Work in Progress) limits.
In essence, Scrumban is a hybrid of the best of both worlds, so it makes sense to incorporate elements/practices from specific frameworks that are best suited to your specific needs. You are creating your own Scrumban version of a framework that works best for you.
Ok, so, how can we use it? Again, let’s look at one application of Scrumban through our streaming platform example.
Our platform is now available with all of its features. However, there are performance issues. For example, there are too many people on the platform, the UX is not that great, etc.
All of these issues are values that must be delivered. At the same time, we want to add new features to our platform, such as sharing and playlists.
Scrumban comes into play at this point. We can work on both – we can plan for the delivery of new features while also planning for problems and maintenance issues. How?
Let’s imagine two scenarios. One in which a team works completely in Scrumban, and another in which there are two teams, one for planned tasks and one for ad hoc tasks.
Two Teams
As sprint goals, one team is assigned to planned tasks. This is done to ensure that you stay on track and are not distracted by things of lesser importance. The other team is concentrating on high-priority ad hoc work.
If no new high priority tasks emerge, the team takes high priority tasks from the product backlog and addresses them one at a time. Unlike Scrum, Scrumban allows specialization, so each separate team can be focused on a specific aspect of development.
One Team
Assume we have three developers on our team. We can calculate the team’s capacity, which is 240 hours in this case. We can plan ahead of time for fixing and changing things, which means that the team’s true capacity for the upcoming sprint and sprint goals is closer to 120 hours.
The rest is for maintenance and planned “unplanned” events. If there aren’t many maintenance tasks, we can always take them from the product backlog.
The Bottom Line
This concludes this article, but please keep in mind, my fellow reader, that this is not an exhaustive list of agile frameworks. There are also Crystal, Feature-driven development and similar frameworks.
However, we haven’t been able to see them successfully implemented first-hand which is why they are left out from this article.
Again, Scrum is an adequate framework when you are in the development stage, i.e. when you need to create a new project or feature(s). It is also appropriate for projects where an increment can be planned during a sprint.
If we are talking about software development exclusively, extreme programming can be a replacement for shortcomings of Scrum, when extensive knowledge sharing through pair programming, automated tests, and constant refactoring of existing code are required.
Kanban is best used for project stabilization or maintenance. This is the case when there are numerous bugs or improvements that must be implemented on a regular basis but no larger features or goals are on the horizon.
Finally, Scrumban combines the best of both worlds by allowing you to make improvements to the project while also delivering new features.
You should pick an agile framework based on your needs, not on the opinion of some guy who wrote an article about agile frameworks. Wait, did I just..
If you have a software development project in mind or have any questions, feel free to contact us.
Let’s talk
