Tag Archives: agile

Designing the mod(ern) squad


squad

/skwɒd/
noun
a small group of people having a particular task.

Background

I recently wrote about our new Squad Manager role(s) and wanted to just dig in a bit to how we see our squad model growing and evolving.

Like many companies and organisations we follow Spotify in referring to our agile delivery teams as ‘squads’. The basic premise of a ‘squad’ is a multi-functional team, of 10ish people, working in an agile manner with a specific focus.

Notbinary predominately supply software engineering squads with some additional capabilities (BAs, user research, architecture, data science, SREs and of course our Squad Managers) to deliver agreed outcomes over set period of time…give or take.

Sometimes this is Alpha →Beta → Live type stuff. Sometimes it is more feature factory style. We occasionally do Discovery work but to be honest we probably have a relatively narrow niche there and over time I suspect we’ll work more closely with partners to undertake more of that type work.

While our squads may vary in size and shape depending on the gig but they all have some common elements and ways of working and this post is me trying to articulate that. Some of this is how we are already operating, some of it is imminent, some of it is aspiration.

Nucleus

Chief Squad Officer

At the core of every Notbinary squad is a partnership. We rely on the double act between the Squad Manager and the Principal Engineer to lead the squad and set the tone. Their is a wider Notbinary culture but each squad is unique and within a broad framework they set their ways of working and approach.

They are supported in a servant/leader style by the Engineering and Squad Directors who oversee a larger portfolio of squads and relationships with our partners plus also the Chief People Officer who oversees hiring — both permanent and independent contractors.

Each squad leadership partnership will also (eventually — we are still working this out) be assigned an ‘early career engineer’ to mentor and work with on projects. This will probably need a blogpost of its own but I’m keen we find a route into this type of work for people from different backgrounds (maybe via bootcamps, online courses, hackdays??) and give them a chance to work on real projects early but with suitable support.

Almost every squad will need a business analyst (usually on the feature factory side) or a user researcher (on the GDSesque style delivery lifecycle). I haven’t quite worked out whether this is an additional ‘nucleus’ role. I have warmed to the idea of ‘slash’ roles (BA/UR for instance) as I have worked with a couple of great ones recently — but I suspect they are still a bit Unicorn-y. From a personal point of view I have been lucky enough to lean on some really good user researchers over the years and they are often the difference between failure and success. I suspect I’d like to get to a point where we add some kind of research capability to the squads by default — just need to work out what that looks like.

To be clear those roles will always be in the squads one way or another — via our partners, our network or our contract hiring — the question is whether they become a permanent member of this settled core team.

Additionally I can see a need for a number of other specialist roles that are permanent staff that act more like floating specialists supporting the squads as needed. In particular I can see a need for ‘Site Reliability Engineers’ , ‘Data Scientists/Engineers’ and ‘Cyber Security’ specialists who can provide advice, support to squads and occasionally drop in for a sprint or two.

Something that I think will help stitch all this together is the idea of Concierge role — different than a PA — more like an old school travel agent or a dispatcher— who makes sure everyone is where they need to be, with whatever they need for a comfortable, productive stay. That is probably another blogpost but the more I mull the idea the more I like it.

Another diagram to trigger some folks 😉

Network

The Network

Now that is already a lot of words but given I previously said that squads are often around 10 people I have maybe only covered half the team.

The reality is the rest of the squad comes from ‘the Network’ (not the Green Day side project I just discovered on Google!). Many squads are cobbled together from independent contractors — often a few will have worked together before. The high performing squads often having a core of pre-existing relationships and chemistry from day one. It isn’t unusual though for them all to meet on day one. This can still work fine if they are a good mix with talented leadership but it is a risk.

I am all for minimising risk.


Notbinary is now part of TPX — a fast growing digital transformation group. Our partners already include Manifesto (who recently acquired Deeson), Greenshoot Labs, Questors and Bene Agere. The growth shows no sign of slowing any time soon. So our immediate Network already includes expertise in UX, front-end development, software engineering, AI, chatbots, digital strategy and performance analysis amongst many other things.

Now I’m not saying the intention is to have an internal group market loaning staff around willy nilly but there are opportunities to take advantage of the breadth of skills available now and that is a lot more nodes in the network than just us.

