Delivery – Joe Blogs

Getting remote-friendly

Several teams where I work have been experimenting with different ways to support remote-working.

We’ve done this for a number of reasons:

Open plan offices are not always conducive to concentrating and thinking without interruption. We’ve adapted our workspace as best we can, but it can still be cramped and noisy on busy days. This is fine for the teams running noisy workshop-type activities, but it’s not good for those people who need to get their heads down to concentrate on something for a while.

Related to this; we know that context-switching and interruptions can be annoying, and impact our productivity. Some of the remote-working practices we adopted aim to manage those interruptions.

We thought that doing more remote-working would force us to think more about how we communicate about our work, and make it more open to people outside of the team.

We value flexibility. Our people work hard, and helping them to fit in work around their ‘real lives’ is something we want to support. Working remotely reduces the amount of commuting people have to do, for starters.

Many forward-thinking, and successful organisations are doing this too. We’ve been inspired by the likes of GitLab, Automattic, and 18F.

There are other reasons too. Making these changes also fits with our culture of continuous improvement. We’re always trying to make small adjustments to the way we work, and this seemed like a more ambitious experiment to take on.

Remote-first

The biggest change we’ve made in our team is starting to adopt a remote-first approach.

Remote-first means to communicate and collaborate as if all your teammates are working remotely, even when some of them are in the office.

In practice this means that if any team members are working remotely and join a meeting via Google Hangouts, then everyone joins as if they’re working remotely. So if they’re in the office they join Hangouts individually from their desk, rather than piling into a meeting room.

This was strange to start with, as you had people sat across the office from each other, talking over Hangouts. But then it starts making more sense, as it means that everyone in a given session is on a level playing field. It avoids the situation of having a less good experience if you are working remotely.

It also means that instead of turning up at someone’s desk to ask a question, you might send them a message over Slack instead. Unless you really need the answer right that second, you can communicate asynchronously and let them answer when it suits them to break from what they’re doing. This also means that conversations can be made more ‘visible’ to your other teammates.

This has been, and continues to be, very much a gradual journey of discovery for us as a team. We’ve gradually started spending less time in the office. Some people now come into the office a couple of days a week, and work remotely the rest of the time. A few people still come into the office most days. We’re not a truly remote-first team, but I’d say we’re a lot more remote-friendly.

Some things we’ve learned along the way

It’s really important to ditch the thing you sometimes hear along the lines of “x is working from home, I’ll pick it up with her tomorrow when she’s in the office”. Unless something absolutely has to be discussed in-person, you can probably at least start that conversation right now, over another channel. We still have to pull each other up on this.

We’re more conscious about socialising. When we’re not physically together so often, it’s important to refresh those team bonds that are built through face-to-face interaction. Think less ‘forced fun’, and more just scheduling time in for coffee, team lunches, and team drinks.

Be explicit about whether a meeting is remote or really needs everyone physically together. Over time we’re reducing the number of sessions that are mandatorily face-to-face, but there are still some where we find it helps to be together.

Over-communicate status. When you’re in the office people can see you’re around, and you’re working on certain things. When you’re remote it’s helpful to keep people updated as to how you’re getting on.

Finding the right balance between synchronous and asynchronous communication. Not everything has to be a real-time conversation, but knowing when to switch out of Slack and into a video-call is something we’ve been working on.

When new people join the team, we spend a bit more time in the office together, so we can form new bonds and get used to working together.

Working remotely doesn’t have to mean working at home. Co-working spaces, and the obligatory coffee shop, are regularly used by the team.

People like the flexibility that working in this way gives them. It can help in balancing work, and ‘real life’.

It’s not for everyone; some people prefer coming into the office and being physically co-located with their team-mates. We support that, and in future people’s preferences around remote working should be factored into how we set up new teams.

Challenges

Many of the new practices have been most eagerly adopted by the Developers in our team. There’s a good fit for them with being able to work in a quiet environment, get into the flow of their work, and communicate asynchronously as needed. It helps them find a ‘maker’s schedule’.

We still face challenges as to how we run design processes remotely. We have run decent design reviews remotely; in some ways it forces us to slow down a little and listen better as each person speaks. But there are some activities like analysing user research and sketching sessions, where we still generally choose to be physically in the same place.

