Scrum, Kanban, Test Driven Development (TDD), Scaled Agile (SAFe), and the list could go on when it comes to agile software development methodologies a team could adopt. The general candidates are Scrum for new feature development and Kanban for the maintenance teams when building an effective agile process. However, I have worked with contemporary methods like Design Thinking, User-centred Design and Service Delivery while implementing Scrum & Kanban effectively with my product teams.
Scrum: The age-old titan
In my adolescent days of the Agile journey, I learned that you need to follow three things when you do Scrum:
- It would be best if you did not change the sprint plan during the sprint
- You always estimate using story points
- You have to deliver something that stakeholders can review
How true these held up, I will be sharing in the paragraphs that follow.
Kanban: The no non-sense process
Kanban is the visual approach to work in progress (WIP) based on priorities without having any time-bound planning and, thus, more welcoming when changing commitments. In addition, it does not have the complexities of having multiple roles or prescribed sets of meeting that Scrum consists of.
Why even bother?
The general notion is that Scrum works well as the team gains maturity and you keep course correcting. For example, after working with boutique IT service firms through a BFSI major, I joined a UK based start-up. Since the team was reasonably new, it was on me and the management to establish the processes that could work best for the team members. So we first started the whole team under a single scrum routine that would include any features the team is working on or the issues handed over by the support team via our clients.
We quickly realized that this would not work owing to the different pace and requirements for a standard feature development team and members working on the maintenance tickets. So we divided the group into two sections – New Feature Development who will continue using Scrum, and Rapid Action Team (RAT) who will have a Kanban board for the support issues. During the year we implemented the new process, I noticed that team is generally revolving around the same velocity, more or less. A few bottlenecks are coming up every time we do a retro or during the daily stand-ups.
Identifying the bottlenecks of Scrum
Take an example of going to an ophthalmologist where he tests your eyesight and finds it weaker than usual. He then offers his spectacles to you while suggesting that these have worked for him for the past five years, and he is pretty confident that they will work just fine for you. Weird, right? How was he expecting that something that worked for him would work for you too? The same is the case when you intend to set up a process for your team, whether it is Scrum, Kanban, SAFe or anything else.
After working with boutique IT service firms through a BFSI major, I joined a UK based start-up. Since the team was reasonably new, it was on me and the management to establish the processes that could work best for the team members. We first started the whole team under a single scrum routine that would include any features the team is working on or the issues handed over by the support team via our clients.
We quickly realized that this would not work owing to the different pace and requirements for a standard feature development team and members working on the maintenance tickets. So we divided the group into two sections – New Feature Development who will continue using Scrum, and Rapid Action Team (RAT) who will have a kanban board for the support issues. During the year we implemented the new process, I noticed that team is generally revolving around the same velocity, more or less. A few bottlenecks are coming up every time we do a retro or during the daily standups.
Push Oppression
Having a plan is the essence of Scrum, but that leads to pushing more tasks towards the developer to achieve the sprint goal. For example, during our stand-ups, people seldom pointed out that they felt stressed, especially in the last week of the sprint, to deliver on the sprint commitments they agreed on during the planning session. At first, it seemed like a planning issue, and we tried different permutations and combinations to tackle that. However, it took me some time to realize, but I found out people were losing focus on their tasks instead of delivering on the plan.
Task Haywire
A constant concern that was coming up from the team during the retros was that we were changing commitments too often, and the Scrum rule book says that we need to commit to a sprint. However, it also suggests that the standard procedure is to push back the stakeholders, explaining why the current tasks are more critical or will add more value. Then, if they are still adamant, you pick the new priorities and remove some from the current sprint to balance out the working bucket. Being a start-up product company, you need to compromise on commitments to make the existing clients happy or pick up the piece of work that could win us a new client over our competition. However, the production team did not like it whenever we tried to switch the plan as they could not anchor their thought process when asked to pick up different tasks that we agreed on after a 2-hour rigorous planning meeting.
Estimation Faux pas
This one is classic; there is a 50% chance that your estimations will fail during the sprint when you realize more than what meets the eye, but that could go up to 99.99% when you re-plan in the middle of the sprint to align with changing priorities. Remember my top three things I mentioned about Scrum, one of them is story point estimation which is a cornerstone of being a Scrum team. You estimate tasks by judging the complexity using comparison and not specifically the person-hours. Story point estimation has been a debatable topic for years now, and ultimately, I learned what works best for the team.
When Scrum met Kanban
While the Scrum team was fighting the constant battles, I noticed that the team Kanban is pretty happy as they did not have to stick to a plan. They used to pull tasks from the board based on the defined priorities and estimate on an assignment basis. However, they always needed someone to maintain healthy levels of work in progress by weekly meetings to discuss impediments or any changes in the current scheme of things.
I had an epiphany that we always had the solution in front of our eyes, but we passed on it. So why can’t we import Kanban values into the Scrum affair? They seem to be the answer to many of the issues my team is facing currently. If you take the plan out of Scrum, you mostly have a Kanban team that will help, ultimately lead to losing focus on the product roadmap, and team members will focus only on task to task basis. I did not want to sacrifice the sanctity of working towards achieving the product vision that has taken me months to align my team to.
I researched and learned about a new Agile baby that took birth after marrying Scrum and Kanban; welcome “Scrumban”.
Scrumban is something that I can work with, at least experiment and see how it works with my team.
The experiment
After a few discussions with the management, we had an official go-ahead to try out the new process. So here are the steps I took to inject Scrumban into our system:
Focus one day at a time: Instead of having all the team members stuck for a couple of hours to frame a plan for the next two weeks, we started using daily stand-ups to share focus for the day aligned to the sprint goal. It bought the team members what they need to achieve today rather than worrying about delivering on a sprint plan.
Sprint connects versus planning meetings: I introduced a mid-week meeting of 15-30mins (depending on team size) where we would involve only the people who are part of a particular new feature development or are needed to mitigate risks and dependencies. We remove full-fledged planning meetings from the calendar for two reasons:
- Planning meetings could sometimes extend to hours and hence add to the combined downtime for all the members
- Nobody had the feeling they wasted 2-3 hours they invested in a plan only to change it later
Scrumban boosters
Pull Democracy
Having Kanban like approach towards tasks handed the control to the participants, ultimately assisting them in moving away from the push pressure to a more pull-based workflow. As a result, it is them who now sits in the driving seat rather than being a passenger of a “plan” car.
Task In-Order
Sprint connect meetings freed everybody from the shackles to sit out a whole planning and grooming session and instead spend 15-20mins to discuss their actual issues and progress during the week. It also becomes a conduit for introducing any changes in the plan, which the team is more adaptable to take up as they were working with a daily focus and not the pressure of delivering the whole sprint.
Adaptable Estimations
The team has to share estimations based on the day’s focus and not the whole sprint, giving them a chance to inspect and adapt within a day rather than reaching the second week of the sprint only to know their estimations were flawed.
Another advantage of the Scrumban is that it frees the Product Owner and Scrum Master from filling in their obligations of facilitating everything for the team. Instead, the group becomes proactive to achieve their daily focus, ultimately leading them to be high-performance teams.
Conclusion
- Since Scrumban is an amalgamation of two of the most popular processes like Scrum and Kanban, it becomes very intuitive for the team resulting in less or no resistance from the team members.
- Scrumban breaks the general notion of Scrum by not having mandatory meetings every week while still maintaining transparency in terms of the workflow, provided your team takes full advantage of daily stand-ups.
- To sum up, Scrumban picks the best of both worlds and offers an alternative process that could be more feasible for a team where you need more flexibility which was the whole context for my team. Feel free to share your comments on what issues do you face and if you think that Scrumban could be an answer to your problem or not.
