InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Don't Worry About Scaling Scrum

Posted by Vikas Hazrati on Apr 21, 2008

Sections
Process & Practices,
Architecture & Design
Topics
Methodologies ,
Adopting Agile ,
Agile
Tags
Introducing Agile ,
Scrum ,
Scaling Agile ,
Self-organizing Team
One of the first questions asked when Agile is introduced to an organization is about scaling. Tobias Mayers put his thoughts in his blog post where he suggested that organizations should not worry too much about scaling Scrum. If they have built a strong foundation with the correct set of Scrum practices then Scrum will scale on its own. Adopters tend to focus on quick solutions to complex problems without understanding the basics. People seem to focus too much on scaling right from the start; they should instead embrace the principles and practices of scrum to gain a deep understanding of the methodology first.

Tobias mentioned:
I believe Scrum to be self-scaling. By that, I mean that Scrum contains all the elements required for handling complexity: self-organization, empiricism, prioritization and timeboxing.
He suggested that, once everyone on the team understands the principles then, Scrum Masters can take a back seat and let the self organizing teams manage the scaling.

He draws an analogy with the movement now known as Alcoholics Anonymous where it started with a small group of people trying to recover from the obsession of Alcoholism and grew into a world-wide movement, comprised simply of members who worked together, who did not have therapists, counselors or leaders.

He suggested that these groups were formed on the basis of common need, they worked together till the need was satisfied, and then they dissolved. The suggestion points to the fact that, in a similar way, Scrum teams would get formed when there is a need, work in a self organizing way and dissolve when the need is fulfilled. When there is a need for it, the group would decide to split into separate scrum teams, where they would be self-organizing and work towards the project goal. The role of a Scrum Master would be gently guide the group to team needs rather than influence the group with his own perceptions.

Tobias compares a few core principles of AA which can apply to the scaling of Scrum
Among the guiding principles in these “traditions” are the following:
  • Our leaders are but trusted servants; they do not govern
  • Each group should be autonomous except in matters affecting other groups or AA as a whole
  • Each group has but one primary purpose — to carry its message to the alcoholic who still suffers
It will easily be seen how such principles can apply to the scaling of Scrum:
  • Our leaders are but trusted servants; they do not govern (no change there)
  • Each Team should be autonomous except in matters affecting other Teams or the organization as a whole.
  • Each Team has but one primary purpose — to build an increment every iteration and deliver it to the Product Owner (who is possibly suffering!)
He concluded by suggesting that instead of ignoring the analogy and dismissing it as non-relevant, agile teams should try to learn from the similarities. The main point is that instead of worrying about scaling upfront, adopters should take care in laying a solid foundation in terms of principles and practices of Scrum. Once that is done the self organizing Scrum teams will take care of scaling on their own.
  • This article is part of a featured topic series on Agile

Related Sponsor

In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!

No comments

Watch Thread Reply

Educational Content

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.