On our new website and second-order agile.
Last week we switched to our new council website1. You might notice the bold new layout on the homepage but the most important changes may not be so easy to spot.
The design is based on good practice developed by the UK Government2 supplemented by feedback from representative users. The priority is to help people do what they need to do in their own context. This means the content needs to work well with the devices people actually use (mostly small touch screens on mobile phones) and for all sorts of people (such as people using screen readers).
Our old website was hosted on public cloud services but didn’t take full advantage of the flexibility available. Our new website makes use of more advanced features to employ more computing power during busy periods (such as the local elections next month) and release it when things are quiet.
It has taken a lot of work and a few sleepless nights to get this far and teams from across the Council can be proud of their part in this. We now have a much better platform but the new website isn’t finished yet. Our services and user needs keep changing so we will never finish adapting the site to keep up.
Around the world, many people have been using agile techniques to get their work done and are generally very generous in sharing what is working, or not, for their teams. This is the raw material for more formalised frameworks like Scrum3 which are still evolving based upon this collective experience. In simple cases, where there is a clear team and a clear product, it is easy to find good advice about how to do all sorts of work in an agile way and keep improving over time.
Sometimes the team and the product are not so clear or need to change. I think of this sort of problem as second-order agile and there isn’t such a rich body of knowledge here. For public services, the UK Government Service Manual covers some of these second-order topics but even this makes some assumptions about the context that don’t always apply.
At the Council we are getting quite comfortable with first-order agile and consistently getting good results. When we struggle there is a good chance it is down to a second-order problem. Here are some examples:
- The work involves coordinating the efforts of a group of people that is too large to run as a single team. There are lots of ways of dividing the group into smaller teams but none of the options are ideal. When we spot these situations we can make deliberate choices or run experiments to find the best structure. Sometimes the situation emerges gradually and the structure that made sense at one point now doesn’t fit.
- The scope of a product and the outcomes of a change we want to make don’t match. For example, imagine we want to make changes to staff expenses. We already have an expenses system which is a component of one of our IT products. The expense system may need to change but so will our expense policies. We will also need to engage staff in the change and train our support teams in how the new rules work and how to handle exceptions. A lot of this is out of the scope of the IT product. If we based our products around business services, like managing expenses, much more of this work would be in the scope but we would need a very different product team.
Over the last couple of weeks I’ve been wrestling with a few of these second-order issues related to our finance and workforce systems. We have an integrated set of services, systems and teams which are too big to manage as a single unit. We’ve made some decisions about the overall principles we will use to structure this area but many of the details aren’t obvious. It isn’t even clear if one approach will work across the whole area. Some of the answers will come from further work to design our future operating model but some will need to come from experiments and trials so that we can learn what works in practice.