Some might say that you cannot be ‘agile’ unless your whole team is all in the same place. I’d challenge that now; I think if you have a well-bonded team, with modern tooling for remote work, you can definitely work in an agile way.

I think on reflection that when we’re in ‘delivery mode’; knowing the product we need to build, and having a clear backlog to work from, then remote-first works well for us. More recently when we’ve been in ‘learning mode’; back in discovery, figuring out what we should be making, then we’ve benefited from being in the office together a bit more.

Is it the future?

A future that’s supportive of us remote-working could lead to us being able to hire people from much further afield, form some fully remote teams, and have much less need for permanent office-space. Some of our recent vacancies have been advertised with remote-working as an option.

It’s not for everyone, but if you’re supportive of remote-working in your teams, do consider adopting practices that fall under the banner of remote-first. If you already do this, I’d love to hear about what you do, and how it works for you.

Resources, or People?

Workplace language is interesting. We hear a lot of different jargon and cliches that we wouldn’t ordinarily encounter outside of the office. I think we know some of it is a bit silly and acknowledge it as such, but other workplace language is treated as totally normal.

One of the most common, but perhaps pernicious, examples of workplace language is the use of the word Resources, when we mean People. It really does seem to be workplace-only vernacular too – I’ve yet to hear anyone say “We need some more resources for 5-a-side tonight.”

I understand that it’s a fairly industry-standard term, but that doesn’t mean there aren’t issues with it. Lots has been written on this before – posts like this, and this – and there’s even a day dedicated to the cause.

oxforddictionaries.com defines resources as

A stock or supply of money, materials, staff, and other assets that can be drawn on by a person or organisation in order to function effectively

So technically speaking using the word resources to describe people isn’t wrong, and sometimes it makes sense to use the word resources to describe a particular ‘thing’. Resource management isn’t just about people – it could be about laptops, office space, or beanbags.

But 99% of the times I hear ‘resources’ mentioned at work, it’s being used to refer solely to people.

The problem is that the word resources seems to imply an interchangeable quantity –

“we need more resource”

“add some more resources”

“this resource is leaving, let’s get another one in”

From a management point of view this is great. It would be fantastic to be able to swap interchangeable resources in and out at will, in order to maintain performance.

But of course it doesn’t work like that. People have different skills, personalities, likes, dislikes, attitudes and so on. You cannot simply switch people in and out of a team, and expect things to continue at the same level or pace.

Because in knowledge work, value is generally delivered by teams, not individuals. A team is not just the sum of its parts – it’s the product of its interactions. The relationships between the people in the team determines the success of the team – it’s not about just adding up the raw skills of the individuals in the team.

The word resource obfuscates this fact. It helps us to kid ourselves that we can work in this way – swapping people around. It’s hiding the reality of the situation that when you’re dealing with knowledge work – people are not always going to be completely interchangeable.

That’s not to say I’m not against moving people around between teams on some regular basis. This can keep things fresh, and helps to share knowledge. But I think I’d get better results from trying out a new winger in my regular line-up, than swapping out the entire midfield.

I know a lot of people don’t like being referred to in this way, but I don’t think this is just about individuals being sensitive to being called a ‘resource’ – it’s about our cultural definition of how we view and treat our people, and about how we plan and manage work in a realistic way.

Having shared language is really important for building shared understanding, but next time you’re about to use the the word Resources, maybe pause and think; would the word People explain the situation in a clearer, more helpful, and more realistic way?

Building consensus around product ideas

I’ve spent the last year or so working with teams in the early stages of Product Discovery – examining the needs of users, and forming ideas and prototypes of services we can deliver to meet those needs.

One thing I’ve seen is the tendency in those teams to have the same conversations about a particular topic or idea several times over. Sometimes in the office, sometimes over lunch, and sometimes in the pub after work (which is where a lot of good ideas form).

This isn’t necessarily a bad thing while we’re shaping our ideas and building consensus in small groups. But once we’ve found ourselves repeating, and agreeing, the same concepts a few times, it feels like it’s time to get things out of our heads and onto some paper, so that we can share the idea further, and build a broader consensus.

The worst case scenario is if we don’t do this, that a small group forms an idea and assumes everyone else is also thinking the same thing. In the early stages of delivering a new service for users, building shared understanding across the whole team is critical.

