What do high-performing teams need in the real world?

I recently watched one of those skits on the Amazon show The Grand Tour (S3 E11) which surprised me with its rather sensible conclusion. The loveable presenters each had a luxury performance car and were competing against a professional racing driver in a rusty aged saloon across 50 miles of "real life" roads: intraurban traffic, motorway, rural roads and finishing in a medieval town centre with cobbled streets. The conclusion was that all cars in the real world go at the same speed because how fast they go is dictated by external factors, not the car itself.

This is a great analogy for how the pace of a potentially-high performance team is often limited by environmental factors within an organisation and they end up performing broadly the same as any other team.

The cars in the urban and rural environments couldn't pick much speed because of factors such as pedestrian crossings and farm animals on the road respectively; overtaking other cars was virtually impossible in both cases. In organizations where all teams must compete for the same resources (my new team member needs a laptop...) and services (...and they need IT's help in getting started) the potentially high-performance team will wait just a long as everyone else.

Even on the motorway, the cars all went at the same speed because there were speed cameras every 100 metres. This put me in mind of agile teams slowed due to the enforcement of traditional governance policies.

Interestingly, when the race concluded in the medieval town, the experienced racing driver in the ordinary car had a distinct advantage: they could pick up pace, not getting jackknifed on the awkward changes in level, not caring about the occasional ding when clipping corners. This reminded me how an organization's "people assets" are most valuable because they know how to get things done in the existing environment, usually by having a network of useful people. How often do we see newly-formed teams of expensive contractors with so much potential fail to make progress because they don't have anyone to tell them how to effectively navigate the organization?

What changes need to be made to a team's environment to allow them to be high performing in the "real world"?

Your Community Needs You?

I occasionally get asked by someone who has their sights on a job as a Scrum Master or Product Owner how they can get the experience the job adverts ask for. It also is regularly asked in a certain agile Slack community I frequent (you know who you are, awesome people). 

One of standard replies is to find an organisation who would appreciate some help on a voluntary basis. That sounds like good advice to me but I've always wondered, does anyone actually follow it?

My mind has turned to this recently from a personal perspective. I feel I have things to offer for which my current client have no direct need. For example, it has been a while since I worked with a team in a start-up company and I miss the challenge of getting a fledgling product to a new market. Could there be a company out there who has a need for what I can offer who are also wondering how to connect?

Now that I think of it, one of the reasons I visit the aforementioned Slack community is to exercise muscles that I don't use everyday. There's no denying the altruistic rush when the someone likes my answer, whether it's from  my respected peers or the person in need saying, "Thanks, that helps!" It goes some way to meeting the need I have to feel I am contributing to the wider community but I certainly have more to offer.

So how does someone go about finding an organisation willing to take on a volunteer agile practitioner? Are there organisations out there that already know an agile coach is exactly what they need? Are they looking for more general 'business' help for which a Scrum Master is a fairly good fit? Do companies really bring someone in and share intimate details of their business without the person they are engaging being 'invested' in the outcome the same way as, say, an employee would?

If you have any insights, please leave a comment.

Essential videos

What We Actually Know About Software Development, and Why We Believe It’s True, Greg Wilson's CUSEC 2010 Keynote - (67 mins)

https://www.youtube.com/watch?v=I0Pt9Lf9JzQ

Software Engineering's Greatest Hits by Greg Wilson (28 mins)

https://www.youtube.com/watch?v=HrVtA-ue-x0

10 Things Scrummers Get Wrong by Jim Coplien (122 mins)
https://vimeo.com/42772592

Agile Fine-Tuning by James Coplien (58 mins)
https://vimeo.com/13324992

Kanban Columns by John Cutler (5 mins)
https://vimeo.com/284632621

Why Work Small? by John Cutler (8 mins) 
https://vimeo.com/252572259

Value and Debt by John Cutler (8 mins)
https://vimeo.com/252433474

The resource utilization trap demo (5 mins)
https://www.youtube.com/watch?v=CostXs2p6r0

There's a Scrum Event for that (3 mins)

https://www.youtube.com/watch?v=Gp9agRq8S8c

Feature Injection a.k.a. teabag (28 mins)
https://www.youtube.com/watch?v=hZdYR1fb4Gk

Conversational Transformation by Jeffrey and Squirrel (31 mins)
https://www.youtube.com/watch?v=RMT_Tqzf_vc

