We wrote the first draft in a 30-minute session.
After working together for almost a year, our 4 delivery heads, plus the Chief Product Officer, spent many hours discussing all kinds of delivery dos and don’ts. We had done the thinking for months and only had to do concise writing. It still took us another month to finish the delivery principles.
Sharing our delivery principles
On Thursday morning, in our combined All-hands and Show the Thing session, we gave some context and then read the 12 delivery principles out:
- Each project has a dedicated team.
- Each team understands the motivations of the project partners.
- Each team has a clear task and problem definition.
- Each team defines success metrics in advance that contribute to the company and project goals.
- Each team works together in an agile way and has clear roles, rules and rituals.
- Each team works in increments and tests its work-in-progress with low effort and high frequency.
- Each team organises its work in a transparent and accessible way.
- Each team works together with project partners in a structured way and communicates progress regularly.
- Each team understands the users, their contexts and infrastructure before developing new solutions.
- Each team reuses existing patterns and components.
- Each team takes responsibility for quality, risks, security and accessibility.
- Each team releases continuously and is responsible for operations until handover.
None of these 12 principles should be surprising. Most are obvious. The first principle we have to address in the leadership team: teams need to be sufficiently staffed to work effectively. Then, the teams can take care of the other 11 in the way they deem adequate in their setting.
Since I joined 2 years ago, the organisation doubled in size. New colleagues have joined us from all kinds of organisations and with all sorts of backgrounds. Some have worked in tech start-ups, NGOs and non-profits, and others in corporations or small consultancies. Everyone has experienced different ways of building digital things. Our context is equally distinct and unique. That is why we mention ‘project partners’ twice in the delivery principles. In our setup as a government in-house unit, we work closely with different ministries and their digital project units. Hence, principles 2 and 8 highlight how vital the work with ministerial project partners is. We must understand our partners’ motivations beyond the overall goals, tasks and problem definitions. We must ensure our collaboration and communication are structured and frequent, especially as we’re often not co-located.
The other points are mostly linked to the points of the Service Standard. We will roll out the principles in the coming days and weeks. We asked teams to read them, discuss them with their team members, and provide feedback.
From June onwards, we will use them in the Introduction to Delivery Disciplines, which is 1 of our 12 onboarding modules for new starters. The principles should offer an excellent summary and starting point of discussion for new colleagues.
Figuring out how we collaborate effectively across organisational boundaries
In the middle of the week, I joined a meeting with our colleagues from the Federal Press. Apart from printing money, producing official documents, and issuing ID cards and passports, they also build digital products, services, and infrastructure. In week 4, I reached out to a former fellow student working there as a UX designer. But we had very little to no contact since then. I still would like to see this changed.
Both of our units are in-house companies of the Federal government. While the Federal Press is about 25 times bigger than Digital Service, we overlap in some areas and have complementary capabilities. We had an open and admiring conversation this week that ran well over the scheduled time. We closed with a commitment to continue the exchange and look for further ways to collaborate actively.
One area could be the work on a cross-government design system. The Federal Press colleagues joined our community of practice gathering on design systems and component libraries last September. Since then, we have met with other public sector units on the topic since the beginning of the year 3 times. This Friday was already the 4th occasion. The Federal Press is still missing in these exchanges. However, their involvement would be essential and fruitful given their remit and project scope – from the federal services portal to a visa portal and digital identity systems.
This Friday, colleagues from AKDB, Dataport and Digital Service continued reviewing navigational patterns and discussing brand styles of the KERN design system. We packed a 3-hour slot and will reconvene soon. From our side, we want to free up more design time to accelerate our involvement.
In addition, I am looking into running a global design pattern review session in 1.5 weeks. With my former colleague Laurence and many other international colleagues in town, we could examine the GovStack design patterns closely. In my view, they fill gaps that we currently have in all our national design systems. So, I started outlining a little workshop for Friday, 14 June, with whoever is interested and able to join.
What’s next
On Monday, I will welcome another new designer, Vivien. She will join one of our new legal information system streams to work on expert users’ interfaces for federal court clerks documenting case law. Currently, this is our only project for expert users. Charlotte talked about the work in her TEDx talk, and Sophia and Jana blogged about the co-creation with court staff.
On Tuesday morning, I will give a morning talk about user-centred design in the public sector. It’s for a semi-regular speaker series run by the innovation office of the Federal Ministry for Family Affairs, Senior Citizens, Women, and Youth. I was told that no more than 20 to 30 people might show up, but the right people in the room might make a difference at some level.
Ein Kommentar
Kommentare sind geschlossen.