Is Spotify-ing your business the only way forward? Is Agile a binary option like you’re in or out? And what if you scale up the agile way of working while an inspection on team level would reveal many deviations from the theoretical or original setup? Is your company pride based on false assumptions? Let’s dig into these questions.

Agile ≠ Scrum

Scrum is just one of the agile frameworks out there to support complex product development. Scrum is a lightweight framework with a limited set of roles, events, and artifacts. An agile team or other organization needs more than a process framework. Behaviors, principles or values, and tools are important as well. Scrum itself will not make you agile, neither does a tool like Atlassian’s JIRA, a mandatory in-house training or certification of all your former project managers as professional Scrum masters. A tool, process or technique is there to help you, guide you. Adherence to principles like the ones in the Agile Manifesto, as well as daily visible behaviors that enable your team(s) to produce and improve are key. Remember that the Agile Manifesto is not defining Agile. It’s a manifesto of shared convictions expressed by a community of representatives of iterative and incremental software development methods and frameworks. There’s no owner of agile, or independent supervisor determining who is and who is not agile. So, no one can blame you or excommunicate from the “agile community” if you:

  • Apply the Scrum framework outside software development by a single team.
  • Use other tools than Atlassian’s for product breakdown and planning.
  • Enhance the Agile Manifesto e.g. taking it beyond the realm of software development.
  • Admit being on a journey becoming agiler.
  • Reserve Scrum for complex product development, and apply different processes or practices for business-as-usual, complicated or chaotic contexts.

16 pages of Scrum theory are incredibly difficult to practice

Whether you like it or not, the 16 pages of the Scrum Guide define Scrum. “This Guide contains the definition of  Scrum. This definition consists of Scrum’s roles, events, artifacts, and the rules that bind them together.” If you want to bend these rules or deviate, be honest about it. Any Scrum master or critical observer knowledgeable of the same 16 pages of rules, is fully entitled to confront you with your choices. There is a reason for Ken Schwaber and Jeff Sutherland to state that they “developed Scrum; the Scrum Guide is written and provided by them. Together, they stand behind the Scrum Guide.” “Scrum is:

  • Lightweight
  • Simple to understand
  • Difficult to master,” and

“Specific tactics for using the Scrum framework vary and are described elsewhere.” Other books, presenters, practitioners may publish and share their tactics, practices, lessons learned about the way they actually use the Scrum framework. It’s just like a soccer team being coached, instructed, and rewarded to play the game in a specific way. Rules for soccer are a given, selection of team players, playing style, training schedule, salaries, clothing, sponsorship, involvement of fans, etc. are open and will vary among teams and countries. Be aware of the difference between tactics for using the Scrum framework and deliberate choices to play a different game. My client organization wants to check the knowledge of Scrum, throws in weekly quizzes with questions like: “What are steps involve in Scrum Cycle?” Unfortunately, there is no none-of-the-above option to answer this question. Scrum, like other frameworks based on empiricism, has three pillars: inspect, adapt, transparency. In the Scrum Guide steps are non-existent. There is no predefined sequence. Transparency should be there 24/7. Inspect and adapt is at the core of the Scrum events (Sprint planning, daily Scrum, Sprint review, Sprint retrospective). Planning is both at the beginning of the Sprint during the Sprint planning event, but also answering the second question in the daily Scrum, as well as throughout the day as progression is made, impediments are encountered, and other products are completed faster than expected. If you want to have a sequential step-by-step approach in place, like the Plan-Do-Check-Act (PDCA) cycle, you’re using a different framework, and have to face the consequences. You will only inspect finished products by quality review techniques, adapt only after a close inspection of delivered products. Everything can and must be planned before being produced. I’m not against PDCA, but Deming is not Schwaber or Sutherland providing us Scrum.

What about deviations on team level when scaling up?

Consider this real-life case:

  • Multiple product owners interact with a single Scrum team.
  • Many in-depth discussions occur during the daily Scrum. The three questions development team members should explain themselves are forgotten or left to the Scrum master to pull from them.
  • It takes multiple Sprints to deliver shippable software and mandatory documentation. Story points are only counted for when a User story is done. A burn-down chart is not used at all.
  • Every 2–3 Sprints team composition changes.
  • The team is highly dependent on providers and consumers of the products they deliver.
  • No stakeholders are invited to the Sprint review. None or only a selection of the products are demonstrated.
  • Even after 16 Sprints daily Scrum meetings don’t start and end in time, people joining and leaving throughout the meeting, and audio connections are still bad, despite conference call tools being available.
  • No velocity is measured, no reference user stories for estimating are available.
  • Updating tasks for product backlog items in JIRA is still not common practice among development team members.

Will scaling up resolve or increase these problems? Let’s revisit the soccer team. When our son was around eight, he and his fellow team members basically didn’t know how to play the game. They simply went after the ball, all of them, all the time. Later, they learned to listen more to the referee, play a certain position, and become better soccer players, both individually, and as a team. If you play soccer in name only, you will lose all the matches, except for a few in which you are very lucky. In my opinion, the same applies to the play of Scrum. If you don’t know how to play it according to the rules, you’ll lose the matches. Your product owner and other stakeholders will not benefit from your free-format sandbox level play. Where other teams behave predictably, you don’t. And where other teams improve their process, competencies, and productivity, you still struggle with basics. Be honest, you’re not ready for the big game. It’s Agile in name only, nothing to be proud of.