Broadening the network is vital — I want to empower our squad partnerships to form their own teams and I want them to work with people they know and trust whenever possible — but the reality is that isn’t going to always happen so the more people we are aware of who are a directly known quantity to people within the Group the better.

The Talent Manager

This is all going to take some kind of ‘Talent Management’ operation — Database/CRM of whole network of independent contractors who are known to or recommended to our Group with their skills, availability, day-rates and ‘riders’ (London only, max three days on site, never work next to an Indian burial ground…). Keeping on top of this feels both bloody hard and equally important as we scale. Not to mention continuing to build a culture and offering that appeals to these people.

s-minus-1

https://media.giphy.com/media/ALQ6OXrBDqBWw/giphy.gif

This is another stub of an idea I am currently thinking through which will likely result in another blogpost.

I can’t find the reference but the idea that everytime you make any change to the make up of a team it is essentially a new team means that no matter how much effort you put in to have a stable core in your squad each time it lands it is a thing thing. To counter this I have been thinking about what I am calling s-minus-1 (basically Sprint Minus One — something before Sprint Zero) where you bring the team together for a few days, offsite, in a room and basically give them a bit of time to get their shit together, find their voice, agree all the admin and ways of working — away from the view of the client. So when they land on site they are ready to roll.

Well that turned out to be longer than I planned! Obviously had a bit on my mind.

What the Forking Here* is a Squad Manager?

https://media.giphy.com/media/3o6fJ8baw3aDgUQnJu/giphy.gif

I’ve learned a lot in my first year working for Notbinary — the nuts and bolts of it is pretty well covered in this post from Sean Tubbs about making the switch to consultancy life. A big lesson however is that some of the key positions in the ‘squads’ we provide are a little different from when you are on the other side of the table. In particular the ‘Delivery Manager’ role has a different shape to it from this perspective. To such an extent that as we are now fully in to hiring mode at Notbinary I have been looking for a new job title that is recognisable but clearly its own thing.

Enter the ‘Squad Manager’

Created just to upset data vis snobs 😉

The Squad Manager does undertake the role of ‘Delivery Manager’ on the ground with our squads. That is the role that would map best to the DDaT framework and would likely be how we would describe the role to clients. They need to have a deep understanding of agile ways of working as well as things like ‘Lean Start-up’ approaches and given our main market they totally need to understand the Service Standard. They take care of the squad and make sure it has what it needs to succeed — they are also responsible for keeping everybody up to speed with progress (clients and colleagues).

They might have gained all that understanding as a Delivery Manager, Agile Coach, Product Owner or a myriad of other opportunities. We are open to people from different ‘professions’ — a holistic attitude towards modern agile rather than a dogmatic single framework approach, a passion for building great teams and an understanding of what it takes to make these ways of working actually work in big bureaucracies is the most important thing.

They will need to do other things though — they will be the representative of the company to the client and as such there is inevitably an element of Account Management in the role and while we would never expect our delivery people to do ‘sales’ on the ground there is a requirement for a certain amount of commercial acumen.

There is often a client coaching element in the role. Product Owners might be relatively new to working in this way or simply new to their roles. Our ‘Squad Managers’ should be experienced and a little battle-hardened(!) and willing to add value to the projects by providing whatever support they can — even if it is just access to a wider network and relevant introductions.

They will also inevitably be the local admin manager as well — ensuring timesheets are filled in, fielding questions about processes, making sure absences are recorded and a myriad other small tasks that contribute to day to day work life.

Finally (well apart from everything I have forgotten) they are guardians of the space — successful squads have a home to call their own and our Squad Managers need to do all they can to ensure that and to then protect it. Not always easy when you on a client site!

These roles are vital to the model we are implementing (a future post will explain the important of the Squad Manager/Principal Engineer double act we see as the core of all our teams.)

We are on the brink of actively recruiting a number of ‘Squad Managers’ — we are just completing the salary bench marking before we make that public and are currently just sorting out our benefits package going forward but if you want a sneak peak of the job description it is here on our Github and you can AMA at matt@notbinary.co.uk.

*https://thegoodplace.fandom.com/wiki/Censored_Curse_Words

Ways of working (in progress)


This is an attempt to write down the approach we are starting to formalise around our ‘squads’ — it is a work in progress but is starting to make sense. It is inspired by working practices I witnessed or experienced at Defra, mySociety, ONS and elsewhere →