Audio recording

A nice idea we tried recently was to get a small group of us (three worked nicely) to record the conversation. Kudos to @evilstreak for taking inspiration from the work @mattsheret has done with us on blogging.

We found a quiet space and used a USB mic (that we use for remote meetings) and Quicktime to record our conversation for about 30 minutes.

We didn’t write anything down beforehand, but the conversation was fairly structured, as we’d already had similar versions of it before.

One side-effect of the recording was that we were a bit more conscious of what we were saying, and avoided any unnecessary rambling. Being aware of the recording also stopped us from talking over each other at all. This is something we sometimes suffer from, as everyone has so many ideas to share, people just want to get them out there.

After the recording we transcribed it verbatim into a document. By sharing the audio file, two people were able to work in parallel for 30 minutes to get the whole conversation transcribed.

Pro-tip – using VLC to play back the conversation at a slightly slower speed (about 80%) allowed the typist to keep pace with the conversation without having to pause and replay bits. If you’re a really fast typist maybe you won’t need this.

Listening again to the recording actually helped ideas to crystallise in peoples’ minds. You were listening more intently, rather than thinking about what to say next, as you might in conversation.

Getting feedback from the wider team

As it was just three of us that had the initial conversation, we needed to gather feedback from the wider team.

Initially sharing the transcript was a useful way to share the ideas. Teammates reported that reading the transcript was a very natural way to read, and understand the ideas.

We then began to structure it into a more coherent narrative. Using a tool that enables quick electronic collaboration (like Google Docs) is really handy here. Everyone can be in the same version of the document at the same time – teammates can add comments, responses can be seen instantly, and everyone can see updates as they’re being made.

Crits

We supplement this electronic collaboration with group crit sessions.

Anyone interested in providing feedback gathers around a table and we read through some ideas and have a time-boxed discussion with the goal of gathering specific change to make to the narrative.

In this case we quickly realised that we didn’t have consensus across our team. Lot of new ideas came from these sessions, and the original narrative gave us a way of framing this discussion.

A picture speaks quite a few words

Another (fairly obvious) way of clarifying thoughts and ideas was to do quick sketches of your thoughts. Drawing something and showing it around was a really quick way of prompting further conversation to build shared understanding.

It’s handy to draw something and then pass it to a colleague without explaining what it shows, then ask them to explain their understanding of it.

Building consensus in public

So we’ve built some consensus amongst ourselves, within our team. Next we need to build some consensus with the wider world outside of our team – with our stakeholders and with the public.

We need to be open with our ideas as early as possible for a couple of reasons –

All the services we’re delivering are created for, and paid for by, the public. We should be transparent about how we’re spending public money.
The health and care system is complex. There are many different organisations involved. Being open about our ideas and proposals early on is a good way of getting the message out to these organisations, and starting a conversation with them.

One way in which we share our ideas openly is by blogging.

The document and drawing described above were drafted into an initial blog post by @evilstreak and @paul_furley, the drawing was redrawn by @demotive, and the resulting post is here – Booking is critical for transforming healthcare

Lego Flow Game

We run regular Delivery Methodology sessions for a mixture of Delivery Managers and other folk involved in running Delivery Teams. It’s the beginning of a Community of Practice around how we deliver.

One of the items that someone added to our list for discussion recently was about how we forecast effort, in order to predict delivery dates. Straight away I was thinking about how we shouldn’t necessarily be forecasting effort, as this doesn’t account for all of the time when things spend blocked, or just not being worked on.

Instead we should be trying to forecast the flow of work.

We’d been through a lot of this before, but we have bunch of new people in the teams now, and it seemed like a good idea for a refresher. My colleague Chris Cheadle had spotted the Lego Flow Game, and we were both keen to put our Lego advent calendars to good use, so we decided to run this as an introduction to the different ways in which work can be batched and managed, and the effect that might then have on how the work flows.

Lego Advent Calendar

The Lego Flow Game was created by Karl Scotland and Sallyann Freudenberg, and you can read all of the details of how to run it on Karl’s page. It makes sense to look at how the game works before reading about how we got on.

