Chris Fleming

Tag: agile

  • What does “working in the open” mean?

    In Public Digital we often talk to clients about working in the open. We think it’s a key ingredient of successful digital transformation.

    What is working in the open?

    Working in the open means showing people the work you are doing, as you’re doing it. At a minimum this should be people within your team and people across your organisation. Even better is sharing publicly, with stakeholders outside your organisation who have an interest.

    Working in the open is not just about demonstrating progress, but also talking openly about mistakes, changes, and things you’ve learned. It’s partly to support communications, to help you build a movement for change. But it’s also about good governance. It gives stakeholders a window onto your work that drives up quality, helps unblock, and manages your dependencies. Work in the open by being open about the work.

    Typical examples of working in the open are as follows.

    Hosting ‘show-and-tell’ sessions. A show-and-tell is a regular (every 2 weeks, say) open invite event. The team does a short presentation about recent progress, and allows time for questions at the end. Importantly the team does not simply give a status update but “shows the thing”. Such as prototypes, designs, research, or other lightbulb moments.

    Publishing regular updates on the team’s progress. For instance by writing and publishing weeknotes. Or writing regular posts about more specific things as they learn them. This could be a set of insights from user research sessions. Or the logic behind making a particular choice about a technology.

    • NHS trust digital leaders Amy Freeman and Andy Callow both publish weeknotes.
    • NHS Digital hosts a series of blogs on transformation, technology, and design.
    • The Defra Future Farming programme blog.

    Publishing code and documentation as open source. When a digital team is developing a digital service or piece of software they should code in the open wherever possible. Publishing code in public repositories helps teams focus on the quality of their code and documentation. It allows others to build or copy the work that has been done.

    • GCHQ’s internal Boiling Frogs research paper on software development and organisational change. If GCHQ can work in the open, anyone can.
    • NHS design and prototyping kit code repository.
    • The Government Digital Services’s code repositories.

    Using workplace messaging tools. This is one of the simplest things you can do to help your teams work in the open more. Posting information in a ‘chatroom’ rather than sending an email switches the default visibility of a message from closed (only the people copied get it) to open (everyone in the channel or room gets it). This helps all the team know what’s going on, and allows the team to discuss important topics together. It also allows discussion to happen asynchronously without the need for a meeting.

    Richard Pope has published a brilliant thread on twitter of some of the things teams publish in the name of working in the open & transparency.

    Tweet
    Working in the open: chat rooms

    How does working in the open help

    What is the traditional way of communicating?

    Traditional methods of project communication typically follow these patterns:

    • Broadcast. The communications are one-way.
    • Hierarchical. Only the most senior people are allowed to represent the project.
    • Tightly controlled. Everything has to be cleared by a separate comms team.
    • PR-oriented. The objective is to spin what you’re doing to show it in the best possible light.
    • Big bang. One big press release when the work is ‘finished’.

    These types of communications are often impersonal, inauthentic, and frankly boring.

    Advantages of working in the open

    Working in the open is typically low cost and has a number of advantages

    It supports better project communications because:

    • It builds momentum. Digital transformation is not only about technology. It’s also about changing culture, process and operating models. You won’t be able to do this in a silo. By working in the open, you can develop your narrative and bring people with you. It helps create momentum for change. Sharing what you’re doing little and often increases the chances people will engage, reaching wider audiences.
    • It’s 2-way. It allows your audience to interact and converse with you. It opens up a channel for you to receive feedback.
    • It is timely and relevant. Avoiding long comms clearance processes enables your communications to happen when the work does. This helps build momentum and keeps you on the radar of key stakeholders: decision makers or funders. Decision makers don’t like surprises.
    • It has more authenticity. Working in the open allows you to talk in the voice of the people who best understand the project. Helping people understand why you’ve made the decisions you have builds trust. Like your maths teacher used to say, show your working out.

    It supports better project governance because:

    • It makes the service better. More eyes and earlier eyes on the service, product or project means it will get improved, more quickly and at lower cost/risk.
    • It is a window onto your world. It allows stakeholders a much clearer understanding of what the hell is going on than a Red/Amber/Green status report in 8pt Arial on a slide.
    • It manages dependencies. Legacy organisations tend to try and manage dependencies in large spreadsheets. This may allow one person (the owner of the spreadsheet) to understand dependencies. But this isn’t enough. Working in the open allows everyone to see what’s in flight, and identify and manage dependencies for themselves.
    • It helps you manage and persist knowledge. It enables you to build an open store of understanding and insight over time about how and why things have been done. This makes it easier for others to copy or pick up where you left off. It allows others to link to what you are doing and explain.

    It supports capability building because:

    • It helps you hire. Digital professionals like to be able to work in the open. If your organisation can show that it works this way, you will attract more of the people you need. “I asked members of the audience to raise their hand if they wanted to work at GDS after reading one of its blog posts. 75 per cent of people put their hand up.”
    • It is democratic. Everyone on the team is empowered to showcase their expertise about what they’re doing and why. This builds confidence in communications skills. It helps everyone feel like they are contributing.

    If you want to build trust, confidence, and learning, we suggest you work in the open.

    Further guides

    More advice on agile communications from Giles Turnbull.

    More advice on weeknotes from Giles and Ben.

    More advice on running great show and tells.

    More advice on doing presentations.

    More advice on coding in the open.

    This post was originally published on the Public Digital website.

  • Building digital organisations, creating great teams and enabling transformation

    I’ve spent a good portion of my career working in digital teams in the NHS. You’ll have to trust me when I say it’s the most satisfying work you could do.

    The ingredients are pretty compelling. Done well, it brings you close to the people you are trying to help. You understand their backgrounds, stories, hopes and fears and live it with them. A minute saved, a question answered, a reassurance given; incremental tweaks making a small difference to the world. Over time these can scale up to something rather powerful. Even better if the team is empowered by leadership to solve the problems the business and users have set them. There is no further level to ascend in Maslow’s hierarchy.

    Most inspiring though, is operating in a multidisciplinary environment. The satisfaction of charting a course through what’s safe, what’s possible technically, what the business wants to achieve, and what experience will meet the user need. It requires technologists, designers, researchers, clinicians and operational staff. They each bring expertise from their alien worlds to alight on the thing that will make the service better by next Friday. And the Friday after that.

    As part of the Digital Board’s programme we recently helped NHS Providers produce a guide on Building and enabling digital teams. It may sound obvious when you say it out loud but the secret to digital transformation is not magic. It’s teams. While leadership and a window of opportunity are important, all the words and slides in the world won’t save you without a team in place to deliver. Teams are the start, middle and end of your transformation.

    The board of any organisation plays a huge role in creating great teams. It also sets the conditions to enable them to thrive. In the guide we propose 8 questions for boards to ask about progress building a digital organisation.

    1. Do you talk about digital services or IT projects?
      Projects imply a one-off thing to be ticked off a list. Services imply a need to understand the people who will use them and help them complete a task. Projects end on launch day. Services start on launch day.
    2. Who designs your services and how?
      Digital is not just a rebrand of your IT department. True transformation happens when the edges of traditional and new disciplines meet. You will design the best services and meet the needs of your users when you bring together multidisciplinary teams.
    3. Is specialist digital knowledge represented at the top table when key technology decisions are made? Digital is about rethinking operating models as much as delivering new technology. Making those decisions in the absence of specialist expertise is risky.
    4. Are you applying new hiring strategies to hire new skills? Senior product leaders or interaction designers are not typically going to be looking on NHS Jobs. If you look in the same places, you will get the same people.
    5. Does your team look like who you are trying to reach? The best way to build services that work for everyone is to make sure that your team, at any level, reflects the people who will be using them. Diverse teams are more productive and innovative, and have been shown to improve patient care and outcomes.
    6. Are digital teams coming to you with problems to solve? As a board, are you servant leaders having an open conversation, or are you trying to decipher the hidden problems obscured in the papers?
    7. Does information flow to authority, or does authority flow to information? There is no argument that good governance is critical to good service delivery. But ‘good governance’ is often confused with extra process, hierarchy and paperwork. There is a better way.
    8. When was your last blog post about your digital transformation published? One of the most powerful ways an institution can differentiate itself and attract a new type of skillset or leader is to interact with the outside world in a different way. The best digital organisations show their working out.

    This post was originally published on the NHS Providers website.

  • Agile policy teams

    There’s a brilliant event taking place today. #oneteamgov is having proper crack at bridging the policy/delivery divide.

    Anyone working in digital knows what an agile product team looks like. As a fun thought experiment, I wondered what would a multi-disciplinary agile policy team would look like.

    • You would have to start with the product/policy manager. They conduct the orchestra, understand the user needs, and prioritise the ways of meeting them. In a policy context this also means being to be able to accurately channel ministerial intent; i.e. being the relevant SpAd’s best friend. Ideally this person has some experience of working with digital because so much delivery is rooted now in digital services; and digital provides all the best team tools for effective delivery.
    • Next hire would be a delivery manager. When I moved from policy into product I was particularly struck by the rigorous approach taken to prioritisation, enabled by strong delivery management. I’m also a big fan of separating the roles of owning the vision with owning the delivery. Badging policy work in phases like discovery/alpha/beta will help teams chunk up the work, and could have ancillary benefits help… managing… u-turns? I also don’t see why scrum or kanban couldn’t be used in good effect, if only for task management. OK, it’s hard to rapidly prototype and iterate a law once it is statute, but that shouldn’t exclude the rapid generation, iteration and validation of policy ideas and proposals in discovery and alpha. Some interesting arguments for git-based development of legislation have already been made.
    • The 3rd name on the team sheet is design, and specifically a service designer. As well as being skilled at ideation and interpreting needs from research, designers are excellent at communicating ideas verbally or visually and are the kind of people you want in front of ministers. I also consistently struggle to think of a single area of officialdom that would not be improved by better content design so get them onboard as soon as you need to start putting pen to paper.
    • Research and analysis. In the ideal world this is a data scientist with an excellent grounding in social research and epidemiology. The extraordinary difficulty of finding someone like that means you probably have to pick depending on the policy area. Someone comfortable with the micro and the macro would be the place to start.
    • A stakeholder manager. Policy work is so often about accumulating the views and knowledge of as wide a group of people as possible and synthesising that in order to support decision making. Getting around the various interest groups is a full time job. A good communicator, networker, and seller of ideas will get your policy flying.
    • An economist. Because all roads lead to HMT.

    There are many more who need to be involved in policy development but above are a few ideas for an irreducible core.

    Policy makers will probably read this thinking “Yawn, we do all that already.” But whisper it, I don’t think you/we do. The people I mention above do join together in the civil service, but not usually as part of a specific autonomous unit. They remain for the most part in silos, feeding into lots of different projects at a time. In other words, a bit like IT firms where development is in one department, testing in another, and infrastructure or support in another. A model which seems so old fashioned now.

    Agile was described to me recently as “collaboration, iteration, prioritisation”. I think that autonomous agile policy teams can help achieve those things more easily, and deliver better policy, quicker. I’d love to know if anyone’s tried this or what people think.

    Update 16:07 on 29 June: thanks to Sophie, Olivia and Matt who have pointed out to me that they would have a user researcher on the team. I wholeheartedly agree.

    This story was originally published at Medium.

  • 10 things policy can learn from product

    Six months ago I made a career pivot from policy making to product management. The roles require a similar mix of empathy and politics, so I feel I’ve taken to it reasonably well. Alongside a deep understanding of Internet-enabled technologies, a notable difference is how much and how effectively product management makes use of specific tools and methodologies to solve problems.

    So here are ten techniques I would bring into a policy team if I went back. If any of the terms don’t make sense, Ben Stevens from the Home Office has posted a handy glossary.

    1. Work in sprints. Choose a time period of 1 or 2 weeks to help give structure to the team’s work. Get everyone together at the start of the sprint and agree the things you are going to focus on completing in that time, remembering that new tasks will come in too. This is called sprint planning.
    2. Hold ‘stand-ups’ over the course of the sprint, and ‘retrospectives’, and ‘show and tells’ at the end of it. Don’t be spooked by the language. These are just meetings, so not exactly an alien concept to policy makers. There’s no need for me to repeat better guidance elsewhere on this, except to endorse how useful they are as an ensemble.
    3. Get a wall. Every team needs a wall. I managed a major house renovation last year and even had a wall (this is not a joke). At its simplest this is expressing a task on a Post-It note, fixing it to a nice flat surface that people can gather around, and moving the tasks through columns labelled ‘doing next’, ‘doing now’, and ‘done’. Do this, and then feel the energy and sense of achievement coursing through the team as they deposit card after card in the done column at each stand-up.
    4. Create genuinely multidisciplinary teams. I spent some time shadowing my mentor who works on NHS.UK Alpha a few weeks ago. It’s a full-blown agile team, replete with product manager, delivery manger, content writers, designers, and developers. Having such expertise around a table enabled them to do magical things, like designing the key features of a GP look-up service, in record time. My experience of policy is usually hierarchical group of something akin to project managers. Other experts tend to be in a box somewhere, wheeled out for special occasions. It also now seems amazing to me that design thinking in policy is still seen as the cutting edge while it’s de rigeur in digital.
    5. Make it someone’s explicit responsibility to knit the team. The mantra goes, “the unit of delivery is the team”, and commensurate effort is placed in getting that team working brilliantly together. My experience working in policy teams is that if they are working great, then great. But if they are not, the response is usually a shrug and sporadic suggestions for ‘more social events’. Digital methodology encourages constant communication between the team using stand-ups. It celebrates successes through show+tells, and does a thorough job of learning from failures through retrospectives. The result is a team completely aligned around an objective, with everyone feeling they are part of something important, and fantastic pace of delivery. Tasks fall to the team not individuals. This reduces risk of single point of failure.
    6. Separate responsibility for day-to-day delivery with big picture and vision. In digital there are overlapping and complementary roles called product manager and delivery manager. The former focusses on macro issues: vision, roadmap, stakeholder management. The other focusses on micro issues: unblocking the obstacles the team faces day-to-day, and doing the team coaching I describe above. This structure recognises something important about our minds being poor at doing two things at the same time. It’s very effective.
    7. Try out some new collaborative tools. Digital teams more naturally have their fingers on the pulse of internet-enabled tools to facilitate team communication, prioritisation, or collaboration. I know IT systems can create barriers to this; but in an age where everyone has a smart phone it’s not hard to find workarounds. If you had to pick any, for me it is Slack. There’s a bit of a backlash against Slack at the moment (Slacklash?), but frankly I’m still at the crest of the wave of appreciation that sees how much more efficient than email is at enabling team interaction.
    8. Prioritise properly. Product recognises you can’t do everything, so have a plethora of techniques for deciding what comes next. Do a few things well rather than lots of things mediocrely, and be rigorous in your approach to choosing which those things should be.
    9. Clap more. Digital teams religiously clap their teammate’s or others’ presentations. This is not only courteous, but sends the presenter away with those few extra endorphins that make it all seem worth it.
    10. Be agile. Note the small ‘a’. My simplest interpretation of this is understanding that for almost everything, your first answer could well be wrong. Doing something and then testing it is better than trying to get it perfect first time. As long as it is labelled as such, it is fine to say something is a prototype or early version and will be iterated, improved, or even binned.

    None of these suggestions are especially complicated. But they can be tough to implement in teams unfamiliar with the language and culture. Digital teams should help with this where they can, as forming good habits should not solely be the preserve of digital. They should be for everyone.

    I’d be delighted to give my novice advice to any policy makers, so do get in touch if it would help. Hat tips to Lisa, Matt, and Kylie for product coaching, and Benji for delivery management advice.

  • An agile intranet

    We designed our intranet to be continuously improved, and over recent weeks have been doing just that. Since the intranet’s launch last year we have gathered data and done extensive research to deepen our insights into our users’ behaviour. This is enabling us to flex our product to meet our users’ changing needs – in line with digital best practice.

    In our most recent development sprint, we focussed on the homepage. The intranet homepage is the first thing most people in the department see when they log on in the morning, so it’s not surprising that 99.9% of user journeys begin there. That’s not true of all websites – GOV.UK pages are often reached via a search engine – but our default makes the homepage a prime piece of digital real estate. It deserves excellent design and only the most important content or features.

    From looking at site traffic we could see the content users visited most over the past year. For instance: guidance on performance management, expenses claims, booking video conferencing, and a few specific  forms. Over the last month or so, content about the DH2020 change programme has also been very popular.

    This data informed our qualitative research. We interviewed twenty-one individuals, asking them about their use of the intranet. We also observed them using the homepage to try and perform particular tasks. As well as interviews, we ran card sorting exercises and a co-design workshop where users drew sketches of their ideal homepages, or voted on features they liked from other government intranets. The range of ideas generated ranged from the pragmatic to the extravagant. But the discussion was invaluable in helping our suppliers understand the needs of DH staff. Over two weeks our experts translated those insights into some of the changes you can now see:

    • Bringing in common design patterns by integrating the menu, search and login into the header to help users find them
    • Developing prominent areas for links to popular services and pages; these are customisable by our content team so can change as needs change
    • Introducing a campaign box to highlight the most important ‘need-to-know’ information of the moment
    • Increasing the number of news stories further down the page; as the large number of users felt the stories dropped off the homepage too quickly
    • Retaining a clean design that users responded to well, but binning the bits that users did not need or want anymore

    Communicating via Slack across several UK locations, the team deployed the changes early last Tuesday morning. Thanks to the brilliant work of the developers we encountered almost no bugs, and by the time we got into the office some fantastic feedback had started to come in.

    Launching is the start of a process, not the end. We’re moving straight into more user testing, including those using assistive technologies, to ensure our changes are performing as we want.

    An ‘agile intranet’ is something the department should be proud of. Internal services and tools are rarely built in this way. It has only been possible for us to effect improvements to this product quickly, cheaply, and securely thanks to our predecessors. They left us a site built on open source software, to open standards, with no contract lock-in, and with the precedent set for relentless focus on user needs. Long may that continue.

    Originally posted to Digital Health Blog.