We work in the open by default — if something needs to be dealt with in private we deal with that be exception.

What open looks like for us:

Github

A new squad gets a new repository on the Notbinary Github.

This repository is used for:

  • Online Kanban board (Github Projects)
  • Issues are used for tracking ongoing tasks
  • All code and prototypes
  • Github Pages site to document outcomes and decisions
  • Weeknotes should be published at the end of each week summarising activity and link circulated to the team and client(s)

At the end of an engagement we want to be able to provide a single Github repo that represents everything we did with a Github Pages site that provides all the relevant context — the expectation isn’t that the code is reusable in the open source sense but that all our learning is available and we show our workings (through the code!). Also our ambition is that when we do Service Assessments or similar we don’t need a slidedeck — we just step through the repo using the Github Pages site as the guide (as such we have created a GOV.UKesque Pages template — as well as an upcoming Notbinary one.)

Agile

We are agile not Agile™. We do daily updates via Slack rather than traditional stand-ups, we do regular retrospectives (using FunRetro and Slack calls), for Alphas we work with a loosely one week sprint cadence but a Kanban-esque backlog. We are #noestimates during Alpha.

For Beta we take a more rigorous approach but still relatively lightweight by default. Two week sprints are more likely. Some high level estimating is likely to creep in. We will also be much more driven by TDD and as such the ‘stories’ will be much more precisely articulated that during Alpha.

In both cases we maintain public roadmaps as well.

Slack

Each squad has a private channel on the Notbinary Slack.

Slack is the default team communication channel.

This channel includes

  • A user-group so all members can be contacted at once
  • Invited members from the client-side (one channel guests in Slack parlance)
  • ‘The Standup Alice’ chatbot to handle daily updates via Slack

Email

When email communication is required with the client(s) the team email should be BCC’d in to all communications to ensure nothing is lost in team members inboxes if they are unavailable (the archive can be searched via Notbinary’s Google Groups account).

Meetings

We have ’Show and Tells’ per sprint. These are facilitated by the Delivery Lead. They should also act as the primary stakeholder meeting for broader conversations.

Otherwise seek to minimise large group meetings. Where possible one-to-one or small target conversations with subject matter experts are our preference.

Makers

We firmly believe in what David Kelly of IDEO said;

“A prototype is worth a thousand meetings.”

The goal of our squads is software not slideware.

An alpha alpha approach

Mr Downey spurred a bit of conversation on Twitter about the idea of ‘alpha’ stages in the GDS delivery cycle.

One of the responses was from Martin — which I liked up to a point but it also didn’t totally work for me and part of that was the terminology — unfortunately MVP has attracted so much baggage at this point it is like Kim Kardashian on a weekend away.

Personally I think Michael Brunton-Spall did a great job of describing the approach to ‘alpha’ I subscribe to in this post from last year — I especially like this quote →

..we want teams to move fast, to explore the possible solution space and feel confident that they’ve learnt more about what possible solutions there are and which ones should be progressed.

We failed at the final stages bidding for a few alpha projects recently so I have been spending quite a bit of time trying to boil down my thinking about our approach and I’m not sure it is always what the potential client wants to hear. While I totally believe with the idea that alphas are “not the first n weeks of the project” and that the code should be throwaway I have definitely seen a little wincing on the other side of the table when I say that.

My Alpha approach

I like to treat the alpha phase as a funnel. Discovery should have sufficiently explored the problem space and art of the possible to give you some hypotheses to explore and the goal of the alpha is to experiment, explore and iterate via prototypes with the tightest feedback loop you can manage (I tend to talk about one week sprints with continuous user research). At each stage you should be narrowing your focus based on that feedback. You need to be ruthless in pursuit of the alpha goal —you need to ‘kill your darlings’ if that is what the research says. The balance is difficult — you can’t risk narrowing focus too early as you could miss something but also I don’t think we should treat alpha like R&D — it is not experimentation for the sake of it — it has an end goal. To prove (or not) there is a next stage — that there is something that needs building. This is the only time I talk about an MVP (and honestly I’d rather not but for now I have nothing better) which is what I want to end with — I don’t want to finish with just ‘learning’ — I want to finish an alpha with an MVP that provides a stepping stone towards the Beta build (not from a code point of view — burn that down!). I want something that illustrates the next phase to users, to stakeholders, to the team on that build.