We ran the game as described here, but Chris adapted Karl’s slides very slightly to reflect the roles and stages involved in our delivery stream, and he tweaked the analyst role slightly so they were working from a prioritised ‘programme plan’.

Round 1 – Waterfall

Maybe we’re just really bad at building Lego, but we had to extend the time slightly to deliver anything at all in this first round! Extending the deadline, to meet a fixed scope, anyone?

The reason we only got two items into test and beyond was that the wrong kits were selected during the ‘Analysis’ phase for three items. The time we spent planning and analysing these items was essentially wasted effort, as we didn’t deliver them.

The pressure of dealing with a whole batch of work at that early stage took it’s toll. This is probably a fairly accurate reflection of trying to do a big up-front analysis under lots of pressure, and then paying the price later for not getting everything right.

It was also noticeable that because of the nature of the ‘waterfall rules’, people working on the later stages of delivery were sat idle for the majority of the round – what a waste!

Our Cumulative Flow Diagram (CFD) for the Waterfall Round looked like this –

You can see how we only delivered two items, and these weren’t delivered until 7:00 – no early feedback from the market in this round!

CFDs are a really useful tool for monitoring workflow and showing progress. I tend to use a full CFD to examine the flow of work through a team and for spotting bottlenecks, and a trimmed down CFD without the intermediate stages (essentially a burn-up chart) for demonstrating and forecasting progress with the team and stakeholders.

Round 2 – Time-boxed

We did three three-minute time-boxes during this round. Before we started the first time-box we estimated we’d complete three items. We only completed one – our estimation sucked!

In the second time-box we estimated we’d deliver two items and managed to deliver two, just!

Before the third time-box we discussed some improvements and estimated that we’d deliver three again. We delivered two items – almost three!

Team members were busier in this round, as items were passed through as they were ready to be worked on.

The CFD looks a bit funny as I think we still rejected items that were incorrectly analysed (although Karl’s rules say we could pass rejected work back for improvement)

The first items were delivered after 3:00 and you can the regular delivery intervals at 6:00 and 9:00, typical of a time-boxed approach.

Round 3 – Flow

During the flow round, people retained their specialisms, but each team member was very quick to help out at other stages, in order to keep the work flowing as quickly as possible.

Initially, those working in the earlier stages took a little getting used to the idea of not building up queues, but we soon got the hang of it.

The limiting of WIP to a single item in each stage forced us to swarm onto the tricky items. Everyone was busier – it ‘felt faster’.

We’ve had some success with this in our actual delivery teams – the idea of Developers helping out with testing, in order to keep queue sizes down – but I must admit it’s sometimes tricky to get an entire team into the mindset of working outside their specialisms, ‘for the good of the flow’.

Here’s the CFD –

The total items delivered was 7, which blows away the other rounds.

You can see we were delivering items into production as early as 2:00 into the round. So not only did we deliver more in total, but we got products to market much earlier. This is so useful in real life as we can be getting early feedback, which helps us to build even better products and services.

The fastest cycle time for an individual item was 2:00

A caveat

Delivering faster in the final round could be partly down to learning and practice – I know I was getting more familiar with building some of the Lego kits.

With this in mind, it would be interesting to run the session with a group who haven’t done it before, but doing the rounds in reverse order. Or maybe have multiple groups doing the rounds in different orders.

What else did we learn

* Limiting WIP really does work. The challenge is to take that into a real setting where specialists are delivering real products.

* I’ve used other kanban simulation tools like the coin-flip game and GetKanban. This Lego Flow Game seemed to have enough complexity to make it realistic, but kept it simple enough to be able to focus on what we’re learning from the exercise.

* Identifying Lego pieces inside plastic tubs is harder than you’d think.

Overall a neat and fun exercise, to get the whole team thinking about how work flows, and how their work fits into the bigger picture of delivering a product.

Failure IS an option

I wrote this post after coming off a daily ‘stand-up’ call where one Developer admitted he “didn’t know what he was doing” because he’s covering for one of our UI Developers while she’s off , and a DBA told us we weren’t seeing the data we expected that morning because he ran the wrong package by mistake.

It got me thinking about how it’s important to encourage an atmosphere where people aren’t afraid to talk about the mistakes they’ve made.

