Hello World, Scrum of Scrums and Scrumbrella

Hello, and welcome to my new blog!

My name is Nigel and I am an Agile Coach based in Bristol in the UK. I’m heavily involved in the ScrumAlliance, both as a Certified Scrum Trainer and as the Programme Chair for the London 2012 Scrum Gathering. I travel the world, training, coaching and enabling people in Agile methods, (particularly Scrum).

I’m also writing a book. The current title is “Change with Scrum.” That, like most projects, is likely to change. I am currently 40,000 words in, and in second draft form.

With all this, you may be wondering, why on Earth I need to fill my other 12 minutes of free time, with yet more work writing this blog?

To be frank, It’s a question I’m asking myself.

The fact is, there is a lot written about Scrum on the net. And it isn’t always good stuff. No, I don’t mean “good” as in “positive”, but “good” as in “will not get me fired or make my life hell.”

There’s too much positioning, by people with more time to write than work, or people with their own little axes to grind.

And that’s OK – Not everyone is going to agree. But recently, I have been noting that people who are blogging a lot are being listened to, and believed without comment.

I’ve just been to the Seattle Scrum Gathering – A great event, organised by the ScrumAlliance and chaired by a great fellow trainer, Brian Stallings.  I really enjoyed and embraced the large community of intelligent, engaged individuals there.

My one concern, was that some of the sessions and keynotes were being listened to with an uncritical eye.  The Gatherings over the last few years have taken a more “big tent” approach to Agile than before, and that has been a great benefit, but with the engagement with a wider community comes differing opinions. Some of these run counter to (in my experience at least) the unofficial body of knowledge that has been built up, and some of these are misunderstandings of what Scrum is actually about.

Now, during the event, I did what most mid thirties, IT professionals/geeks do and tweeted my comments and thoughts… but that’s not enough in my opinion.

So what I am going to do hear, is blog my own thoughts and feelings on a variety of subjects in Scrum. I am going to draw from the second draft of my book, and I’m going to compare it to some of the comments we’ve been hearing from the Gathering (to begin with) and then in the longer term, in terms of comments I am hearing in the industry in general.

So with that introduction out of the way, lets get onto the first subject.

Scrum of Scrums and the Scrumbrella.

Steve McDonell had the pleasure of the first keynote. (due to unforeseen circumstances, the conference had to be Agile and move keynotes around – The introduction of new open space session facilitated by Chris Sims covered the gap and started the conference with a bang!)

His keynote was about problems he has seen with Scrum in industry. He tried to frame it appropriately, (“I am here to praise Scrum and NOT bury Scrum” was my pithy paraphrase at the time, of his introduction), but the entire keynote was a reflection of genuine issues through the lens of a (seemingly to me) conservative consulting software organisation.

Two things Steve pointed out in his presentation were anti-patterns I have seen in industry: Agile teams not planning far enough ahead for the business (Steve used the statement “The Business prefers Wrong over Vague”) and about Scaling.

Today’s blog is about the scaling conversation, though we will cover back to the “not enough planning” concern in a late blog post. (If you can’t be bothered, don’t worry, here is the post in one sentence. “Velocity, Rolling release plans and Stable teams, dummy.”)