What is an Agile Coach? Lyssa Adkins & Simon Powers (76 mins)
https://www.youtube.com/watch?v=4OC_j8LwIMw

Beyond Estimates: Estimates or No Estimates - Woody Zuill (71 mins)
https://www.youtube.com/watch?v=hLNDih4BVZU

Beyond Developer by Dan North (53 mins)
https://www.youtube.com/watch?v=wYEk0y8LYfg

Patterns of Effective Teams by Dan North (51 mins)
https://www.youtube.com/watch?v=lvs7VEsQzKY

Cynefin in Action by Liz Keogh (51 mins)
https://www.youtube.com/watch?v=G2X_7ojZwtU

Beyond continual improvement by Russ Ackoff (12 mins)
https://www.youtube.com/watch?v=OqEeIG8aPPk

Conflict resolution using NVC (3 mins)
https://www.youtube.com/watch?v=ii2xRt3nR_c

Identifying Impediments by Samantha Laing and Karen Greaves (4 mins)
https://www.youtube.com/watch?v=MG9mP0LhrJA

What went wrong with the IT-industry? by James Coplien (47 mins)
https://www.youtube.com/watch?v=gPP7Bleg214

Swearing, Nudity and Other Vulnerable Positions by John Le Drew (83 mins)
https://www.youtube.com/watch?v=V1fbNSMj4JU

Ian Sense, Scrum Master - fun with Jeff Sutherland (5 mins)
https://www.youtube.com/watch?v=oheekef7oJk

Building a psychologically safe workplace by Amy Edmondson (11 mins)
https://www.youtube.com/watch?v=LhoLuui9gX8

No More Managers by Mel Pullen (24 mins)
https://www.youtube.com/watch?v=TrBYUzn8eGI

How Too Many Rules at Work Keep You from Getting Things Done by Yves Morieux (17 mins)

https://www.youtube.com/watch?v=t__NoFstCmQ

Acceptance tests for a Sprint Goal

Second half: There is no reasonable expectation of it being achieved in the first half of the Sprint, otherwise it may not be encompassing enough. If your team is regularly completing Sprint Goals early, consider having shorter Sprints!

Connective-free: It doesn't contain connectives such as the word 'and', commas, semicolons, slashes, etc.

Obviable: It has the potential to become obsolete. A Sprint Goal that cannot be invalidated is likely be too vague and not targeted at a specific enough use case. Also consider whether the team are engaging with the customer community to know when the market has moved on.

Negotiable: The team can reconfigure items on the Sprint Backlog (drop them, swap them) and still achieve the Sprint Goal.

Egalitarian: It can be verified by anyone on the Scrum Team as having been achieved. It may not be objective enough if it requires the subjective opinion of the PO.

#CreamFirst

Essential Android apps for Scrum Masters

Native mobile apps:

Post-it®

https://play.google.com/store/apps/details?id=com.mmm.postit

Decision Roulette
https://play.google.com/store/apps/details?id=es.treebit.decisionroulette

Giant clock
https://play.google.com/store/apps/details?id=com.bojankogoj.giantclock

HUGE Stopwatch
https://play.google.com/store/apps/details?id=huge.stopwatch

Large Countdown Timer (Timesloutely)
https://play.google.com/store/apps/details?id=com.mta.countdown

Multi Timer - Stopwatch Timer
https://play.google.com/store/apps/details?id=com.egg.multitimer

Liberating Structures (LiSA)
https://play.google.com/store/apps/details?id=de.holisticon.app.ls

Mobile versions of browser apps:

Miro - formerly RealtimeBoard Online Whiteboard
https://play.google.com/store/apps/details?id=com.realtimeboard

Kanban Tool
https://play.google.com/store/apps/details?id=com.kanbantool

Trello
https://play.google.com/store/apps/details?id=com.trello

Is missing the Sprint Goal an automatic 'fail'?

I received the following quote in response to an earlier post about a Dev messaging the Product Owner about a change of plan mid-Sprint that would likely involve missing the Sprint Goal:

I'm troubled with this. Why did the team fail to reach the goal? How come there is room for extra tasks (new goal?) but no discussion of reducing scope? Is the current goal validated to be important and will the new tasks increase the chance of it being reached in the next sprint? Showing UI to stakeholders is nice but it could have been done with mocks/wireframes too. And if it has, then the feedback will anyway be expected, so what's the value of that?