No-one admonished these people for saying these things. We respect someone for being open about the fact that they made a mistake, and then fixed it. We admire someone for actively stepping out of their comfort zone to work on something they’re not used to – it broadens their skills and reduces the number of single points of failure in our team – which in turn helps to keep our work flowing.

Whilst failure can be bad – it is also a chance to learn, and improve. It’s okay to make mistakes, and to admit when you don’t know the best way to do something, as long as you learn from it!

photo credit: ncc_badiey cc

10% time hall of fame

I wrote a post last year about introducing 10% time in our workplace, and the twitter feedback idea that I started working on.

A few months ago we had our first entry into the 10% time hall of fame. This is a coveted position reserved only for those ideas that have been developed and iterated to the point where they’ve been released into our main live service.

Read more about Michael Cheung’s 10% time project – Optimise Health A-Z for small viewports.

Hopefully this will be the first of many ideas to start out as 10% time projects, and make it all the way into our live service…

Friends & Family Tweet

For my 10% time project I have decided to look at whether Friends and Family Ratings could be submitted via Twitter.

The idea was that if you’re sat in a GP waiting room you might be tweeting, and if you were shown a particular hashtag(s) then you could use these to tweet a view on the service you’re receiving.

This example could be flawed in several ways, as you’re more likely to want to give an opinion after you’ve actually seen the doctor, not while you’re waiting there…

However I’m going to explore the possibilities and see where it takes us – there may be mileage in integrating with Care Connect so that people can submit real-time ratings, comments or complaints via Twitter. It could be extended beyond Twitter itself to other channels. We could make use of geo-location (thanks Russell) or QR codes (thanks Sean) to enhance the experience.

EDIT – there seems to be appetite for this today
http://www.bbc.co.uk/news/health-24669382

The technical bit

So far I have a basic Gherkin spec which looks like this –

Feature: Grab Tweets By Hashtag
In order to store tweets for processing
Twit can grab tweets with a specified hashtag from twitter

Scenario: Grab a new tweet with a hashtag
Given there is a new tweet with the hashtag #nhsfft
When you wait 15 seconds
And you run Twit
Then this tweet should be stored

In the background this automatically posts a tweet from a personal dev account I set up, and then runs a console app (called Twit, right now) which searches twitter for tweets with this hashtag and then stores the tweets in a RavenDB store for future processing. The 15 second pause is there as the tweet wasn’t showing up in search results immediately – this sucks a bit as it slows down the automated test…

The next step is to write a separate process, which takes these stored tweets and posts them to Choices via our comment capture API.

I’m trying to practice what I preach (!) and use a BDD and TDD approach to the coding, with lots of refactoring as I go to ensure the code-base stays simple and clean.

It’s also good for learning – I found that you don’t have to store the NuGet packages in source control (thanks Steve), and am learning bits and pieces about RavenDB too.

Interacting with Twitter poses some challenges too. I began writing raw requests, but found dealing with OAuth was eating up time (when I just want to get something working) so am now using a couple of .Net components that wrap around the Twitter API. It’s likely that I’ll have to move from using the REST API to the Streaming API too, in order to ensure we don’t miss any tweets.

I’m also learning more about git – it’s only in a local repository at present, but will hopefully be in github soon!

10% time

We just launched a new initiative in our team to encourage more innovation and learning. Our 10% time is a bit of a cross between Google’s 20% time, and Dragons’ Den.

The idea is that any team members in Product Delivery can spend Friday afternoons working on their own project. It can be anything they want, but our panel of Dragons must agree to ‘invest’ a certain number of afternoons in the idea first.

Pitch

To get involved – team members deliver a short pitch explaining

what the idea is
how it will benefit the wider organisation
how long they initially need to work on it

Investment

The Dragons can choose to invest a certain number of afternoons in the idea, or ask for more refinements to the idea. When the end of the invested time comes – we’ll have demos of the different ideas, to see what we’ve come up with.

Ideas

There are some already some interesting ideas being pitched – ranging from a historic twitter analysis and a pregnancy care planner app, to a virtual fridge. Some people have pitched individually, and others have worked in pairs. The methodologies, technologies and tools used to build these ideas are entirely up the individuals building them, so it’s a chance to try out some new stuff.

Delivery, Delivery, Delivery

