Scrum Scaled for Large Projects and Organizational Initiatives


Ken Schwaber’s point of view on scaling Scrum. With a smile I’ve read Ken’s comment: “Lately, we have watched with amusement and then growing concern as the methodologists have rolled megaprocesses they assert are the silver-bullets to scaling.”

Growing concern, I must concur. As well, I experience how organisations are struggling and seeking how to scale scrum. Recently, Gunther presented the issue at #atbru (Agile tour Brussels) in his talk “Empirical management explored”.

My observations:
* Organisations not yet able to decently organize Scrum at team level, should not embark on a journey to scale Scrum beyond that team level.
* If such organisations do attempt to scale Scrum, they will scale dysfunctions.
* Organisations still stuck in the classic management paradigm are steer-less seeking to get product creation organised in an incremental and iterative way, still mixing it with many waterfall practices (predictive long-term project planning, absurd guesstimates, lack of transparency, …). On the way, they end up with a self-defined framework; mixing it all up.

The bottom line is:
* Invest wisely to get organized to transform your teams to Scrum
* Invest wisely to maximize Scrum at team level, and next with multiple teams, and next with multiple products > this subsequent growing approach is the sound approach to scale
* Live and breathe the Scrum Stance and agile values
> Invest in people and teams
> Manage and plan based upon real metrics and evidence
> Focus on business value

Scrum Scaled for Large Projects and Organizational Initiatives

1 Comment

  1. frederik says

    These days, “Scaling” Scrum is a widely discussed topic in the Agile and Scrum community. Recently I’ve attended the “Scaling Agile” conference in Brussels (organized by Agile Consortium Brussels) – the conference was filled with thought leaders on the topic. is pitching their vision on scaling Scrum as “Scaling Professional Scrum” ( is organizing courses). Scrum Alliance is pitching their vision on scaling Scrum as “Scaling Scrum” (Scrum Alliance will also be organizing courses soon).

    Interesting how the 2 main Scrum organizations ( driven by Ken Schwaber and Scrum Alliance driven by Jeff Sutherland) are sprinting to publish their vision on the topic and getting their courses ready. (Sometimes I wonder, do these two align sometimes?)

    On the other hand, is “Scaling Scrum” new?

    – The first version of the official Scrum framework has been published in 1995 (two decades ago)
    – The agile manifesto has been published in 2001 (almost a decade and a half ago)

    Is it only recently organizations are trying to scale / apply Scrum to multiple teams, multiple products, multiple projects? Obviously not. In fact, Scrum always has been scalable.

    Organizations have been adopting the principles, but adapting the practices to fit the needs.

    Definition: “Scaling” agile addresses the need when an organization wants to interconnect multiple agile teams to build 1 (or multiple products) or projects (in an agile way). Think of it as an agile team of agile teams. (fill-in ‘agile’ with ‘Scrum’ at any time you’d like).

    1/ Scrum (by definition) is for 1 team (standard Scrum, 1 product backlog, 1 team, in a serial way, sprint after sprint)
    2/ Multiple teams (apply standard Scrum to multiple teams working in parallel , 1 product backlog)
    3/ Scaled Scrum (standard Scrum, multiple teams in parallel, 1 or multiple (derived) backlogs, and an integrated product increment, sprint after sprint)

    At Agile Tour Brussels 2014 and Scaling Agile Brussels 2015, I’ve seen Gunther Verheyen ( talking about the topic. It basically boils down to the following:

    Make sure you get your (Scrum) basics right, live by the agile values and principles, and perform your work professionally.

    What do we mean by professionally, or ‘Professional Scrum’ as names it?
    – Do not only know the Scrum principles, but make it work to the Agile mindset. Scrum outperforms when it has become an optimum of a Scrum team, true agile values, and driven by empiricism (= fact-based decision making).
    – Do now only perform Scrum, but perform it in a professional way. Good engineering standards, practices, tools, methods are needed and required to be able to build a truly potentially shippable product increment at the end of each sprint.

    In fact, the result is a state of ‘high performance or productivity’, moreover ‘hyper performance or productivity’.

    The bottom-line: do not start to scale Scrum to multiple teams on a same product, if you are not able to:
    – Scrum in professional way on a team level
    – Coordinate multiple Scrum teams work together to produce a potentially shippable product increment, sprint after sprint

    I think I got the basics right.

Comments are closed.