No, what I want to communicate here is about Scaling. Both Steve and Alan Shalloway, (Who I did not hear speak, so I am relying on Steve Dennings blog post here (http://blogs.forbes.com/stevedenning/2011/05/18/major-management-insights-from-the-scrum-global-gathering/) discussed about how Scrum of Scrums “doesn’t work” or “isn’t enough”. What spurred me to write this, was the fact that Mr Denning, (whose presentation went down incredibly well with the audience and put into context how Agile is just one movement in a broader space pushing organisations out of the 20^th century and into the 21^st), seems to have taken than opinion as a given. I have seen many other people buy into the same argument.

I was confused? There were frequent references to how Scrum of Scrums didn’t work, yet every week of my working life, I help organisations put together productive and helpful scaled experiences. I have no problems with the SofS and in fact, have written about it in my forthcoming book.

Steve said, that Alan said “ the reason for this is that Scrum is essentially a bottom-up approach to work, which is highly effective for generating high productivity at the team level. However when it comes to making sense of, and coordinating, large scale projects, it is better to start from a top-down or big picture approach” – There is some truth to that, though my Agilometer (A device that measures Agile heart and culture and uses the universal unit of Agile soul, the “Tobias” (http://agileanarchy.wordpress.com/) as its’ measure… well, it didn’t like the meter reading it got off that comment. Too much Bottom up? That’s like saying, “You’re too healthy”. Dammit, man! Eat more cakes and smoke more cigars. But still, I didn’t see that big picture missing in my work?

Then Chris OD said about Scrum being a fantastic tool for team management of work, but at the “higher levels” more traditional practices are needed. Now the Agilometer would not even twitch at this. This is an anti-pattern of Scrum, and scaled Scrum in particular, I first noted back in 2007, called “Workpacket”. Alas, This blog is already running far longer than I would like, so I’ll come back to those anti-patterns in another post, if anyone is interested. (They’re also in my forthcoming book.)

So I decided to look back – and see what people actually mean by Scrum of Scrums.

Scrum of Scrums PRIMER

 From Mike Cohn’s Mountaingoatsoftware.com:

“Although not the only thing necessary to scale Scrum, one well-known technique is the use of a “Scrum of Scrums” meeting. With this approach each Scrum team proceeds as normal but each team identifies one person who attends Scrum of Scrum meetings to coordinate the work of multiple Scrum teams. These meetings are analogous to the Daily Scrum Meeting but do not necessarily happen every day. In many organizations, having a Scrum of Scrums meeting two or three times a week is sufficient.”

 “The illustration below shows how a Scrum of Scrums approach allows Scrum to scale up (in this case to 243 people). Each cell represents one person on a Scrum team. The bottom of this illustration shows teams with nine developers on them. One person from each team (the differently colored cell) also participates in a Scrum of Scrum to coordinate work above that team. Then from those nine-person teams another person is selected (this time shown with diagonal lines) to participate in what is called a Scrum of Scrums of Scrums.”

(Thanks to Mike Cohn for the above image)

  

           

Ah-Ha! Turns out that I disagree with this approach as well – But not the name. You see a Scrum of Scrums should be exactly that, in my book. A genuine Scrum of Scrums.

I can see people’s concerns about somehow managing a large project with the only official artifact to support you, being this fifteen minute meeting. Having said that, I genuinely get people in my Certified ScrumMaster Training (CSM) who believe the entire course will be about that 15 minute timebox.

<ASIDE>: I suppose they think that somehow this small, trivial on it’s own, irrelevant sub artifact of the delivery experience can somehow be leveraged to introduce the entire project framework over time. Using that daily inspect and adapt cycle to reinvent the wheel in every project, using some form of Expensive guru who tells you how to finesse the structure into place, in a grand act of intellectual wankery.

But I can’t see anyone taking such a silly approach. If you do, remember I INVENTED IT and it is called “Scrumesis.” (A combination of Genesis and Scrum.) Oh dear. I have the horrible feeling that this joke has started some further thinking within me and at least another blog post. </ASIDE>

So,back to Scrum of Scrums – Here is the approach I take:

The Scrum of Scrums is not only one part of Scrum; The Daily Scrum. At the Scrum of Scrums level, the entire Scrum framework should also be applied.

1. There should be a coherent overarching Vision, This big picture is more essential than ever. I have started (and so do not have any long term evidence of success, apart from “it feels good”) to use my friend, Roman Pichlers’s suggested Product Board format for this scaled Vision. (http://www.romanpichler.com/blog/product-vision/the-product-vision-board/) The Board captures the Product Roadmap, which in a scaled environment is usually essential.
2. There will need to be a Product Backlog
1. Queue: In medium scaled projects (1-3 teams) this can be one Product Backlog with the teams pulling from that one backlog. (See Bas Voddes and Craig Larmans book on the queueing theory behind such a model.)
2. View and Queue: In a HUGE project, (3+ teams) this will likely to be a View onto the Product Backlogs of the teams for the Release and only kept at the scaled level, one backlog model for future releases.
3. Superset: I’ve not seen a successful “Superset” backlog, where the backlogs are individual teams based and then consolidated at the higher level and driven and steered from there as a consolidated whole.

This view can be as complex or as simple as you like.  You also do not have to have a one big backlog OR one per team.  You can have Product Backlogs shared amongst teams. If you go too low level, “feeding the beast” that is the Scrum teams is very difficult and keeping the Product shape reasonable and aligned is a real war. Keep your backlogs as shared as possible.

Normalisation of Backlog sizes seems to be more in vogue again. I remember a time when this was frowned upon, but with a sensible understanding of abstract sizing, it can be pretty easy to get an approximation of equality. They will never be identical, but “near enough is good enough” for the appropriate level of planning at release. I wouldn’t bother across backlogs, as we can use the simple calculation of size of backlog/velocity to get a timeline to align our work across teams. I do see people normalising backlog sizes and THEN running as separate backlogs. I am not sure of the benefit of this…

1. Traditionally, a Scrum of Scrums is for dependencies, but most semi mature scaled environments I have seen, have formed their own particular methods to ensure cross team dependencies. The one I suggest most is the “Trigger” model. Whereas, just like a traditional database trigger, teams mark cross team dependant cards with some form of visual marker (such as a phone number), so that if he story falls out of or into another sprint, the trigger is activated and they call the number and give that team the bad news.
   1. Thus, the Scrum Of Scrums becomes an inspect and adapt point for the scaled Scrum team, a bootstrap of the day much as the Daily Scrum is and is used for understanding status and most importantly, dealing with issues.
   2. It allows us to Inspect and Adapt daily within this hugely complex environment. So instead of the Cohn suggested 30 mins– 30 mins – 30 mins heartbeat, we have a 15-15-15-15-15 daily heartbeat – Plus any extra spawned conversations and meetings needed.  In complex large enterprise environments, you have to be on top of things, daily.  Arrhythmic heartbeats is unhealthy in the body and unhealthy in Scrum.

1. There will be a Sprint Backlog for this level. Since this virtual team will need to own issues that the Scrum teams themselves cannot handle, we need some way of managing our cross team workstack and progress. This will not be burnt down in a traditional Scrum team way, and is best looked at as a To-Do issue list for this group. The larger the project, the more formal this part of Scrum is applied.
2. There will be Sprints to organise ourselves and to align with the feature teams.
3. There will be Reviews and Retrospectives.
   1. The Retrospectives will be performed by the Scrum of Scrums team to discuss the cross team issues and progress at the end of the timebox.  As well as their own performance and tuning of Scrum at this level.
   2. The Review is more important. This should be the demonstration of the Product in its totality, and not a mere combination of Reviews of the sub products being created by the Scrum Teams.  This review whilst not repeating the work of the Scrum teams, (that would be waste) should demonstrate the end to end experience of the Product as a whole. This review is not only for “higher level” stakeholders per se, though it will contain more business sponsor level conversations, but just like a normal Review should contain a cross functional mix of people from beyond the virtual team.
   3. Scaled virtual team. The Scrum of Scrums, instead of having a volunteer to attend each day, has a more semi permanent structure. It is still NOT a hierarchical thing, (The attendee would be the most appropriate team mate), but attendance would need to be semi consistent to help deal with the organisational issues raised. In real life, I tend to see more ScrumMasters coming to this than less, because the main topic of work is organisational issues and problems, and ScrumMasters tend to focus on these.
   4. Scrum Roles: In all scaled Products there needs to be a Product Owner for the larger product experience. (A Chief Product Owner, Product King, whatever titles you want. I have my own suggested Product Owner naming convention which I will likely cover in another blog post – It’s in the book.) and larger scaled projects (3+ teams) I almost always suggest another ScrumMaster at this level to help facilitate the virtual team and keep the artefacts and ceremonies in some reasonable shape. It is very easy for scaled programmes of work to run away with themselves and roll away from you. Or towards you, like the big ball in Raiders of the Lost Ark. J

Integration Scrum and Webs

 

We are all aware of the classic approach to scaling Scrum projects, The Scrum of Scrums – and we have already discussed the risks associated with merging that Scrum model into other frameworks or contradictory sets of principles. [See future blog post] However, the Scrum Of Scrums is not a universal panacea to large projects – the structure just allows us to steer the product through it’s lifecycle and gives us a handy system for helping us deal with issues.

However, it is too easy for us to still build end-2-end solutions within the stack that duplicate or mirror functionality (“stovepipe solutions”) being built within other teams. This duplication reduces reuse, and introduces needless complexity.

We have seen that a single Product Backlog for all teams, can help reduce this, though as we have seen in the early chapter, this becomes very difficult to manage once the number of teams as grown above a handful. Another approach is suggested in Ken Schwabers “Enterprise and Scrum” (2007) of Integration Scrum.

The integration Scrum effectively acts in a similar way to the Scrum of Scrums, but this grouping is there to bring about technical and structure coherence.

Rather than this:

The structure looks like this:

With the integration Scrum acting as a Scrum team, with a volunteer from each team attending like the others. As before, this does not have to be the ScrumMasters (in fact, in such a technically focussed conversation, they may be some of the worst people to attend.) but is an appropriate volunteer from the team, combining this human technical coherence and emergent design practice along with the classic Agile engineering practices of Continuous Integration, Test and Behavioural Driven Development , Automated Testing etc, can really allow us to form our systems into the Shapes we want.

This allows us to be less vulnerable to the choices made in any up front thinking, (and those choices less vulnerable to being ripped apart by ten Scrum teams) and to allow us lots of product technical flexibility on the “back end”, without creating a monster. Or at least a Monstrous entity. This allows us to not only to empirically plan, but empirically shape.

Practically, though I have heard of people doing either a Scrum of Scrums OR a Integration Scrum – I see both as equally as important in the larger projects. And this is my preference.

Note: This is a placeholder image – A new image with appropriate colours (The attendees of the integration Scrum WILL NOT be the same as the Scrum of Scrums and Scrum of ScrumMasters will be added soon.)

Dependencies and organisational issues being dealt with through the Scrum of Scrums, and the technical coherence through the integration Scrum.

You’ll find that the Integration “Scrum” may not be a full Scrum implementation, though I see that method take on more and more Scrum properties as it gets larger and larger. The minimum is the Daily Scrum ceremony, but Vision, Issues, Review and Retrospective are often the most useful artefacts that emerge. This tends to be more asymmetric than the Daily Scrums, running a couple of times a week.

That is a start, but it is not enough. In the next blog post I will introduce a new concept: WEBS.

Now, I have always called this Scrum of Scrums, because that is exactly what it is. A virtual Scrum Framework above the other. With some parts lightly applied, and some parts heavily so.

However, as we see, that term is taken. So I am rebadging this general approach as a Scrumbrella model. (A term I first coined for a slightly different context back at the Portland Scrum Gathering in 2007.)

The ideas behind the model (Scrum not merely for dependancies, but more for issues and and actions in the enterprise, acting as another form of protection to the wider community and a support tool for ScrumMasters. With a structure to assist the Product Owner Team with Vision, roadmap and appropriately scaled feedback.)

This distinguishes it from the captured-in-books, traditional Scrum of Scrum model.

This model is not my invention alone – I know it to be a pattern that has reoccurred again and again in more sensible organisations. I know aspects of it have been captured in many books on scaling. But at least we now have a name for that model and we can now communicate the difference to people on the periphery of the Agile movement to help them understand.

As I say in my book:

The first step in the transformation of the world of work was the team. The second step was the Product Owner. The Third is the Team of Teams.