Transforming the Scrum of Scrums and Delegating Release Co-ordination

“The agile manager’s scariest move; handing over responsibility”

Once we* had our Delivery Teams regularly delivering increments of valuable working software; the management team made the tough call of pushing the responsibility for co-ordination of releases to the Delivery Teams. This blog post follows this decision through its successes and failures and explains how we adapted to the feedback we received and issues that we identified.

*The Royal we: Management Team, Transformation Team, and Coaching Staff.

Attempt 1 – Complete freedom

A meeting was arranged by the management team to announced to the Scrum Masters (and a few other stakeholders) that as part of the ongoing transition the Scrum Masters must step up and take ownership and responsible for co-ordinating our quarterly releases. After this meeting the management team deliberately sat back and let the Scrum Masters sort it out themselves.

The Scrum Masters held a brief meeting to decide how they would handle the situation. They quickly selected two Scrum Masters to lead the co-ordination effort. One of them took the lead and did a great job of co-ordinating the release, which went out on time and to the quality we had aimed for. There was plenty of room for improvement but no major disasters.  

While the Scrum Masters were comfortable with this change, the management team quickly lost visibility of any issues that were occurring and at the same time were getting feedback from many staff members about a lack of communication between the Delivery Teams.

Another couple of issues popped up, which told us another approach was needed for the next release: 

1. The Scrum Master who lead the co-ordination of the previous release was promoted into the management team. 
2. The other Scrum Master who had been involved was currently swamped with practice improvement work. We were not sure who would step up to the take the reins.

Attempt 2 – PMO established Scrum of Scrums

With issues around lack of visibility, low communication between teams and concerns about how repeatable our previous success was, the management team decided that they needed to act.

At this point in time the culture had moved from ‘responsibilities being assigned to individuals’ towards ‘responsibilities being assigned to teams’. Looking at our current issues the decision was made by the management team to rotate the responsibility for Release Co-ordination between Delivery Teams each release, along with establishing a Scrum of Scrums as a status reporting, cross team communication and impediment removal approach.

To get things moving quickly our PMO manager booked a weekly meeting with the Scrum Masters, during which they were asked what the status was of each release that was in progress (we have 1 or 2 maintenance releases and 1 feature release in progress at any one time). The Scrum Masters saw it as the PMO meeting and were fearful of raising issues at the meeting, as those issues would then be forwarded onto the management team. The Scrum Masters thought that any issues that were raised made them look bad, meanwhile the management team was hanging out to know the real status of the releases, so that they could help wherever was needed. This fear or lack of a ‘Safe to Fail’ environment was addresses separately (and is perhaps the topic of another blog).

With the PMO established Scrum of Scrum operating, the management team continued to receive feedback that there was not enough team to team communication, however we did start to get some issues raises and did get some feeling for how well the releases were going (and they were going well). We were still concerned that the level of ownership of Release Co-ordination was not as high as we needed it to be.

Attempt 3 – Scrum Master established Scrum of Scrums

With Attempt 2 still not providing the results we wanted, we decided to intervene by re-invigorating the ‘SOS’ (this unfortunately meeting name was one of the first things to go).

To kick off the change our two Engineering Managers (who have responsibilities around People and Practices) each talked one-on-one with the Scrum Masters that reported to them. 

They asked about the Scrum Masters view of the SOS meetings and set out some clear expectations around team to team communication, Scrum Master to team communication, the raising of issues, ownership of release co-ordination and running the Scrum of Scrums. Lastly they were told that a meeting would soon be organised with all of the Scrum Masters where they would have to work out how they would re-invigorate the Scrum of Scrums.

I facilitated the meeting with the Scrum Masters and the Engineering Managers in attendance. We started with one of the Engineering managers setting down the expectations regarding the Scrum of Scrums:

• Raise team specific risks, so that the other teams are aware and can assist.
• Explain what each team is doing, so that the other teams are aware and can assist.
• As a group uncover big risks and either deal with them or escalate them.
• As a group review and understand commitments especially those with specific dates.

Once those expectations were clear we got down to the business of the Scrum Masters deciding what information they needed to be able to meet those expectations, how the meeting would be organised, when it would occur and who should attend.

In summary they decided upon:

• All Scrum Masters and the PMO manager would meet weekly on a Monday after all of the Stand Ups were completed. No other people had to attend, however back up Scrum Masters and the Lead Architect was optionally invited.
• Using a large highly visible planning board, showing all teams, all key user stories, dates, etc.
• A simple agenda: Each Scrum Master presents in the order shown on the board, and then any issues/news is discussed as a group.
• Each Scrum Master was responsible for keeping their team’s row up to date.
• One volunteer would create the first Scrum of Scrums board.

Continuation / Tuning

The first meeting went reasonable smoothly, a due date was clarified, a risk was discovered and they discovered two teams that needed to co-ordination on a user story. A few tweaks to the board where suggesting, including using a consistent colour coding scheme.

The next few meetings were tentative affairs as each Scrum Master was ‘feeling out’ how they should behave in this new situation.

The fifth meeting seemed like they were starting to get off track and just running through the motions of an ineffective status update meeting.

The sixth meeting had some minor cross team concerns discussed. A couple of teams had let their information get out of date, with only one user stories up for the current sprint. The major issue was that we were fast approaching a critical release date, and there was no communication around the status of features that had been committed in the release. It seems like the Scrum Masters were not considering the whole release as much as was hoped by the management team. This prompted a lot of one-on-one discussions and feedback sessions, which thankfully all hit the mark.

Seventh meeting: Great, they are really getting it, taking ownership, asking questions, self-organising. The teams that last week only had one card had added all of their planned user stories and provided more detail in their summaries; this triggered conversations and overall seemed successful.

The Eighth meeting was held part way through the first sprint of our new Release cycle. The board had the next 4 to 5 sprints filled in for most teams (only at a high level for sprints 2 to 5). As a group they spotted three key issues and quickly resolved them. It looks like the Scrum of Scrums is working and is here to stay.

Coaching Scrum Masters

In my coaching work, I find that any effort I put into coaching Scrum Masters pays itself back many times over. The Scrum Master is able to take their improved knowledge and apply it to their team which has a compounding effect. With the Scrum Masters fulfilling their role well the teams can hit their stride earlier and I can focus on key individuals and organisational issues.

In this blog post I explained my approach of providing direct feedback to Scrum Masters based on the Scrum Activity that they just facilitated. That approach has served me well; however it was not always been smooth sailing. I have learnt a few lessons along the way. From my successes and lessons I present to you a list of ‘Trys’.

The basic approach is to observe the Scrum Activities (Planning, Review, Retrospectives, Stand ups) and provide feedback directly to the Scrum Masters. Focusing on the Scrum Activities helps the Scrum Masters to quickly come to terms with the most visible aspects of Scrum. With these visible aspects under control, they can move on to learning about the more ‘behind the scenes’ aspects.

Prior to the activity

• Try asking for permission from the Scrum Master to attend the activity. This serves several purposes; it helps to bring the Scrum Master onside ready to receive your feedback, it gives you a chance to ask the Scrum Master to explain your presence to the attendees at the start of the activity, and it allows you to book in a time to provide the feedback promptly after the activity.

During the activity

• Try having the Scrum Master explain to the attendees as part of setting the scene for the activity; that your presence is to provide feedback to the Scrum Master and help them improve; it is not to grade the team. This goes a little way towards the attendees being more open in your presence.
• Try taking plenty of notes during the activity. Making sure to record specific examples of the incident that relates to the feedback you want to provide. i.e. During a Retrospective ‘Need to drill into symptoms to find root cause’, would be better recorded as ‘John said the tests where taking too long; you should have asked why are they taking so long, before getting the team to come up with a Try.”

After the activity