When I started this job it was towards the end of a big release. I witnessed a long and painful bug-fixing period, and got to thinking about what improvements could be put in place to make the next release smoother. It soon became apparent though, that the releases all year had been late, and as such a backlog of work had built up. What also became apparent was that all of this work was contractually required to be delivered by the end of 2010. My first full release was certainly going to be interesting, if not smooth…

According to the PMs all of the required work would fit into the time we had, but unfortunately the estimates that this assertion was based on had all been provided by individuals who would not actually deliver the work, or by developers who had been forced to ‘estimate’ to a specific figure. In my mind these so-called estimates are pretty worthless, as the whole point of estimating is to be able to plan well (in many environments it’s also to cost things up, but in our case the costs are already fixed by the overall contract), but more on estimation in a future post…

So we ended up in a situation with the resource, time and scope were effectively fixed – not ideal.

We mitigated this to a degree by ensuring we worked on the right things first. Although the overall scope was fixed, there are usually ‘nice-to-have’ features that the business can truly live without. The business owners weren’t used to having to prioritise in this way – we had to gain their trust, and explain that we weren’t planning to drop their features, rather we needed to avoid a situation where if the sh*t really did hit the fan, we wouldn’t be left with critical features not implemented, based on their advice. This seemed to work okay, and we had more confidence that we were working on the right things in the right order. We also tightened the testing feedback loop by getting the testers to test everything in an earlier environment. This reduced the total cycle time to deliver bug-fixed requirements.

Even after those minor improvements, it was a tough release. The team worked a lot of overtime, something I hope to avoid in future. We worked late nights and we worked from home some weekends. When we worked in the office at the weekend we had to get portable heaters in as it was so cold that our fingers were seizing up, and when it really started snowing we booked people into hotels so they could carry on working instead of leaving early.

And we delivered. We got the release out on time, and we partied when it was all over. Would I want to do another release like that again – no way… However there was something positive about the team pulling together to beat the odds. It was a time when we worked hard and played hard together, and it’s still one of the releases that some of those involved talk about with a wry smile.

Introducing Iterations

New year, new start… We’ve just got a big release under our belts and it feels like there is now enough trust from senior management to start making a few changes to the way we do things.

So what first..?

One problem seems to be the feedback loop from the business. They come up with an idea, it spends a few weeks/months being spec’d up, and then we develop it. Finally it gets tested and eventually the business owner gets to see the ‘finished’ product…

This sounds okay in practice, but it doesn’t work because things change along the way.

We need to tighten the feedback loop so the business are involved and engaged throughout the whole of the design, develop, and testing process.

Another problem is that time is wasted in spec’ing up features that never get delivered because we then run out of time in the development phase.

Ultimately we need to move away from the long phase-based waterfall approach that makes the flawed assumption that we can get everything right and complete in one phase before moving onto the next.

Pull?

I think the ideal solution to this will be to introduce a pull-based continuous-flow pipeline type of approach. We’d take one minimal marketable feature at a time and deliver it all the way through the pipeline from start to finish.

Although this type of Kanban approach says ‘start with what you do now’ – I see us having the problem that this is going to require a lot of regular communication and engagement between different teams, who work in different geographical locations. The organisation isn’t currently used to this level and style of communication.

Iterate

After some thought, I reckon it’s probably going to be better to try an iterative approach first.

We’ll try working in two week iterations; taking a small chunk of work at a time – maybe a couple of features – developing and testing them, and then finally demo’ing them to the business owners to get approval that we’ve done the right thing, and/or feedback that we need to change things.

By getting this early and regular feedback we should avoid the nasty surprise of finding we’ve delivered something incorrectly right at the end of a release when we don’t have the time to do anything about it. Ideally if something is going to fail, we want it to fail as early as possible! We can tackle high priority and high risk items in the earlier iterations, to drive out risk, and ensure we’re delivering the core requirements early on.

My reasoning of choosing iterations over continuous flow, is that because of our split site, it will be good to have specific markers in time where the different teams can come together to look at where we are, review progress and then plan the next steps to take.

I actually hope that over time the iterations might naturally disappear and we’ll end up with the continuous flow system that will work even better in the long run. Until then I think that introducing the discipline required to make an iterative approach work, will be a good thing…