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 forwarded 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 have 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 feature 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 which 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 times.
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, all depends as the product I work for is huge and we have most of 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 “time and material” contract. Getting blocked from customer end doesn’t harm as billing don’t stop. How do I fit in a work which takes 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 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 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
The Sprint success is really important when you talk about Scrum. The Sprint fails due to the 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. In many times either we run too much to having successful sprint (By means of slogging or patch up work) or do not think of 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 existing process to Kanban. Please provide your comments below. This would help me to cover all aspect in my next set of blogs on Kanban.