• Try to meet with the recipient promptly after the event. The same day is ideal, the next day is ok. With the event fresh in your minds you will both be better placed to discuss specific examples.
• Try keeping your feedback to around five key points or less. Any more then that will be hard for the recipient to take in during the feedback meeting. I often look at my page of notes and mark a couple of good points and a couple of the areas for improvement, making sure to only mark five points or less.
• Try meeting in private, this encourages the recipient to be more open and frank with you, especially when talking about their interactions with other people.
• Try starting the feedback meeting by asking them what they thought of the event; their answer is often enlightening. Some times they may already have internalised the feedback that you intended to give them, they may have seen the activity completely different to you, they may have had some insight into why people did what they did, they may offer up some issues that gives you a great opportunity to drill into.
• Try to discuss all criticisms in a constructive way. They should be presented as areas for improvement. E.g. ‘You did not stop the ongoing discussion about how to design the widget, that discussion was wasting the team’s time.’ would be better phrased as ‘The ongoing discussion about how to design the widget, could have been cut short and taken offline. This would have saved several minutes for the team. Perhaps next time a discussion is occurring that only involves a couple of people goes for over a minute of two, you could politely ask them to take it offline? Would you be comfortable doing that?’
• Try using the Feedback Sandwich:  

1. Start with positive feedback (Praise).     
2. Discuss areas for improvement (Constructive Criticism)     
3. Wrap up with more good stuff or general encouragement (Praise).

• Try to discuss all praise and criticisms based on recent and specific examples. E.g. ‘It would be good to see you support the voice of the quiet people in the team’ would be better as ‘When Ronald started to talk about his issues with the documentation being out of date; it would have been a great opportunity to support a quiet voice in the team by agreeing with him and asking the team to discuss it further’.

Good luck giving out your feedback and seeing your Scrum Masters grow. Let me know if any of these try's worked for you. I am also keen to hear about any that backfire for you.

Photo by: Kris Anderson

Focus on UX

I recently attended a session of the London Agile DiscussionGroup where the focus for the night was UX, what is it, where does it fit in the lifecycle of an agile project? To me it was a very interesting night as I have not worked directly with a UX designer before. I was intrigued to see how others have done it.

I was especially keen to know whether they had been able to work in a continuous manner (UX developed in the same sprint that it is applied to the product) as opposed to working sequentially (UX developed in Sprint N, UX applied to product in Sprint N+1). Going into the night I had seen couple of ThoughtWorks presentations on Continuous Design. However because I had never experienced it, I was open to possibilities on both sides of the debate. At the end of the night I had heard three tales of Continuous UX occurring in the wild and about 70% of the attendees believed that it will be possible for them to do Continuous UX in the future.

For me there were three key takeaways from the night:

1. Continuous UX is possible.
2. The key to Continuous UX is small User Stories.
3. UX needs to involve feedback from real users; ideally the feedback should be analytical data. Otherwise it is just guess work and not really UX.

From what I heard most UX is a case of cyclically incorporating the feedback/data into the on-going design and development work. There will be some UX Debt accumulate, but you need to keep it low as the cost of those UX changes can quickly sky rocket. In summary UX like architecture, needs to be a little bit ahead of the daily sprint work, but not sprints ahead.

One of the real life success stories I heard, was of a small team (1 UX, 2 developers & 1 QA) building internal system and working on small User Stories. The UX guy would produce working CSS of the item in half a day, and work with the team on refining it. They were able to deliver a continuous flow of changes that incorporated UX. The UX guy building directly into CSS and not writing down his ideas; was a large part of their success, along with their small stories that lead to simple UX.

Restaurant Booking Web site scenario

To put our new found knowledge into action, each table of participants at the meet up, took on the following scenario. As a new project team, create a web site for a local restaurant that allows them to take bookings for dinner. Outline the project plan sprint by sprint for the first couple of sprints. From my memory this is what we came up with as a team.

Sprint 0

•        Establish team
•        User Story Workshop & Project envisioning
•        Establish Infrastructure: hardware, coding standards, continuous integration, etc.
•        Deploy a hello world home page that is not published to DNS servers hence is only available to navigate to via entering the IP address.
•        Create architecture that allows for AB split testing and analytics capture
•        Create Brand Guidelines – style guides, reusable controls such as buttons.
•        Conduct Market Research

Sprint 1

•        Deploy a publicly accessible holding page that uses the brand guidelines, indicates that a full web site is under construction, shows the address, phone number and e-mail address of the restaurant.
•        Conduct AB split testing on some different holding pages.
•        Start working on the highest priority User Stories, incorporating UX as we went.

Photo Credit: http://www.flickr.com/photos/murdocke/

Communication during a transition

In summary it should be focused on what you hear not on what you say.


