3Back:

I had the pleasure of attending 3Back consulting’s “Scaling Scrum with Scrum” training last week with Dan Rawsthorne.  It was an EPIC day due to the dense amount of information provided, philosophical analysis completed, and a very worthwhile way to spend eight training hours.  I also completed my Certified Scrum Product Owner training with 3Back’s Doug Shimp because, as a repeat customer, I know Doug and Dan present more than one perspective, offer their personal experiences to the mix, and drive collaborative discussion.  There is no one way to Scrum, and 3Back gives a broad yet practical introduction to the debate.

Frameworks:

The fundamental element of Scrum is the Well-Formed Team.  Philosophical Scrum, your Scrum 101, might make it easy to gloss over this building-block of Scrum – there is an immense amount of information to cover and the importance of the Well-Formed Team is quickly lost on the beginner.  However, after three years of driving Agile, Scrum, XP, and Lean in various organizations, I must reiterate:  the need to build on the Well-Formed Team as a paradigm cannot be overstated.

What does a Well-Formed Team – a “Scrum” in the truest sense, huddling around a problem to solve – look like?

• It is Self-Organized:  No one on the team directs the work of anyone else on the team.  Everyone is self-started, self-directed, and accountable for their commitments to the Product Owner
• It is Self-Contained:  We often call it “cross-functional” but this is insufficient.  A truly well-formed team has every resource it needs in one room, ready to solve an issue on a whiteboard together.  The members value working together as a team, work constantly to improve, take pride in their “chores” (effort not directly involved in completion of committed backlog items), take seriously the due-diligence and appropriate standard of care for the product increments that are built for the stakeholders and users, and practice this excellence with complete integrity as professionals.

This Well-Formed Team is completely self-contained – every discipline necessary for working software is in a room, sharing a proverbial pizza.  Pragmatically speaking, “classic” Scrum would have a team that looks like this:

• 4 iOS developers
• 1 Middle-tier/ DBA
• 2 QA testers
• 1 UX/UI designer

How they grow to become cross-functional is part of their self-organization:  The iOS developers will assist the Middle-Tier and QA in System Integration Testing, collaborate on Human Interface Guidelines with the UX/UI designer.  The middle tier looks to UX/UI and the iOS developers for what information needs to be delivered by a web service.  The QA testers are perfect for “hallway” testing of the UX/UI designer’s rapid prototypes.

A framework is a collection of patterns– the Scrum framework is built from the pattern of the Well-Formed Team.

The second pattern consists of the Scrum Ceremonies – the feedback loop of Daily Stand Up, Planning, Review, Retrospective.  The last pattern is the role of the Product Owner as the single point of accountability to the users, stakeholders, business owner, and team for the value created by the prioritize Product Backlog (for more on this, see my post Why Product Owners?).  In traditional Scrum, the Product Owner is outside this Well-Formed Team.  50% of the Product Owner’s time is spent collaborating with the team about the backlog, 50% is spent with the Stakeholders.  Adding a Business Owner that handles most of the sales and business “chores”, this could be an effective Lean Startup!

Scaling the Patterns:

The 3Back course reviews three approaches to scaling the patterns set up by Scrum:

• SAFe – Scaled Agile Framework http://www.scaledagileframework.com
• LeSS – Large Scale Scrum http://less.works
• SSwS – Scaling Scrum with Scrum http://3back.com/scaling-scrum-with-scrum

In the interest of time, and because I recommend learning this from 3Back, LeSS, or SAFe yourself, I will skip to my take-aways.  The number one thing to recognize one a framework scales is where accountability is shifted.  This is the biggest with the concept of the “Product” Owner in traditional Scrum – once several teams are delivering a single large product (imagine Spotify or Microsoft Office for desktop), or a single team becomes responsible for a long series of very different products (imagine a team in a typical custom software development company, delivering 4 to 7 products per year), the “ownership” becomes an expectation that must be made clear.

SAFe – Scaled Agile Framework:

SAFe takes the large organization and introduces agile in a scaled manner (in juxtaposition to scaling from small to large as a company grows).