Thanks for the feedback. As with all great feedback, it has made me think a lot, which is always a good thing :)

First, let me point out that at the time the message was posted, the Sprint Goal had not been missed. Rather, the Devs decided it was at risk mid-Sprint and they wanted to make this clear to the PO. In the days leading up to this point, the Devs had expressed concerns as regard meeting the Sprint Goal at Daily Scrum when the PO had been present. So this wasn't a bolt out of the blue, rather an escalation of threat level. This is a subtle but important point. But for this discussion, let's assume it is the end of the Sprint and the goal had not been reached.

In order to respond to you, I imagined the feedback had come from a stakeholder during Sprint Review. Let's say, one of the Devs had opened the meeting by referring to the Sprint Goal (which would be written on the board at the front of the space), had said the words I posted in the thread (but that the Sprint Goal had not been reached) and the CEO had said your words to the group before hearing any further context. What would my response be?

I think my reaction would be that the safety of the space would be under threat and I'd be concerned that the Devs would think that they were being attacked. I must say here that in these Slack channels I think we have a different kind of safety. I think as coaches and - I hope - mentors to each other, we can hold each other to account in a more 'robust' way where good intent is assumed. I coach my the Scrum Teams to show their 'public face' during Sprint Review and to save holding each other to account to the 'private' space we create during the Sprint Retrospective.

So I think my response would be to protect the team in the moment and close the situation down. I'd thank the CEO for their feedback. I'd remind them that during the Sprint Review the team will speak about "what problems it ran into, and how those problems were solved". I'd suggest that by the end of the meeting the context for missing the Sprint Goal would be clearer. Finally, I'd offer to speak with the CEO, and any other stakeholders, at some point after the meeting to address any remaining concerns.

The context for the Sprint Goal being at risk involved some impediments.

The team have recently on-boarded a new person and this is their first full Sprint with this team and this company. We knew this would impact the team but we couldn't know exactly how: we'd have an extra pair of hands but would they would need attention from old hands. Another factor for Sprint Planning was knowing that a Dev would be on holiday for 50% of the Sprint, which is always a challenge as regards ordering of tasks and adjustment of what some teams call 'velocity'. As the old adage goes, "It is difficult to make predictions, especially about the future."

We also had emergent impediments. A team member went off sick for a few days, which always has an impact on ability to deliver and couldn't have been foreseen. Another unforeseen event was the office losing internet access for an entire day: some of us travelled home to work remotely once our IPs had been white-listed but two devs on this team weren't able to work from home and had to make do without full access to systems.

When you refer to extra tasks, I wonder whether there has been some fundamental misunderstanding and if so I must apologise for not making things clear earlier. When the Dev says, "We have identified a number of extra tasks as part of the [redacted] work", they are referring to emergent understanding of the required work.

Here is a quote from my favourite Scrum Book:

"Scrum is an extreme sport and [the Scrum Team] enter into a Sprint with some risks in order to go faster. Their primary risk is emergent requirements" [1]

From the Scrum Guide:

"The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal." [2]

So it is not the case here that the Development Team have taken on new work unrelated to the Sprint Goal, rather they have discovered the normal and expected emergent work directly relating to the Sprint Goal. Either the amount is more than was forecast during Sprint Planning or the impediments resulted in too much lost time to cover the correct forecast.

Note that the Sprint Goals this team sets itself are not of the 'Do these five backlog items' variety. As is my usual approach, I've coached the team (particularly the PO) to encompassing, challenging goals that exist more in the 'problem space' and solutioning is avoided until we get into the Sprint proper. When we leave Sprint Planning, we have agreed that some kind of solution is likely given the time and people's availability but we haven't got detailed designs for every element, we haven't resolved all dependencies, we only have some of the tasks identified and on the board, etc. This is by design and honours the spirit of Scrum.

When the Dev referred to 'prioritising UI changes', they were alluding to vertical slices. Although the team have the mindset of creating product increments each Sprint that are vertical slices, the tasks in the Sprint Backlog have so far been more horizontal. The message from the Dev is that the work completed so far is missing an important element of vertical slice, being the UI. A wireframe would not complete the vertical slice and a fake would not meet the Definition of Done. Completing the UI is also important because it would allow the UI automated tests (both UI unit tests and end-to-end tests that target the UI) to be completed, again a Definition of Done requirement. I coach the team to only consider 'Done done' work as being part of the product increment and only share 'Done done' work at the Sprint Review.

