During my recent time at MHCLG I did a series of opinionated sessions on agile/digital ways of working I think of as the [IMHO] series. They were light on speakers notes and long on rants – but the slides were solid enough so I am sharing what I can here.

==========================================

This is a team sport

Before anything you should probably just get familiar with the Government Digital and Data Profession Capability Framework (aka the DDaT framework) ddat-capability-framework.service.gov.uk given that is where everything stems from these days. You need to understand the rules before you can break them after all!

**The world according to Jukesie **

I wrote a bunch of pen portraits just giving an idea of what I think some common roles are on the hook for – including artefacts I tend to expect from them.

=========================================== Product Managers are the voice of the product/vision. They set the direction via OKRs, sprint goals and the roadmap. They make the trade-offs. They wrangle stakeholders and ‘sell’ the vision.

Artefacts: Roadmap, OKRs, Sprint Plan ===========================================

Delivery Managers are the voice of the team. They ensure the team is set up for success. They watch for obstacles, blockers and burnout. They provide the plan. Part facilitator, project manager and therapist.

*Artefacts: Delivery Plan, Team Healthcheck, Backlog *===========================================

User Researchers are the (loudest) voice of the user. They identify appropriate user cohorts and undertake structured research into specific problem statements and provide insights for the team to make better decisions.

Artefacts: Research Plan, Insights reports ===========================================

Interaction Designers take the UR insights, the vision, constraints, wider context and make visual recommendations of how to respond to those factors.

*Artefacts: Wireframes, prototypes, hi-def designs (and stickers) *===========================================

Developers perform the boring magic that conjures working software from all the visions, insights, recommendations and trade offs. They decide how best to do that and how much can be done at any given time.

*Artefacts: Code, tests, stories *===========================================

Content Designers ensure that any information that the team needs to provide to users is presented in the most appropriate, clearest, accessible and user friendly way as possible. Whatever that might be. It is not a synonym for copy-writer.

Artefacts: Style guides, release notes ===========================================

Service Designers look at the big picture – the end to end service. They identify the opportunities to make things as user centred as possible and seek to optimise the entire service (and sometimes organisation).

*Artefacts: Journey maps, Service blueprints *===========================================

Performance Analysts are the quantitive ying to the User Researchers qualitative yang. They measure the metrics that matter and share those with the team (and stakeholders) to support data informed decisions. They identify trends and patterns in the usage data in order to make things better for users.

Artefacts: KPIs, KRs, dashboards (soooo many dashboards) ===========================================

Business Analysts own the ‘as is’. Mapping how things work (or not) now and why. Ensuring the team understands the space they are operating in. They also [often] hold the ‘Given-When-Then’ acceptance criteria activities.

Artefacts: Gherkin specifications, Process maps ===========================================

Communications/Product Adoption folk tell the story of the product. They ensure the work is understood, using the right formats for the appropriate audiences.

*Artefacts: Comms plans, blogposts, intranet articles, common comms collateral *===========================================

**Successful teams have open relationships **

Every role is an island in the GDaD framework and while the Service Manual encourages some 1-2-1 relationships between roles the reality is a high performing team is polyamorous.

**Partnerships: powerful but potentially problematic **

WARNING Sports metaphor incoming

Football is full of partnerships that made teams better.. Iniesta and Xavi Neville and Beckham Terry and Ferdinand Rush and Dalglish…but they were never more important than the team as a whole.

The same is true in digital teams. Duos and trios often emerge and can help teams succeed (I am a big believer in the product/deliver manager team-up) but if you are not careful it can unbalance the team and lead to factions emerging. It is a fine line to tread but as long as everyone remembers that the unit of delivery is the team then things should land okay.

===========================================

**Empathy as a team superpower **

The better you understand other roles the more empathy you have for their particular challenges.

The more empathy you have for your colleagues the more effective your collaborations will be.

Better collaboration amongst the team will lead to better performance, better products and better outcomes for users. ===========================================

If you want to really get under the skin of understanding roles, responsibilities and relationships in your teams I recommend running through Emily Webber’s 4Ds workshop** **– it really helps uncover and articulate what folk expect from each other.