I want to release anytime, I don’t want iterations, I want to skip estimation, I have challenges with self-organizing teams, I want to change my priorities,
I need better visualization, I want to process that is more adaptable, Scope creep is my major concern, I am want to handle support tickets, I am afraid of sprint failure and end of picking less work, I can’t break down stories enough to complete within the sprint.
Before I get into details, review below carefully, this would suffice the need for moving to Kanban over Scrum or XP.
- There are teams that have a more responsive nature of work like maintenance, fixing customer bugs, run time day to day requests, etc.
- It may not be a good idea for these teams to plan the sprint or iteration since a lot of activities will become overhead. In addition to that, we need to break the Agile principles for instance constantly adding items to sprint during execution, not doing refinement in advance, accepting back-to-back sprint failure, and more.
- Not doing Scrum does not mean they would not publish the work. They are still expected to commit approx work (Preferably in terms of story points) in a given time period.
- They commit to goals and SLA based on the past data
Scrum is great while the world is not a perfect place. You can always overcome challenges associated with it but if you have another Agile method is even more flexible there is no harm in leveraging that. I see many organizations are switching to Kanban and getting wonderful results. I don’t have the intention to move you from what you have been doing while I am just trying to initiate a thought process and philosophy around Kanban.
Let’s understand the above in more detail with real-time scenarios. A group of project managers gathered to discuss the challenges they have with the existing process with senior management. Let’s look at some of the interesting areas what they have put forward on the table (I am sure you can relate one or more areas if you have managed agile teams)
Project Manager 1: (Team is afraid of Sprint failure) My team has very fewer items in sprint compare to what they can accomplish as they are scared of sprint failure. Despite that, I don’t have successful sprints as one or items roll most times as we get blocked. I can’t allow my team to pick more middle of a sprint
Project Manager 2: (Prod issues; Lot of support to other teams) My team builds new features while I am expected to support some of the other teams for whom we provide back-end services. The requests coming from them is our top priority whenever it’s related to prod for them. The amount of work that comes from different teams vary and we cannot assign fixed bandwidth to deal with those issues. Most of our Sprint we have one of these two situations
- The sprint fails because we need to focus on supporting other teams.
- We are done much before the sprint ends. Pulling new work is not allowed mid-sprint hence we use that time for learning while this is not a great idea all the time.
Project Manager 3: (Support work; Tickets) I have all the support work. The estimation has been a challenge most times. A bug takes a day or a week, it all depends on the product I work for is huge and we have most of the newer members. How can I make sure my sprints are successful and at the same time, we as a team don’t under commit?
Project Manager 4: (Adaptive to more adaptive) My team hates too many ceremonies and processes. They think of having a lightweight process which is more adaptive over-prescriptive, is much better. All of them are experienced/committed and understand their roles and responsibilities.
Project Manager 5: (Time and material; Longer stories; Unpredictable work) We built adapters and I don’t see the benefit of breaking down and doing that in parts. We have a deadline for every adapter and we kept getting blocked. We are fine to wait as we are on the “time and material” contract. Getting blocked from the customer end doesn’t harm as billing doesn’t stop. How do I fit in a work which takes a few weeks to a couple of months?
Project Manager 6: (Frequent priority shift) Our priorities changes very frequently. Many times we literally have to stop what we are working on and start something else. Getting new work done in the next sprint doesn’t help as the work we are doing becomes useless even if that’s completed due to change in priority.
Project Manager 7: (Customer or Sprint success) Our company’s top priority is to manage customers and their expectations while we always focus on velocity and sprint success. This becomes challenging as in order to manage customer priorities, we compromise Scrum priorities or vice versa. Both are not good ideas. In the first option, you are disregarding a process resulting in low team morale and an unpredictable outcome. The later is not acceptable anyway 🙂
Project Manager 8: (The product owner struggles) The PO struggles to lock down the requirements for a week. He keeps adding work to sprint throughout the week, changing existing requirements, and even providing/updating acceptance criteria during the sprint.
Projects Manager 9: (Team experience or complex work) My team has challenges with breaking the requirements or estimating the work. The sprint success matters most to me (Why-Sprint-Success-is-Important). I end up being unhappy most times.
Kanban could be one of the solutions for most of the problems listed above. The comparison of Kanban with Scrum/XP and some of the core frameworks is available here
Sprint success is really important when you talk about Scrum. The Sprint fails due to a variety of reasons like team experience, The challenges with breaking down stories, unpredictable work, Customer focus precedes team priorities, support work, and many other challenges as listed above. Many times either we run too much to having a successful sprint (By means of slogging or patch up work) or do not think of a successful sprint at all. Both are not good options.
In my upcoming blogs, I would be talking in detail about how to use Kanban, best practices, myths, and an easy shift from the existing process to Kanban. Please provide your comments below. This would help me to cover all aspects of my next set of blogs on Kanban.