It divides the delivery of a large organization into the product, program, and portfolio levels.  The Agile Release Train and (presumably) the ceremonies are on a single schedule for the entire portfolio.  At each level, backlog development is done at the program and portfolio level, leaving the teams to deliver groomed and prioritized backlogs to deliver.  While the Agile Release Train teams, whether delivering a distinct Product or features as part of a large system, have an accountability owner, the key issue with SAFe is how accountability is scaled.  The pattern indicates scaled scrum teams, but those teams do not have Accountable Owners for the decisions or the teams!  You can see how, despite sprint-based delivery, this will eventually result in the Waterfall Witch-Hunt”.

LeSS – Large Scale Scrum:

Large Scale Scrum, is the methodology currently supported by ScrumAlliance.org for its new Added Qualification: Scaling Scrum Fundamentals.  The Body of Knowledge presented on the LeSS site is thorough and full of terrific information on the Well-Formed Team, organizing in the Large, and bringing together the  – I am still revisiting the content and will likely write more on the topic in the future.

As Dan Rawsthorne quickly pointed when tying together the patterns in SAFe and LeSS, the owner of accountability, regardless of what (s)he is called, emerges in three ways from:

1. Traditional Scrum: The Product Owner is outside the team and gives them a prioritized but not fully groomed backlog
2. Modern and Scaled Scrum: The Product Owner is part of the team that is handed a prioritized and groomed backlog, some level of interaction with stakeholders is sacrificed
3. Dysfunctional Scrum: The Product Owner is outside multiple teams serving multiple competing stakeholders for several products (typically, a proxy owner ends up with responsibility but no accountability

In SAFe, the key problem breach-of-pattern is that the diffusion of responsibility overcome through a Product Owner does not scale to the Program and Portfolio levels.  The key issue with LeSS, in contradistinction, is that the the pattern forgets to give each Scrum team their product owner!  It may be be implied that a Business Analyst or Technical Lead is meant to take on the responsibility of ensuring the backlog is fully groomed, but without recommending a solution for this I predict Dysfunctional Scrum – the person accountable, the person responsible, and the person empowered are not housed in a single role.

Scaling Scrum with Scrum:

The Scaling Scrum with Scrum framework recommended by Rawsthorne and Shimp at 3Back attempts to maintain the patterns that make Scrum successful and repeat them across several teams working on cohesive product offering.  Partly drawing on the success of Spotify there is a clear effort to maintain a clear chain of accountability ownership at any level of the organization.  This is not by necessity a command-and-control hierarchy – the reporting structure can rely on Communities of Practice so that skill-specific positions can report to an expert in that field despite working on separate teams.  The goal best driven by SSwS is organizational learning.  The clarity of the One Big Role at each level, where the is a facilitator and aggregator of feedback (scaling the ScrumMaster) and a clear point of accountability for decisions related to the feedback (scaling the Product Owner) stayed true to the philosophical line of thought set up in the first half hour.

Having spent several hours with a pattern-based critique, I quickly realized the main limitation of SSwS – the pattern “scales” 50 to 100 developers in scrum teams up to a cohesive Product Offering.  As the other half of my career was focused on Management Strategy Consulting, I could see that scaling accountability beyond SAFe’s portfolio level in a many-product firm competing with unique strategies in disparate markets quickly becomes management problem, not Scrum problem.  Dividing up strategic divisions, defining positioning in the market, and set the focus of a complex portfolio of investment is strategy solution, not a process solution.  Rawsthorne alluded to the longer discussion of how to Scale SSwS with SSwS and I plan to reach out to him regarding it – Chief Operating Officer as ScrumMaster and Chief Executive Officer as Accountability Owner?  “Clark, I can picture it in my mind and its breathtaking.”

Conclusion:

Scaling Scrum with Scrum is a terrific crash course for someone looking for a philosophical comparison of multiple approaches to scaling agile or taking a large organization and introducing scaled agile.  I would primarily recommend it to trainers, coaches, and change agents.

---

Connect With Me: