Maximizing Scrum

Maximizing Scrum

Maximizing Scrum

-a foundational perspective on ‘scaling Scrum’-

Most organizations that have adopted Scrum are caught up in a (mental) race to ‘scale Scrum’. It is worthwhile considering what drives them, and point out the value in understanding and employing Scrum properly first.

A Compelling Desire to Scale?

Organizations that have been around for a while have grown very complicated and extremely interdependent internal structures. IT and software development work is organized as assembly line work. Many bodies, meetings, hand-overs, resources, deliverables, processes and departments are required in order to produce and release even the smallest chunks of work.

Growth in volume and quantity is seen as the only way forward. The internal structures make it very difficult to produce more work and allow such growth. The investment to produce additional work is spent mostly on the structures themselves, not on the actual productive work.

The existing structures are the root of the problems organizations seek to resolve by adopting Scrum. It is then fascinating to observe how Scrum is expected to match the existing structures.

The reluctance to touch the existing structures results in twisted adoptions of Scrum. The problems impeding increased business agility remain. The benefits to be gained from Scrum quickly crash against organizational limits. The attempts to scale Scrum reflect the past views in which growth was only achievable through larger numbers. The already twisted implementation of Scrum then needs to be scaled to develop more software, faster. The opportunities for organizational healing are lost.

The Scalability of Scrum

The primary potential of Scrum lies not in enlarging capabilities, in terms of quantity and volume, but in improving existing capabilities and capabilities established through a proper Scrum adoption. Scaling is in the teams, not in adding teams, roles and phases.

Much scaling is possible, even within a single team. There IS value in maximizing Scrum first.

The Scrum framework, and its roles and rules, is only the beginning. A proper adoption of Scrum, preserving simplicity, is a gateway to a myriad of options to deal with complexity.

jigsaw
Once an organization crosses the barrier of actually doing Scrum, each element included in or attached to the Scrum framework can be implemented in a basic or a more advanced way. Each step towards a more advanced utilization of Scrum increases the benefits and achieves the goal of scalability.

scale

From a base, even mechanical, implementation of Scrum organizational beauty comes within reach.

This is the sole base to scale the benefits achieved through Scrum. Otherwise only dysfunctions are scaled and reinforced, the dysfunctions that remain unresolved through broken or overloaded implementations of Scrum.

Here’s a (non-exhaustive) selection of options that can be exploited within Scrum:

  • Stop creating low value. Product Ownership in Scrum works better with a mandate to organize, order and minimize the Product Backlog from the purpose to maximize the value
  • Enable cross-functional development. A Development Team works better as a feature team. Feature teams face much less complexity — having all skills in the team to work on all technical layers that need being worked on to deliver Increments of software from and end-to-end user perspective.
  • Help teams grow their effectiveness through improved collaboration. Teams benefit from stability and respect for their autonomy and self-organization to enter a continuous collaborative flux. Stop focusing on tasks, capacity and past performance, and provide teams with compelling goals and objectives instead.
  • Embrace technical excellence. Scrum has no exact prescriptions for development practices. However, the empiricism of Scrum thrives on transparency. Transparency encompasses common standards and agreements against which to inspect and adapt. Engineering standards are a crucial part of that. Engineering standards guide the definition of Done, give focus to a team in getting stuff done, help a team in forecasting Product Backlog for a Sprint, and define quality, create accountability.

Imagine the gain in business agility if, through the above tactical choices, every 2-3 weeks a truly releasable Increment of product is available that can be brought to the market without additional, subsequent cost or work.

Enjoy the scaling effect of maximizing Scrum first. If you run out of such improvements, consider adding teams. Choose wisely where you want to invest in first.

