Weeknote 18 - 22 May 2020

On agile roles, documentation, shared infrastructure and mental health.

I am looking forward to the long weekend as I feel like I’ve had a hard week. The pattern of our work is shifting. Crisis response has not gone away but is a shinking share of daily work. We are starting to pick up changes that Covid-19 postponed and are talking about when we can get back to our agile transformation (we’ve done a lot of implicit change as part of the our crisis response¹). Although the demands of the crisis were intense the choices we had to make were clear. Part of the reason this week has been hard is our choices are less clear cut and need more negotiation.

Here are some of the topics which have come up this week.

Making sense of agile roles in a Council

Most agile techniques seek to place decisions with the people best able to make them. This means lots of the key decisions are in the hands of people who tend to be more specialised and lower rank than many organisations are used to. It also means communication lines get flipped. Senior managers need to focus less on sucking in information so they can decide and more on sharing their goals (or radiating intent²) so that their teams can decide. This can be uncomfortable for all concerned. Teams have power and authority that they are not used to handling and senior managers are still held to account but seem to have much less control.

Often, the crunch point during an agile transformation is the product owner³ or product manager⁴. These key people have a role which is relatively easy to define but really challenging to perform - especially when other teams are still working in a traditional way. These product leaders are often caught in the middle of these competing pressures. They need to earn the trust and confidence of everyone.

The product lead provides a key channel of information to the team. They curate what the organisation needs and filter out the noise so the team can get on with the most important work. They also have to navigate the internal politics and stakeholder relationships so that they are included in key discussions and are given the authority needed to properly perform their role. Generally, authority due to position and rank won’t be enough for a product leader and they will need to use their personal credibility and relationships to get things done.

But we don’t value documentation, do we?

One of the things that people and teams new to agile get wrong is to abandon all the good things that they know work well. The agile manifesto⁵ is referenced in most agile techniques and states:

We have come to value working [products]⁶ over comprehensive documentation.

The part that many ignore is:

…there is value in the items on the right…

So the agile manifesto, the sacred source of many of our agile techniques, states that we should value comprehensive documentation. That doesn’t mean we just carry on as before. There is a lot of documentation that is wasted effort so we shouldn’t create that stuff. We should create and use the things we need and these can be large in volume and high in detail. Typical things I have seen teams bring back in a different form as they get more used to agile ways of working include:

• quality checklists
• role descriptions
• meeting preparation including setting an agenda
• cost and time forecasts
• commitments and promises.

I’ve had quite a few conversations this week were teams had the impression that writing these sorts of thing down was somehow anti-agile. I am encouraging them to adapt rather than abandon what works for them. Agile teams should have high standards and experienced teams tend to produce lots of documentation. They will have good information about needs, quality criteria and evidence of progress but you probably won’t find it in a traditional document designed to be printed and signed with an ink pen. Instead, lots of this will be recorded in an system which the teams uses as a routine part of their daily work.

If you are starting out on your own agile transformation you will also need to challenge your current ways of working to make them leaner but don’t throw out the valuable things your teams already do well.

Paying for shared infrastructure

I have hosted several meetings about migrating to public cloud infrastructure this week after escalating some risks about this last week. We have covered commercial and financial topics and also engineering and architecture. Public cloud services are already a big part of our IT estate but we are at the early stages of migrating some of our specialist systems⁷. We are a big organisation looking after some highly sensitive data so we have to take a lot of care over security and put in appropriate controls and safeguards.

The public cloud platform we are building will scale well and save us money but some of our processes and procedures are built upon a different set of assumptions⁸. This can get in the way of migration. For example, we need to train our teams in different technologies and set up high-grade networks and security controls. This means incurring costs up front and collecting the benefits gradually as we move our systems. The business case makes great sense overall but our processes assume each system has a self-contained case. It looks like we have a way to get around this now but I am sure we will need to learn more lessons and create new work arounds as we go.

A word about a good cause

It was mental health awareness week and I read quite a few personal stories about mental health from people I follow on social media. It is brave for people to open themselves up this way. There is still a lot of stigma about mental health and many more will be suffering in silence. These posts leave me with twinges of horror and awe. The horror comes from imagining what life would be like to live in a constant battle with depression or a similar illness - what I imagine probably doesn’t even come close. The awe is at what these people have achieved in spite of their mental health troubles.

I’ve got used to thinking that I am mentally healthy and so mental health measures aren’t relevant to me personally. Statistics tell us⁹ that is naive. Even if you are in a good state of mental health it is wise to look after it and support the people around us. Note to self: Get away from the computer screen, get on the phone, do more exercise, watch what you are eating and drinking.

Footnotes:

1. Some more about our under cover transformation in an earlier week note. ↩

2. I picked up this phrase from this excellent blog post. ↩

3. Most people use this definition in the Scrum Guide. ↩

4. This is a closely related role common in the UK public sector. There is a good introduction from the Government Digital Service. ↩

5. The original agile manifesto. ↩

6. The original manifesto refers to software but, like many organisations, we are using very similar techniques for our other products. Some of these are tangible goods like mobile devices but most are business and professional services. ↩

7. Most of our cloud systems are in the category of Software-as-a-Service such as email, collaboration tools, finance and people management. The next wave of systems will use more Infrastructure-as-a-Service. I’ve written before about how hard it is to get this sort of thing right. ↩

8. We have been used to financing capital assets such as servers and will increasing shift to effectively renting capacity on demand from public cloud providers. ↩

9. Here are some statistics from mind. ↩