I recently accepted a Scrum Master position at a new company and I was preparing for this change, I started thinking about what it would mean to be a full time Scrum Master day to day. In my previous role, I wore many different hats, which included Agile Coaching and Consulting, but it seemed like it would be much different to actually be implementing changes and helping a team grow as opposed to providing advice from the outside.
1. Not focusing on Culture
Adopting Agile at an organizational level is something that will take a long time, bring about change throughout every level of the organization, face many difficulties, and require a great deal of experimentation and learning. In order for all of these to be possible it is not enough for an organization to simply adopt the practices of one of the many Agile frameworks that are currently available. This will lead to (maybe) some short term successes and some initial enthusiasm, but it will not setup the organization to sustain their Agile adoption over the long term. In order to really get a transformation to stick, the entire organization must experience a cultural shift that will encourage, support, and enable a focus on learning, failing, inspection, adaption, and continuous improvement. With the right culture in place, it will not matter what frameworks or practices the organization tries to adopt because they will be comfortable with trying many different things, continuing to focus on improving, and sustaining improvements over the long term.
A team member once came to me and said that they’re team was currently using Kanban, but that they wanted to switch to Scrum. When I asked why, their response was: “we need the two week time-box, because in Kanban everything goes into the in-progress column and just stays there”. There are clearly many issues that would need to be addressed in this statement, but one that is very important that seems to be ignored on a regular basis is: WIP Limits.
One of the most well-known aspects of many Agile frameworks is the iterative nature of the delivery of working software. The Agile manifesto states: “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” The key phrase here that many teams seem to struggle with is “with a preference to the shorter timescale”. The Scrum guide states that sprints can be from 2-4 weeks. This is a little bit better, but many teams still gravitate towards the longer end of that range and end up attempting 3-4 week sprints (Although I am using sprints as recognized in Scrum for most this article, I believe the content and practices that follow can apply to any Agile framework).
Scrum and Kanban are currently two of the most popular ways to implement Agile practices within software development teams. Scrum has prescribed roles and ceremonies and focuses on delivering small batches of potentially releasable work in short time-boxes. Kanban focuses on visualizing work, flow, and limiting work in progress. Both place an emphasis on continuous improvement. Both have been shown to be effective, but the question many teams face when starting to adopt Agile is: which one should we use? Teams often get hung up on deciding and in many cases select a framework which may not suit their team or environment. Or even worse, they will switch when the framework they chose isn’t working as well as they had hoped, without giving any thought to the underlying cause of their problems. Taking the following factors into consideration when deciding which one will be best for a particular team will help to ensure that the team is set up for success.