This is one of the frequent questions that I get asked. In many instances, it is posed a little differently – from teams that started with scrum, as they felt they needed a lightweight process compared to more traditional approaches but find it difficult to get the team to internalize the principles and be effective as a team.
The common challenges that teams face include
- Not having sufficient backlog of stories, sometimes even for the current sprint
- Stories being of varying granularity, that some can be completed in a couple of days with some others taking a couple of months
- Stories involving exploration or defects that need deep investigation
- Sticking to strict time boxing of team events [ceremonies] that leave everyone exhausted and distracted from their core tasks
- Teams not finding value in tracking progress [in story points of hours], as the plans are not baselined and updating remaining efforts do not yield much value
- Many ad-hoc or overriding priority activities being introduced pretty much in a daily basis making the team work in a fore fighting mode
- And, equally significantly, the above being thrust on the team by someone outside the team [sales, management etc]
- Teams not having much confidence in retrospectives, as many points come up again and again and even actions identified in a retro stay unactioned
Compared to this, they feel that Kanban is a lighter weight process model, with no defined roles, ceremonies, artifacts other than the board that were ‘prescribed’.
This would help the teams comply with the audits!
Some other teams also feel that having a board gets them labelled as Agile!
Though Kanban appears simple, it requires a lot more discipline to be successfully adopted.
Getting back to the question in the title of this post, from my experience, I would suggest you consider the following and decide if it would suit your teams’ higher goals:
The most significant behavioral change I have noticed is that the team members become more focused on working on their own tasks or tickets and get them to closure as soon as possible. This is very pronounced when they are measured on the cycle times [or lead times] and individual performance is tracked and rewarded.
This is exactly the opposite of what successful Kanban teams are good at! An approach called swarming, where the entire team is focused on completing the issues in the expedite lane, or if there is a blocker that the individual team member is unable to resolve in time.
While this is – debatably – more suited for a reactive customer support types of situations, some of the key benefits of agile teams – such as collective ownership or self managed teams could be impacted.
Of course, I have also seen mature teams that are focused on cycle times, that take up work distribution by themselves in a self managed manner.
Without a formal role such as a scrum master, there needs to be a catalyst for team practices and ensuring that any dysfunctions in the team are effectively addressed in a timely manner.
There could be other aspects such as WIP-limits, a concept that makes Kanban teams highly productive, that may not be understood by teams and hence be causes for bottlenecks or inefficiencies.
When such mismatches lead to team burnout, the disillusionment begins, and teams feel that agile approaches are not suitable for their nature of work.
The challenges listed earlier with scrum teams should be taken up as opportunities for improvement and in many cases that would help the teams to identify their itineraries for improvement.
If, after due consideration, Kanban is more suitable, it is recommended that the team spends some time to arrive at team norms and also the outcome goals – and move to a self managed model to achieve those objectives.
When teams choose to adopt scrumban [a balanced combination of scrum and Kanban], the scrum master can help understand, adopt and internalize the Kanban concepts and techniques.
One variation that teams have adopted successfully is Scrumban with some management aspects of Scrum combined with Kanban – having a Scrum Master, Product Owner, conducting Retrospectives, reviews, backlog refinement and self-organization etc.
This is also kind of Scrumban because Kanban does not prescribe any of these. This kind of Scrumban Iis recommended for all teams starting with Kanban (even if they have done Scrum for a while) as it gives them a smooth transition. All ceremonies and roles of Scrum with Kanban style of delivery – only thing they don’t do is Sprint Planning. So they measure cycle time etc. and over a period of time they can do away with some of these – SM, PO and such stuff if they learn how to swarm to solve blocks and become more efficient.
Once the team is comfortable with the intent of Kanban and team practices are also well understood, they can move to the second variant – where a mix of quick response tickets and slightly longer activities to implement some functionality can be balanced and run in a scrum/sprint like cadence, while using a Kanban model for overall team ways of working.
To summarize:
- You can start your agile journey with Kanban, if
- Are clear about the concepts and the applicability to your context
- You are aware and commit to being disciplined in terms of planning and execution
- You pay adequate attention to the teamwork aspects
- Else
- It may be better to start with a scrum or scrumban model
- Use retrospectives to identify improvements and implement them
- To achieve some breakthrough improvements, the team may transition to Kanban
P.S.
Whether Kanban or scrum, do not forget the outcomes you want to create – which is awesome user experiences with your solutions! More about that in a future post
You may also be interested in some related thoughts from my colleagues AN and Shiv
Related posts:
Role of Product owner in Kanban teams
