■Author profile■
The author, Alan Plunkett, leads digital delivery for the Gender Pay Gap services on GOV.UK, based in London.
He has led strategy facilitation and change programmes for the past twenty-five years. In previous careers, he practiced earthquake engineering and management accounting.
The views expressed in this paper are personal to the author.
A story of Agile in the UK Government - “See-hear-speak” ? ? ?
See-hear-speak, in that order, is not how most leaders lead. More the reverse. But it does serve us well when it comes to agile.
There are many agile books out there that will tell you what you need to know about agile techniques and processes. Less so do they bring to life what the agile manifesto means by “individuals and interactions over processes and tools”, “customer collaboration over contract negotiation” or “responding to change over following a plan”.
This paper aims to shed light on those values. It sets out some ways of growing and leading agile teams that I hope will help you in your daily practice. It draws on the experience of the agile team in launching the UK’s new gender pay gap services.
Bit of context on the Gender Pay Gap (GPG)
The gender pay gap for an organisation is the difference in pay that women “on average” earn compared to men. This is not the same as equal pay.
These gaps are now published in the UK via the Gender Pay Gap service Https://gender-pay-gap.service.gov.uk. Since launch in 2017, all employers with more than 250 employees, some 10.5k public and private and charitable organisations must report their GPG data to this website.
Most organisations reported in 2018 that women were employed in lower paid job roles than men. They earned 83p for every £1 that men earned.
ーStart with big purposeー
Big purpose is not unique to agile but it sure feels vital. To inspire hope, give meaning and to gain commitment from people. Resources, both people and money then follow to make the change happen.
This was certainly so for GPG. Its big purpose, to close the gender pay gap in a generation, is keenly felt by many women and men who share a different view about what’s fair, what’s good for the economy and what’s good for society.
Unusually, GPG is a cross-party initiative in the UK parliament. It has the support of all the big parties. Politicians, policy folk and “influencers” engaged with big employers to back it, crafting effective regulations and releasing funds for digital, communications and research.
With initial funds secured, the agile digital GPG project was born in September 2016. The work started with equal measure of excitement and trepidation about what it might be and its chances of success.
ーEmbrace the unknownー
Who knows how to deliver that big purpose! That’s the point of agile. It sets out some structures and mindset to navigate your way through unknowns – both known unknowns and unknown ones.
There was much to discover about GPG digital services:
We use scrum structures to help us navigate. They encourage us to have a go to and see what works and what doesn’t! We’ve always got a big backlog of stuff we would like to do and each two weeks (our sprint cycle) we work out what’s important to do now. In scrum, this is called backlog prioritisation. Its perhaps the most obvious signal that we’re always in the land of unknowns and must keep an open mind.
We do have a contracted plan laid out over a year but our two-weekly cycle of backlog prioritisation has always been more important than following the grand plan.
Procure with “agility”
There are plenty of horror stories about projects gone wrong – not just digital ones. Scope creep, budget overruns, late delivery, poor quality – you name it.
Which is why the Government Digital Services (GDS) now procures all new projects in agile phases: Discovery, Alpha, Beta. This agile procurement keeps the buyer in control with flexibility to change course, through the disciplines of:
• Short contracts to learn and develop
• Contracting the next phase only if the previous one passes muster
• Reinforcing experiment and evidence to decide where to next
At GPG, the reality of what comprised our “Minimum Viable Product” changed a lot through the course of our Alpha and Beta phases. We would have liked to have launched with a database of employers who should report but couldn’t. We weren’t sure about the acceptability of publishing data for the public but there was strong political support.
Procuring with agility did not guarantee our success but it sure set us on the right path.
See- hear -speak (in that order) ? ? ?
No matter how smart, how much money, power, authority or charisma you have,
you can’t know it all or know what’s right for those you lead. It’s the same on agile teams. Try telling experts from different races, genders, ages, cultures how to do their job. Not sustainable right.
At GPG, we hire folks who bring something different to the agile team. And we practice “see-hear-speak”, borrowed from the Japanese saying, to make sure they are seen and heard.
To “see” others, we ask the question: what’s going on for them? Are they engaged, happy, anxious, curious? Why? To “hear” them, we listen hard to know what they think…how they feel…what they need? Only after seeing and hearing others, do we “speak” and offer thoughts.
This practice has proven critical for us in the land of unknowns where there are unintended consequences for the unwary. The new evidence or “crazy” thought that allows us to see something in a new light has often come from the softest spoken, the most distant, the youngest person in the team.
At GPG, the role of “scrum master” is, yes to coach the team in the practice and mindset of agile, but foremost to safeguard “see-hear-speak”.
Balance your me-us-it
The agile manifesto for software development considers individuals and interactions more important than processes and tools. This applies equally to other types of project.
“Me-us-it” helps us on GPG to make this happen. I see it as a natural partner to “see-hear-speak”.
• Me: with focus on how do I feel? what do I need to get better at my job, to fit in with home needs?
• Us: with focus on are we working together to solve this problem? And questioning why do I get triggered by John’s behaviour?
• It: with focus on my individual “to-do” list
As with most projects or work environments, the “it” stuff dominates our time, taking up 85+% of our day. Even though we limit planned activities to 6 hours a day!
To counter this, we now consciously strive for more “me” time: gym sessions, café catch-ups, leaving early to be with the kids, learning something new. Daily stand-ups help maintain this – an opportunity for each of us to check-in, connect and see and hear others.
We put a premium on the “us” through the scrum discipline of “retro”. This is where we talk together about what’s really going on between us and how we need to change. The outcome of our discussions has ranged from more “collabs” (more about those later) to “fix the wi-fi” to more personal feedback on behaviour. This can be a bit bumpy!
Better balance of “me-us-it” is certainly makes us more creative and productive. When the going gets tough, it helps us maintain our poise.
Add value every sprint
Remember that big purpose we talked about. Someone benefits from purpose. Normally more than one stakeholder. For GPG, the prima-facie beneficiaries are women entering or returning to the workforce and those wishing to be employed in more fulfilling roles. But it turns out that shareholders benefit too. As do customers and men and communities.
We can’t measure all of the political, social and economic value of closing the gap on our digital project but we do take care to measure value being added every sprint.
We do this by setting proxies or indicators of value for our intended beneficiaries. For us these include employer ratings of ease and safety of reporting and annual compliance of report submission. For both employers and staff and interested members of the public, we measure if they understand what the pay gap data means and what they can do about it.
We can do this every sprint by use of prototypes of web pages and discussions during user research and usability testing. We also do this by making changes to our live website and seeing how user behaviour changes using google analytics and transaction logging. Where do users click and on which pages do they spend the most time?
Most of all, by measuring value add in these different ways, we make sure to stay aligned to our purpose.
Change your mind
Its more than Ok to change your mind about what works best to deliver your purpose – that’s the whole idea of agile.
The constant drumbeat of measuring value-add every sprint (ok we don’t make it for every one!) helps us change our mind. It reinforces evidence-based decisions, mitigating the voice of the loudest or most powerful during backlog prioritisation.
Sometimes you see something new but it’s so surprising you’re really unsure. When that happens, we do more research and testing to check it out. One big surprise for us on GPG was the realisation that most people don’t understand the GPG data that employers are publishing. It doesn’t translate easily to their need for part-time work, to feel fulfilled, to balance child care or transparent pay levels.
It turns out that these are all critical factors when it comes to actions for closing the gap. So, the opportunity presents to link GPG data more closely to different language and content to be more effective in delivering our purpose.
Get value out the door fast with 80/20
We’ve found this to be one of the toughest disciplines of scrum …close up there with see-hear-speak and me-us-it. What 20% of the stuff we could do will add 80% of the value for our users?
The drumbeat of backlog prioritisation using the 80/20 rule keeps this question ever-present. So does the agile concept of “Minimal Viable Product”. This calls for the minimal output that we can get out the door now. To build trust with our users that we are moving in the right direction, to evidence value and to provide the foundation for improving later.
You will always feel tension between getting something out there now and getting it right.
And sometimes it is better to wait. On GPG we ended up taking a lot of time to test how best to translate gap percentages into £ and pence. What seemed like a small change added big value to user’s understanding. Figure A or Figure B.
Beware natural frequencies of vibration
In earthquake engineering, I learnt that buildings and bridges prefer to vibrate at certain frequencies. Civil engineers don’t want their structure’s natural frequency to match the dominant frequency of the likely earthquake because that will accelerate catastrophic failure (as happened at Tacoma Bridge).
It’s the same with agile scrum teams. Because the GPG team is diverse (young, old, male, female, international, technical, business, thinkers, feelers, fast, slow) team members vibrate at different frequencies in response to events! That’s what you want. It avoids group think and driving off the cliff together.
It does make for bumpy retros and collabs though that to the uninitiated can feel like “chaos”. It isn’t. I call it human creativity, learning and communication at work.
“Collab” with the customer - as well as in the team
If you’ve read this far, you’ll have seen that connecting is a big theme of agile working.
Connecting with self, team mates and users. But you must connect with the customer plenty too.
The agile manifesto in software development sets out the principle of customer collaboration over contract negotiation. The customer doesn’t know the answer to their problem – that’s why you’re there to help. So involve them early and often in your discovery and iterations.
On GPG we plan customer “collabs” each sprint. We even created an item type in Visual Studio called “collabs”. I look for them in each sprint and worry if I don’t see any.
These will always involve the “Product Owner” but you also want the relevant
policy, legal, communications, political and Treasury folk as well. That safeguards vibrating at the same frequency!
You’ll want to co-locate your scrum team close to the customer too to foster communication. Make your corner fun to attract attention …and to get folks talking.
In our experience, collabs are different from normal meetings. The person in the chair does hold the agenda on behalf of the group but most of all they safeguard see-hear-speak and something we call “holding your positions lightly” …
Hold your positions lightly
You can’t see and hear what others are thinking and feeling if you already know the answer. You’ll be too busy in your head working out how to combat what the other person is saying.
So, hold your positions lightly. Listen with an open mind and open heart. That guarantees that everyone gets heard and you avoid resonant frequencies.
On GPG, we use a small green cushion that gets passed from person to person. If you hold the cushion, it’s your time to speak and be heard. We use the cushion at stand-up, during retros and for collabs. We don’t always need it but it sure comes in handy.
If that’s not enough, try asking folk to playback what they’ve just heard. You may be surprised to hear them playback what they are thinking, not the other person’s view.
Fail predictively
Earthquake engineering is different to other civil engineering. You can’t do what I’ve seen
quantity surveyors do which was to plan and cost a structure in 1 hour or less of a briefing. Stunningly, the final cost and duration of build would come in within a 5% margin.
In earthquake engineering, nobody knows when the earthquake will come. Nor how big it will be. Earthquake engineers use probability curves to plot scenarios. In the case of an extreme (= black tail) earthquake event, it is simply too costly to design for sustainability of your structure. You expect it to be a write-off and your job as designer is to mitigate loss of life.
This means that you need your structure to fail predictively. In a building, you want a rigid column more than you want a rigid beam. That’s because if the column fails your building falls down. If the beam fails, it absorbs energy and the structure remains standing.
In GPG, the equivalent to column failure is crashing of your website under extreme traffic. This is where you undo all the value you’ve added during many sprints!
So, we’ve built redundancy and core stability around the bits that count most, with flexibility to scale-up our servers at a moment’s notice when the stress comes on.
Since GPG requires employers to send in their GPG data only once per year, at the end of March, we did anticipate low traffic for most of the first year – as you can see in the graph below with a last-minute rush in the final few weeks.
We didn’t quite reckon on the extent of the tail. We received 15% of all reports on the final day but more than that, on the back of media stories, we experienced a spike of over 500k hits on that last day too. The redundant servers kicked in so all was well… but it was a good lesson for all.
The same principle applies to the make-up of your agile team. Decide in advance where you’ll add redundancy and add it because when the black tail event happens, you may just not have time to avoid failure.
Spot patterns
I wanted to share one final insight borrowed from systems dynamics.
There is a shadow side to 80/20 and adding value fast each sprint. What at first seems simple may deceive. You win in the short term you win but later the unintended consequence pops up!
You did see that iceberg but you didn’t see what was beneath.
On GPG, we did see transparency of GPG data would draw attention and website hits on the back of media stories. But we didn’t see that many users didn’t understand the data they were seeing. And so, the resonance was somewhat lost.
We used a simple pattern from psychology to help us. Humans are good at seeing the relative – more so than absolutes. We introduced comparison tables so that users could select several organisations to compare then rank the data from these organisations. This helps employers and staff be clearer about where they stand (good or bad!) and stimulates action to close the gap.
Patterns like this are out there. You may find them in other professions - software engineering has plenty of them, as does civil engineering. Or of course you’ll find that the pattern that works for you emerges over time. Do let it emerge.
ーEnjoy the learningー
In summary, agile for me is a lot about learning…about ourselves, us, them, what’s really going on and what works. You will be forever curious, busy and fulfilled if you embrace its spirit.
And since good mental health and well-being has been proven to depend on relationships and connections, it may not be overstating it to say that agile will be good for your mental health!?