We recognised that communication with staff during an agile transition was important for two reasons; firstly so that the transition changes would be understood and accepted. Secondly and most importantly, so that issues and concerns from staff would be raised. We could only address concerns that we knew about so it was crucial that they were raised by the people who were feeling the impact of the changes.

Try as we might, deafening silence was the result of most of our communication approaches. 

While this blog post presents many communication approaches that failed to generate any feedback, overall the transition was a big success, with the results to prove it. The net positive survey response to ‘I am well informed about the agile transition’ rose from 70% to 84% and then to 90% over two years. However the ultimate indicator of success is that the vast majority of staff are really happy at work.

What I have taken away from all of this, is that communication should come from numerous channels and MUST be two way to be effective. It also brings to mind the Proverb "Listen to people twice as much as you speak." 

For those who are interested, the remainder of this blog explains the different approaches that we tried and a brief summary of the outcomes.

• Email feedback inbox – e-mails received in two years, zero.
• End of Transition Team sprint Email, explaining what we had done and are planning on doing. In there we linked to the feedback email address and mentioned that all of the Transition Team is open to being approached – feedback received, zero.
• Chocolates hidden behind links in the End of Transition Team email - we ended up eating the chocolates ourselves as no one found them.
• Directly telling people about chocolates hidden behind links – partial success, with some heavy hints, the chocolates were ‘found’ and handed out, excitement and interest created = zero.
• End of sprint Blog, explaining what we had done and are planning on doing - very few people subscribed to the blog.
• Transition Team members provided in person updates to teams after their stand ups – partial success, teams got the information and queried a few items; however where generally dis-interested and questioned why they get Management updates and Transition Team updates.
• Submit news to go in Management Update – un-tested by this time the Transition was wrapping up and only one news item was submitted, ‘the disbanding of the Transition Team’.
• Quarterly Staff speak ups – this generated a couple of questions but generally there was silence, at least they were there to hear the messages.
• Ask Transition team for concerns, who in turn asked Scrum Masters, who in turn asked team members – success, a reasonable number of concerns were raised. Many of these were turned into Transition Team User Stories.
• Surveys – ten questions one page, done via Survey Monkey, same survey three times over two years. Success: 80% of staff responded, plenty of meaningful and detailed feedback received. Many of these were turned into Transition Team User Stories.
• Rick Roll entire division in Transition Team farewell e-mail – good result, at least five people contacted me ;-)
• Scrum Masters discussing issues with their manager during regular 1 on 1s – success, plenty of issues where raised and then discussed by the Transition Team with several of these becoming Transition Team users stories and some guidance for stories already in progress or about to start.
• Division Manager holding Staff Forums with small cross functional cross team groups – a great success, staff really got stuck into providing direct and honest feedback. Some of this was related to the transition and other items were more general. This provided some Transition Team user stories and some guidance for stories already in progress or about to start.

Image Provided by: © Svidenovic | Dreamstime Stock Photos & Stock Free Images

Story Points are only one third of the reason for estimating

“One’s destination is never a place, but rather a new way of looking at things.”
From: Miller, H. (1957). Big Sur and the Oranges of Hieronymus Bosch

Assigning some Story Points to a User Story may seem like the point of agile estimation; however in my eyes it just signifies the end of the process. 

For me the goals of agile estimation are to build a shared understanding in the team of what the story is and to build team consensus around what the rough estimate in Story Points should be.

The journey that the team goes through to come up with the estimate, is more important than the number that is assigned at the end of the process. Sure the assigned estimate assists with planning, however the knowledge that the team gains during discussion will help with their understanding of what they are delivering, why and how they will go about it. I often hear discussions on topics such as: user needs, business value, design, potential new User Stories, testing approach, development approach, how this User Story fits into the Epic, which are all valuable.

Here is a brief summary of the benefits that the team gain by going through an agile estimation process.

Assigning Story Points to each User Story supports

• Grooming – identify stories that are large / candidates for splitting, identifying inefficiencies such as splitting an 8 pointer into two 5 pointers – should we do it as an 8 pointer to save overall time?
• Sprint planning – roughly creating a sprint backlog based on average velocity.
• Sprint planning – switching User Stories of equal Story Points in/out, up/down priority.
• Release planning – using the combination of average velocity and story points of remaining stories to provide a rough view of our status.

