How do I get my team to do Scrum?
It’s a question that we hear a lot, and the following is one potential answer from an excerpt of The Scrumban [R]Evolution – Getting the Most Out of Agile, Scrum and Lean Kanban by Ajay Reddy, one of the co-founders of ScrumDo
Although Scrum (and Agile practices in general) are becoming more prevalent in software development, the act of exploring and adopting new ways of working can be quite overwhelming for many teams. There’s a lot of new information to master and a host of emotional impacts to manage (don’t underestimate the influence that emotions have on these efforts).
Some team members may be upset because they perceive the impending effort as an implicit indictment of their previous way of working—that is, a signal that it has been deemed a failure. Others will be concerned about changes in their roles or titles. The range of potential emotions is both wide and unpredictable. You need only consider the kaleidoscope of emotions that most of us feel on the first day of a new job (or a new school year) to gain some appreciation for what’s at play—some anticipation, some anxiety, some doubt, and probably a handful of other feelings.
For these reasons, finding the right quantity of new information to introduce and the right pace at which to introduce it is critical to overall success. Introduce too much too quickly, and you run the risk of bogging teams down. Move too slowly, and the endeavor will be perceived as a waste of time and effort. Though seasoned coaches and Scrum masters will often gain an intuitive understanding of how to strike the right balance, I’ve found Scrumban to be an ideal framework for introducing Agile practices and Scrum to teams. Though every context is different, the general approach outlined in this section has proved successful across a wide range of environments. (Note that this approach assumes there is a seasoned coach working with the team who will come to play the role of Scrum master as Scrum events and artifacts are introduced.)
Whether they choose to acknowledge it or not, teams and organizations interested in adopting Scrum (or Lean and Agile practices in general) are putting themselves on a journey of change. Typically, they are moving from a context that has traditionally assigned success and failure to a limited number of individuals (i.e., project managers and other leaders) to a context where success and failure are collectively owned and shared.
In preparing to embark on this journey, the coach/Scrum master needs to address two levels of context as a first step. The first contextual level is organizational: What are the organization’s pain points driving the effort to change?
- Have there been issues with time to market?
- Is quality a growing concern?
- Has the organization encountered challenges in responding to changing conditions in the marketplace?
Being able to articulate the business reasons driving the need to improve is fundamental to establishing a shared business purpose around which everyone can rally. The second context is local: Which pain points will the team have an opportunity to address as part of the effort?
- Is work seemingly thrust upon the team without regard to the team members’ actual capacity to complete it within the desired time frame?
- Does the team feel isolated from the people who actually use and benefit from what they create?
- Does the team feel impotent about its ability to control or influence how they work?
Identifying conditions the team has a vested interest in improving is an important first step toward minimizing emotional barriers that would otherwise interfere with your efforts.
Even with these contexts defined, however, teams and organizations following a traditional approach to adopting Scrum—where Scrum represents both the vehicle for effectuating change and the change itself—consistently experience significant challenges. This occurs because although Scrum is a simple framework, teams are immediately burdened with learning new ways of working. Changes in habit take time and effort to implement, and it’s fairly typical for new approaches to feel significantly more burdensome, yet less productive as learning curves are traversed. The psychological and emotional impact of this journey cannot be ignored. This is why I find Scrumban a superior framework for introducing Scrum to new teams. Once organizational and team-level rallying points have been articulated, the coach/Scrum master needs to guide the team through a limited number of “new” objectives, concepts, and practices:
- First and foremost, it should be emphasized that the sole objective of this effort is to help the team members better understand how they currently work. The team will decide how to apply their new knowledge to address the organizational and team objectives that have been articulated.
- The team should be provided with a basic introduction to systems thinking, and encouraged to apply this perspective to improve their understanding of their work.
- The team should be introduced to basic mechanics for visualizing workflow (the concept of different work items and value streams). An initial kanban board should be developed from this exercise, and populated with existing work items.
- The team should be introduced to the concept of “pulling” work versus having it “pushed” upon them. This represents the most significant change they will be asked to undertake in performing their work.
- Another significant change to how the team works will likely be the notion of a daily stand-up. Rather than have these stand-ups follow a typical Scrum pattern, however, the team is simply called upon to spend 10–15 minutes each day examining the visual workflow and collectively addressing discoveries. Note this approach doesn’t require the team to learn new concepts (like a product backlog, time-boxed sprints, iterative and incremental delivery of a working product, and other concepts that are central to Scrum). Also, while it’s possible (and preferable) to include nondevelopment functions at this stage (i.e., a product owner), doing so is not essential to getting started. Consequently, teams can be sufficiently oriented in less than a day to continue their present ways of working with minor adaptations that are neither complex nor burdensome.
The coach/Scrum master will use the daily stand-ups and his or her regular interactions with team members to identify opportunities for introducing additional Scrum or Scrumban concepts as appropriate. Although the exact order varies from context to context, I focus on these elements:
- Physical space: Guide the team in embracing changes that can improve collaboration. For example, take down cubicle walls, locate team members in the same physical area (if they have been dispersed throughout a building or campus), locate the information radiator of choice in a central area (e.g., whiteboard, large electronic screen), and incorporate technology to aid collaboration with remote workers.
- Backlog: Though we often think of backlogs in terms of defined products or projects, the reality for many development teams is that they need to address a variety of ad hoc requests outside of product development. I tend to diverge from the traditional Scrum framework here by allowing teams to recognize this work as part of their backlog.
- Creating definitions of done: This definition should ultimately include user acceptance testing (UAT), which will be a challenging change for teams used to having a UAT phase after long design and development phases.
- User stories: Though we start with work items, helping the team develop skills for writing good user stories will improve both flow and recognition of different work items. For application development teams, helping them begin to create work items as user stories that are feature related versus task oriented is a critical evolution to recognizing and delivering value over activity.
- Iterations and related events: Time-boxed sprints and the events around them provide a great structure for fostering a variety of activities that are essential to developing Lean and Agile mindsets. These include the notion of delivering working product on a regular cadence, improving the ways we break down work for execution, enhancing team communication and understanding of the actual work associated with producing any given item, and fostering disciplined approaches to continuous improvement.
Seasoned coaches recognize that events like sprint planning sessions and techniques like team estimation represent mechanisms that can help teams master practices that will improve Lean and Agile outcomes. In my mind, they are akin to the concrete steps to which all new Shu-level learners gravitate. Scrumban allows us to meter the pace at which teams are exposed to these concrete steps, facilitating the process of learning and mastering Scrum.
Neither Scrum nor Scrumban, however, will help teams realize their maximum effectiveness until the end user becomes part of the process. As alluded to earlier, coach/Scrum masters can elect to involve non-IT functions at any point in the process. Nevertheless, there are certain advantages to limiting initial efforts to only the development team. For example, many fundamental practices focus on helping the team better understand and manage workflow, and there’s something to be said for keeping new learners singularly focused on a small number of things without distraction from other concepts.
Once iterations and related events are introduced, however, the product owner’s involvement (and concepts relating to value, risk, and prioritization) becomes essential.
By introducing Scrum practices as solutions to perceived challenges, most teams will have incorporated all of the essential elements of the Scrum framework into their way of working within two to three months. Easing them into the framework in this fashion allows them to gain a deeper understanding of why and how each element fulfills certain functions. And team members will have achieved this maturity with minimal disruption to boot!
With this foundation in place, the team (and organization) has many paths that it can follow to attain further maturity. Naturally, I continue to emphasize maximizing the Scrumban framework to drive this maturity.