Working in the open throughout means none of that learning from the experiments is lost and if you need to revisit things down the road it is still there and provides a trail you can back track through if need be.

You also need to genuinely complete an alpha with the option to walk away — this shouldn’t ever be seen as a failure — unless you cannot adequately demonstrate that you did sufficiently explore the space. If you did that and you don’t end up with something to take forward…congratulations. That is a successful alpha.

The reality is we need to be pragmatic about these things — Beta builds are often a slog — a forced march to Live. You will still be researching, still testing, still iterating but the room to manoeuvre is tighter, the pressure is greater, the spotlight brighter, the investment bigger. The alpha needs to validate things to the extent that everybody is confident in the direction of travel — because once you are in Beta it is harder to change path (harder not impossible.)

Honestly I’m not sure this is how others see it — I’m sure some will see significant flaws in this approach but after a few alphas as Product Lead and an advisor on the edges of a few others this is what works for me…for now. I’m always a work in progress after all — always a few iterations away from ready.

Sloganeering for stickers

Shit I say…and why

I think this was Paul Downey’s laptop

If I was to do a series of stickers (why stickers?) I think this is what they would say (and why)→

01. Minimal viable bureaucracy — I’m not one of those JFDI people. I believe that is the fastest way to get something done that will not stick. If we are in this to make real change then that isn’t good enough. I am someone though who both gets frustrated with bureaucracy while understanding the worth of good governance. The magic is finding the sweet spot — and it is different in different places — but you have to try and find the right balance.

02. This is a team sport / One team at a time — this is my version of ‘the team is the unit of delivery’ which I love the sentiment of but never really liked the actual words! For me it is all about the team(s) and this is where I am happiest. Building teams, leading teams, protecting teams and helping teams. The whole servant/leader thing is all well and good but try doing it without a great team. I also increasingly believe in the idea you can make real change just by getting one team right — right culture, right ways of working, doing the right thing. This can be viral — it infects organisations and breeds other teams.

03. agile not Agile — 10 years after my initial Scrum training my feelings about these ‘ways of working’ become increasingly anti-framework and uncomfortable with what I see as dogma that detracts from the real heart of agile working and the benefits it brings. Use what works. It isn’t AA — you don’t have to follow the steps religiously.

04. Think fast and try things — my version of ‘Move fast and break things’ — something I think does more harm than good. But I do completely believe in that IDEO saying → “If a picture is worth 1000 words, a prototype is worth 1000 meetings” and ideas are 10 a penny so you need to test your hypothesis early and often (with real users of course.)

05. Small teams, loosely joined — I’ve written plenty on this elsewhere but basically it comes down to my distrust of trying to ‘scale’ agile in some kind of controlled, formal way. It is related to the ‘minimal viable bureaucracy’ and ‘one team at a time’ ideas — empower teams and do just enough to ensure there enough pathways between them to keep those collective neurones firing!

06. Hacking hiring — this is something else I have blogged and spoken a lot about. I think improving the way we hire people (and retain people) is probably the most urgent thing facing this whole digital thing. There aren’t enough good people to go around so we have to do (much) better at attracting and keeping them. This isn’t the same old same old and it isn’t bullshit about millennial ‘snowflakes’ — we need to embrace new approaches and do the basics brilliantly.

07. Product is propaganda — so much of what I do is about getting the story right, making sure people understand what teams are actually doing and why. Changing peoples perceptions and bringing them along on the journey. Giles calls it all ‘agile comms’ — I call it product propaganda.

08. Be the shit umbrella — this doesn’t mean hide things from the team or don’t discuss things with the team…it just means keep as much of the petty political distractions away from them as possible and maintain a high signal to noise ratio.

09. Never assume incompetence where bureaucracy is a factor — my version of ‘Hanlon’s razor’. Empathy is vital in the world I work in and until you understand the circumstances that led to a decision keep your opinions to yourself.

10. Work in public service. Work in public — actually I’m just trying this one out as a variation on my usual ‘working open’ spiel — if you are reading this you know my views on that! I’m just playing with an idea of making it much more directly related to the ‘public service internet’ ideas.