Scrum Do’s and Don'ts – Tips for Beginners and Veterans

Eugene LaiMon, 10/08/2018 - 16:16
Subject

After working with and coaching many Scrum teams, I still find it interesting to see how the Scrum framework is applied in a variety of different ways. At its core, Scrum is very simple, but for some reason, many teams decide to come up with their own creative interpretation of how to leverage the simple structure and make it into something unexpectedly complex and unwieldy, and losing the benefits in the process. In this article, I will share a few tips for both beginning Scrum practitioners as well as seasoned veterans.

DO…

  1. Start fairly quickly and adjust based on real experience – Teams that are new to Scrum often over-analyze the mechanics of “how” to do something and get stuck in debates that are not very helpful. Scrum was designed for simplicity, which means teams should learn the basics then get going from there. Keep things as simple as possible and avoid getting stuck overthinking things like “how long should our sprints be”, or “what tools should we use to track work”. Leverage the Retrospective intelligently to evaluate how thing went, then make adjustments and keep learning and adapting.
  2. Manage stakeholder and customer expectations, early and often – Whether you are part of a brand new team or seasoned team of Scrum experts, expectations regarding your team performance is a critical part of everyone’s responsibility. While you may feel that releasing working product consistently is all that you need to do, sometimes stakeholders do not see things in the same light. This is where a tactful Product Owner will help the team clarify goals and expectations and make sure that the team is maximizing the value of their contributions.
  3. Always keep learning and improving – Often times, a seasoned Scrum team can reach a point where they believe they are performance at the peak of their abilities. Even so, this team can still continue to learn and improve. Some may argue that there is a point of diminishing returns when it comes to continuous improvement at the team level. This may be true for some teams, but the net benefit does not necessarily come from any visible, tangible output, but the mindset of relentless pursuit of improvement. If a team stops to learn, or loses the desire/motivation to always get better, then this team is putting itself at risk of degradation. It may not happen immediately, but losing the desire to improve will likely lead to negative outcomes eventually. There is always something new to learn; even if a team has mastered Scrum at the team level, it may be time to explore scaling Scrum across multiple teams within an organization.

DO NOT…

  1. Customize Scrum for the sake of “doing it our way” – Many teams I have worked with decide to alter the frequency of nature of various Scrum events for different reasons. One team that asked me for help had decided to run Daily Scrums twice a week because their management frowned upon so many meetings taking place. Another team chose something that many teams tend to do – stop doing Retrospectives altogether because they were not getting any value from them. The founders of Scrum skillfully architected each event to serve a specific purpose, so it is generally not advisable to alter any of these events without incurring negative effects. My recommendation: follow Scrum as it is stated in the Scrum Guide, commit to it, learn from it, and make a real effort to make things work.
  2. Try to scale Scrum too soon – Some teams rush to scale or grow their Agile practice due to organizational pressures or market trends. There’s a risk to scaling Scrum prematurely – poor practices are more likely to cause bigger negative outcomes to surface if an organization is not ready to manage the increased level of complexity that comes with scaling Agile. My recommendation: master the basics, build the foundation, seek advice from proven experts before attempting to scale Scrum. Trying to build a skyscraper on a shaky foundation can lead to unintended consequences down the road.
  3. Publish metrics that lead to undesired behaviors – Many organizations rely heavily on metrics to gauge team or project performance. In the Agile world, metrics are typically very visible and often misused. It’s important to be mindful when utilizing metrics to measure performance of a Scrum team, especially in an environment that has multiple teams. Some management folks tend to measure teams against each other, which is important at times, but must be managed cautiously. If you start comparing team performance in terms of “Story Points Completed”, you may inadvertently encourage your teams to arbitrarily adjust their point scale, in effect, gaming the system, in order to present themselves in a positive light. It is not my intent to declare that all teams would purposely deceive or break rules. However, this dynamic is something I have experienced myself and may very well occur if left unchecked.

In summary, all Scrum teams regardless of state of maturity can and should invest time and energy to continuously reflect on how they are doing, identify opportunities to improve, and make a commitment to sustain their performance. The world is becoming an increasingly more complex and competitive place, so survival depends heavily on how organizations and teams can adapt.