In summary, the Development team favoured 

a safer bet on completing a 'Done done' increment of product that represents a vertical slice but falls short of the Sprint Goal 

over 

optimistically running at the Sprint Goal with a high risk of ending up with an increment that meets the Definition of Done.

Although I think there were failings that led to this point (and I will be picking these up later), I fully support the decision they made and how they went about in given the circumstances at the time.

Ultimately, I cannot answer questions such as "Why did the team fail to plan better to reach the Sprint Goal?" or "Should the team have protected the Sprint Goal better?" or "Have the team make serious errors of judgement?" That's for the team to analyse and decide on during Sprint Retrospective.

[1] 'A Scrum Book: The Spirit of the Game' by Jeff Sutherland, James O. Coplien, and The Scrum Patterns Group (https://pragprog.com/book/jcscrum/a-scrum-book)

[2] Official Scrum Guide, Ken Schwaber and Jeff Sutherland, accessed 9 June 2019 (https://www.scrumguides.org/scrum-guide.html#artifacts-sprintbacklog)

KPIs as an Agile Coach

I'm always saying to leaders that we'll know I'm having a positive effect when we hear certain language being used.

I've noticed a progression as regards changing conversations. This might reflect UK culture or be more to do with my personal approach. The progression goes something like this:

Early on: a team member will say, "Because Jamie is present [knowing laughter], I should say..."
Later: "As Jamie would say [smiles], ..."
Finally: It just gets said. The fact I introduced it is - rightly - no longer a consideration.

Below is a fantastic example of exactly the kind of language I love to hear team members using. Note this is a verbatim quote (product-specific details) as posted in the team's Slack channel, used with permission:

"Dear [Product Owner], As you missed stand up you should know we believe we will not meet the sprint goal 😞 We are going to prioritise the UI changes now so we have something to show and get feedback on. We have identified a number of extra tasks as part of the [redacted] work. Most of these are not unique to this piece of work and will likely see reuse in other stories (even if only as patterns). We have made a number of good learnings this week and the work around [redacted] in particular should help benefit the upcoming [redacted] work. Happy to discuss further if you want."

Notable features:

• The team member took the action unprompted.
• They have reflected what was agreed collectively at the Daily Scrum. Note that the PO was unavoidable detained elsewhere.
• It makes clear to the Product Owner that Sprint Goal will not be met. While they had considered whether the Sprint Backlog could be renegotiated to satisfy the Sprint Goal, on this occasion they decided that it couldn't without incurring technical debt.
• Mild regret is expressed for the shortfall. As per Toyota, "There can be no kaizen ['improvement'] without hansei ['reflection']." [1]
• It underlines that what the Development Team have learned this Sprint will genuinely have positive effect on upcoming Sprints. That is, they are not making excuses for failure; rather, highlighting their successes despite the Sprint Goal being missed.

When I started with this team, language like this would simply not have been heard. Sprint Goals were afterthoughts (punchlines!), hastily written after a Sprint Backlog had been assembled. Un-Done work at Sprint end would occur frequently and was always carried over to the next Sprint without discussion. Product Backlog items read like mini-specifications rather than hypotheses to be experimented on to provide learnings. Sprint Reviews were demonstrations of Done work rather than conversation starters to get feedback from stakeholders. 

Change has been brought about by taking a multi-faceted approach, including:

• leading by example
• role-modelling desirable behaviours
• agreeing a code of conduct
• introducing new practices and challenging entrenched ones.

Teams can change their language in a positive way when they have incentives to do so, given adequate time and the right guidance.



Here are some KPIs suggested in the Hands-on Agile Slack community:

• Whether the team is meeting the stated goals of (a) the company and (b) customers and their users.
• Whether team members would recommend me as an Agile Coach to other teams/organisations.
• Whether the team is establishing their own KPIs and working collectively toward them.
• Whether the team engages in healthy conflict (e.g. seeing team members challenging each other firmly then going together for lunch and cracking jokes).
• Whether the team is feeling safer.
• Level of team happiness.