Discussions build a Shared Understanding, which supports

• Grooming – effective ways of splitting a User Story into multiple User Stories.
• User Story Planning – splitting user Stories into a set of tasks that will work for the whole team.
• Development – design ideas, implementation approach, testing approach, etc.
• Identifying issues – such as impediments, dependencies, etc.

Using consensus to arrive at the Story Points supports

• Sprint planning – with a stable average velocity and consensus on the Story Point of each User Story, there will be less second guessing of what to pull into the sprint.
• Commitment to delivering the Sprint Backlog – consensus around the estimate, leads the team owning the sprint commitment. i.e. “it was my estimate, so I will push to finish the story within the sprint”.

Interested in estimation?

• Fast Estimation
• Story Points do not equate to time
• Top Tips for Planning Poker

Iteration Manager to Iteration Leader

Scrum Master to Scrum Leader

Iteration Managers/Scrum Masters should not just be managing their team. They should be providing the team with leadership that helps them to achieve great things to together.

• Lead not by telling them.
• Lead by helping them to set clear and elevating goals.
• Lead by teaching an agile way of thinking.
• Lead by teaching them to think through the problems that you yourself contemplate.
• Lead by making them think for themselves.
• Lead by encouraging them all to be their best.
• Lead by example. I.e. exhibit the Scrum values. Be the change you want to see.

Self-organising doesn't mean they don't have an Iteration Manager, it means they can function without one. An Iteration Manager will always be there leading them onto a greater success then they could achieve by themselves. That is what great leaders do.

This article is available in presentation form on SlideShare: Iteration Manager to Iteration Leader.

Photo Credit: I was unable to find the owner of this photo. Please contact me if you own it.

Running a World Café

This is a brief summary of my experience of running a World Café.

I volunteered to run a World Café, themed around Organisational Impediments and how to solve them, for my local agile Meet-Up group ‘Brisbane Agile’*

I deliberately kept my preparation to a minimum. I held some discussions with the Meet-Up Organiser, regarding how we would run the event and set up the room. Apart from that I created a few wall charts to help smooth out proceedings and came up with some sample Organisational Impediments. These were a backup in case the participants were reluctant to volunteer their own items for discussion. This word document contains the wall charts I used.

We set up the room with five groups of tables that seated about six people each. Seating for thirty people was wishful thinking, by the start time we had two full tables. The low numbers were probably due to the event being event in the Christmas season.

While guests were entering and eating the free pizza, I wondered around introduced myself. Asking what had brought them here and suggesting that they post their question or topic on the provided wall charts. From member I think we ended up with eight topics being suggested by the participants.

After brief introductions from our sponsor and the meet-up organiser, I got everyone on their feet and used dot voting to select two of the eight suggested topics. There were a couple of clear winners, which made it easy to start the two tables discussing each topic.

As a group we decided as a group to drop down to ten minute discussion rounds. This allowed us to get through four topics in total.

I time boxed us to ten minutes of discussion, followed by a couple of minutes to switch tables and then another ten minutes of discussion. The conversations that occurred where very animated. It was a real struggle to stop them and get us on to the next round. After the first topics had been discussed by both groups we had the topic leader provide a quick overview which sparked even more discussion.

With roughly half of our planned time used up we used dot voting again to select another two topics and do it all again. Again we had very energetic discussions, which were constrained by the ten minute boundary.

The result was these sheets of butchers paper, which fail to convey the excitement and energy that was in the room.

Result: Agile Contract Models

Result: Introducing Agile into a large organisation

Result: What is more effective Scrum of Iterative Waterfall and Why?

Result: Agile estimation

We ended up with some very satisfied attendees. Some left with a much better understanding of agile, another walked away with an action plan for how he will sell agile to the management group in the company he has just joined. Everyone seemed to walk away happy.

I whole heartedly recommend you to run your own World Café; it is easy to set up, exciting and harness the energy of the participants.

*At the time of the World Café it was actually a separate group ‘Brisbane Scrum and Agile’ Group, however it has since merged with the ‘Brisbane Lean and Agile’ group to become ‘Brisbane Agile’.

Photo by: Travel Fools of America