Scrum is simple but not easy. This has never been more true than when trying to adopt Agile in a large organization. Large organizations have lots of muscle memory for old habits and processes; many layers with shared services and matrix management; and, often, regulatory requirements and challenges. Given all that, change is hard and it takes time, requiring patience and compromise when adopting Agile and the Scrum framework.
Start moving the needle
Adopting Agile could mean an existing team in transition, a new team forming, or a team that is not all together yet and could include a mix of employees, contractors, and vendors. There are many barriers and impediments in the way of standing up a cross-functional team of five to nine people for an organization that is not very mature in its Agile adoption. With the understanding that we may not be able to see and use Scrum the way we would in a dedicated team in a smaller organization, we have to focus on our smaller victories in an organizational and culture change. We achieve this with a viewpoint of positive change and a full adoption of Scrum in the long term rather than right now.
Move the needle, but don't expect to be going 0–60 mph in four seconds in your first month. Once the Agile adoption begins to gain momentum and the organizational impediments (e.g., budgets, staffing, and contracts) fall to the wayside, helping teams work with Scrum will be much easier. Helping teams think about "being Agile" rather than "doing Scrum" will go a long way toward setting them up for long-term success. I like to refer teams to "Teams, Backlogs, Working Tested Software
," by leading Agile CEO Mike Cottmeyer, to read about the core of what it means to "be Agile." Instead of worrying about whether you are following Scrum to the letter, are you making progress in the three core areas of teams, backlog, and working software?
That’s not Scrum!
Agile adoption in large organizations forces many compromises along the way, forcing us to exist in a world that is not quite ideal. You may encounter situations in which your team is too small or too large, you have more than one product owner, testers are not part of the team up front, you have a team working ahead to research and task user stories, or team members who are continually pulled to do unplanned work.
In each one of these cases, this behavior was a stopgap to a more ideal situation that was able to be resolved later as we gained better alignment with business value delivery. It is much more pragmatic to accept the compromise and ignore the "It's not Scrum" screams for a minute, rather than throw the team out with the bathwater and drop the whole notion of Agile or Scrum. There will never be a perfect time to adopt, with ever-pressing release cycles and commitments, so just jump right in and work through the constraints and help the team focus on being
Agile rather than doing
Constraints, checkpoints, and adaptations
In working through the forced compromises, it’s useful to work out with the team and stakeholders what the constraints are, where you are going to push back to adhere to Scrum ceremonies or Agile principles, and where you are going to be flexible and adaptive. If the team pushes back on things that should be important, have a checkpoint and stop; understand why they do not want to participate or why it may not be adding value to them. Hold regular retrospectives with the managers and stakeholders to understand their viewpoint of their team’s Agile adoption to make adjustments in how they are supporting the teams, and to voice where you feel the team needs to improve. Good leadership that will stand behind you can make these changes easy and seamless so that the team can focus on its own growth.
Keep moving forward
A pragmatic view of these scenarios will help move past these things that don't fit into Scrum, with the hope and goal that they can be resolved over time rather than leaning on them as blockers. And in time, as the adoption grows, you can lean on the team to really accelerate their value delivery. What are the compromises that you have made as coaches and ScrumMasters to get teams moving forward?