Gunther is a seasoned Scrum professional. He works for Scrum.org, the home of Scrum, where he shepherds the Professional series. He represents Scrum.org and Scrum co-creator Ken Schwaber in Europe.
In 2013 Gunther published the much acclaimed book “Scrum – A Pocket Guide (A Smart Travel Companion)”.
Learn more about Scrum from Gunther’s blog

  • Charalampos Tsitlakidis

    Hi,

    I believe that the core of the Agile concept is founded on effective, face-to-face communication, close collaboration and flexible self-organizing teams. In that context, a question that will probably arise, is one that concerns the suitability of the Agile mindset in large, geographically dispersed projects.
    But, according to Highsmith (2010), the questions that in that case should be asked are: “At what size does delivering value to customers fail to be important?” and “Can large organizations afford to be inflexible, rigid and unresponsive?”.

    In the context of the globalized, new economy, where outsourcing and Global Software Development (GSD) are usual practices, Agile frameworks such as Scrum, are facing the challenge of being an adequate tool for the situation.

    In the light of the above, several models have been proposed in order to address Scrum scalability issues, particular in distributed projects. Some of them are:

    Isolated Scrums, where teams are geographically isolated and not cross-functional and usually Scrum practices are not applied in great extent.
    Distributed Scrum of Scrums, where teams are geographically isolated and a Scrum of Scrums is used for their integration and regular meetings are being held across different locations.
    Totally Integrated Scrums, where Scrum teams are cross-functional and their members are spread in different locations while the Scrum of Scrums is being held on a particular place.

    Regarding the Distributed Scrum of Scrums model, Scrum cross-functional teams are isolated and independent while Scrum Masters are meeting on a regular basis and on different locations. These meetings serve as a linkage between teams and promote the establishment of the required communication and collaboration framework. Distributed Scrum of Scrums is best suited for teams with relatively little Agile experience.
    In the case of the Integrated Scrum model, the teams are fully geographically dispersed with a number of members from every team working at different locations. In such an environment, the Daily Scrum meetings are helping on removing cultural and organizational impediments. This model is aiming at more experienced Agile teams where a large scale project can be managed as a whole due to the tight integration methods that are being applied.

    Finally, I would say that despite the particular challenges and issues that may arise on a distributed Scrum project, the main driving force, motive and strategic goal remains the same as for every other Agile project: it is all about change, innovation and delivery of business value.

  • http://www.blendo.co George Psistakis

    IMHO Spotify are the “masters” at scaling “Scrum”. This post made my search a bit and I found an interesting post: http://www.scruminc.com/scaling-scrum-what-people-are-not/
    Thoughts?

  • http://agilegreece.org/ Agile Greece

    Comment from Charalampos Tsitlakidis:

    Hi,

    I believe that the core of the Agile concept is founded on effective, face-to-face communication, close collaboration and flexible self-organizing teams. In that context, a question that will probably arise, is one that concerns the suitability of the Agile mindset in large, geographically dispersed projects.

    But, according to Highsmith (2010), the questions that in that case should be asked are: “At what size does delivering value to customers fail to be important?” and “Can large organizations afford to be inflexible, rigid and unresponsive?”.

    In the context of the globalized, new economy, where outsourcing and Global Software Development (GSD) are usual practices, Agile frameworks such as Scrum, are facing the challenge of being an adequate tool for the situation.

    In the light of the above, several models have been proposed in order to address Scrum scalability issues, particular in distributed projects. Some of them are:

    • Isolated Scrums, where teams are geographically isolated and not cross-functional and usually Scrum practices are not applied in great extent.

    • Distributed Scrum of Scrums, where teams are geographically isolated and a Scrum of Scrums is used for their integration and regular meetings are being held across different locations.

    • Totally Integrated Scrums, where Scrum teams are cross-functional and their members are spread in different locations while the Scrum of Scrums is being held on a particular place.

    Regarding the Distributed Scrum of Scrums model, Scrum cross-functional teams are isolated and independent while Scrum Masters are meeting on a regular basis and on different locations. These meetings serve as a linkage between teams and promote the establishment of the required communication and collaboration framework. Distributed Scrum of Scrums is best suited for teams with relatively little Agile experience.

    In the case of the Integrated Scrum model, the teams are fully geographically dispersed with a number of members from every team working at different locations. In such an environment, the Daily Scrum meetings are helping on removing cultural and organizational impediments. This model is aiming at more experienced Agile teams where a large scale project can be managed as a whole due to the tight integration methods that are being applied.

    Finally, I would say that despite the particular challenges and issues that may arise on a distributed Scrum project, the main driving force, motive and strategic goal remains the same as for every other Agile project: it is all about change, innovation and delivery of business value.

  • Pingback: Maximizing Scrum - Agile Greece | All about Agi...()