How we can build for our colleagues

It’s sometimes necessary for an organisation to develop software to support its internal operations. Doing this well is less straightforward than one might think. In this post, I examine some of the challenges faced by product teams building internal tools, and share some lessons learned from working on consumer products that are applicable in overcoming them.

 

The value that comes from using a tool is in how it improves a process. When an actor from a user story hacks around the current process to get their job done, it’s a good indicator that a new tool might be needed. Another step may be required in the workflow, for instance, if users frequently open another browser window to perform a particular task. There are also situations when a new feature is required for reasons other than improving the user experience. We may wish to gather data to train a machine learning algorithm which will ultimately allow us to automate a manual process.

 

Another reason to build our own tools is to avoid vendor lock-in – the situation where we become unable to switch our process from one product or service to another without substantial costs. However, it’s important to remember, that the decision to adopt any technology, be it proprietary or open source, is a long term commitment. While there are compelling reasons to choose an open source solution, we may incur large costs in adapting it to fit our process or in simply learning how to use it well if the base technology and expertise doesn’t already exist in our stack.

 

How do we avoid reinventing an existing tool which already fits our purpose? Cast a wide net to find out whether or not a cost-effective solution is already available on the market. Don’t hesitate to open this investigation to the operations and engineering teams. Their involvement is important; although they may have a good understanding of the problem domain, they often lack the marketplace visibility and exposure to product demos or sales-driven trials that product managers or the business team have. How have stakeholders solved similar problems at previous organisations? Getting input from every player at this stage can eliminate a lot of uncertainty around the necessity of the work involved.

 

When there’s a genuine need for a bespoke solution because the marketplace doesn’t offer an essential feature, expectations may still be high because users will be familiar with similar well established, high quality software. We can manage these expectations by including metrics and benchmarking on the product roadmap and by building them into the product as early as the size of the user base justifies the effort. This also gives us the confidence to abandon our developing solution for something better if it isn’t performing as we’d hoped. Involving users in the development cycle early can also help – users are more forgiving of work in progress when they are part of its inception and growth.

 

We can develop the best understanding of our customers’ pains by beginning the development cycle with an exploratory research phase. This allows us to get to the root of the problem and discourages us from rushing to a suboptimal solution. IDEO’s human centered design framework provides some useful techniques for doing this, such as by having customers map their journey through the process or by observing the journey directly, taking note of any unnecessary cognitive overhead and the behaviours of our “power users”.

 

The research phase may also take the form of a design sprint, where inexpensive prototype solutions are validated by observing how customers interact with them. Be sure to meet with every possible user at this stage. Not only will users at different levels in the workstream be concerned with different tasks; they may also have different working styles which the UX will need to accommodate. This can seem like a large upfront time investment, but it’s far less costly than waiting until after UAT to learn that the chosen solution doesn’t meet the customers’ needs.

 

What do we do when we don’t have the luxury of conducting a lengthy exploratory research phase? When pivoting, a startup or a product team needs to adapt its operations at short notice, sometimes resulting in the prioritisation of a completely new set of features. As an internal product team, our colleagues are our customers; we should therefore be well positioned to meet with them early and often. When we don’t, we develop false assumptions about where the process bottlenecks are. When gathering requirements, don’t be afraid of asking “why” too often. On first asking, our customers might tell us what they think we want to hear, suggesting “quick wins” or solutions they believe are easy to pull off, rather than revealing their greatest pains. Persistence in our questioning will pay dividends.

 

Feature requests are, in theory, better supported by an internal development team than an outsourced one, and straightforward for us to act on because we can easily seek clarification. In practice, we need to consider the long term costs of maintaining these features. Even simple estimation exercises like Josh Pigford’s build vs. buy calculator can be of help. More often than we’d like, resource constraints may mean that we’re not able to balance the local needs of our internal customer with the overall needs of the business. When that’s the case, it’s important for the health of the relationship to communicate why the work can’t be done at this time. Shared understanding and goals reduces the tension between the team and encourages us to review and update these priorities continuously.

 

If our tool doesn’t require expertise to operate, then we’re able to easily dog food our product across the organisation. This lets us find and form relationships with product-minded users who can identify problems which we may have become blind to when designing and building. Take advantage of this, remembering that the managers of most consumer products don’t have this luxury! Developing these relationships by holding “open office hours” increases the quality and quantity of feedback we receive.

 

Once the tool has been built, how do we ensure that product development continues smoothly? Having the development team focus early on the infrastructure necessary to support continuous delivery allows us to launch and begin gathering feedback as early as possible and keep a tight, iterative development cycle. when done well, we can reap the same benefits from practicing agile with our internal tool development as with our consumer products. MVPs are a great way to accelerate learning, but we shouldn’t be duped into thinking that it’s acceptable to produce sub-standard features, believing that they can be “improved incrementally” because we have only our colleagues’ expectations to manage. The launched product should consist of the minimum set of features required to deliver value, but each of those features needs to meet some previously agreed standards.

 

When planning, it’s important to be mindful of how our users will onboard. We’re familiar with the notion that “good design needs no instructions”, but even refined technical operational processes require some training. To save time and effort, training for our tools could take the form of a webinar which can be made available online for later access. Announcing the initial launch internally and continuing to meet frequently with customers can both help drive adoption, and announcing subsequent feature releases can help users imprint on workflows. Make all of the feedback received easily accessible to engineers, for example, through a dedicated Slack channel or integration. Above all, celebrate as a team when users are delighted.

 

In summary, it’s easy for us to become complacent or misguided when we’re designing for our colleagues. We know their organisation, its mission and its roadmap. We know their titles, respective roles and working environment. We may therefore assume that we know what’s best for them, and worse, we won’t make the time to validate those assumptions. Instead, if we do our internal customers the same courtesies as we would our flagship product users, but acknowledge when to treat them differently, we stand a much better chance of delivering the best possible outcome.

Metail provides a yearly training budget for all employees consisting of both time and money, but we found that many employees were not making the most of this opportunity. We decided to look into why this is and work on increasing the uptake. One idea we had was around hackathons – pairing people together to do small hackathons together sounds more fun than just reading a book by yourself!

One-to-ones help uncover trends

From my one-to-ones I found that the main reason people were not using the training days was because they weren’t sure what to do with them. If people were going to a conference or working toward a qualification or certification it was easy to identify the time spent on that as ‘training’. But what if you are already qualified? or there isn’t a conference on this quarter? or you want to spend some time testing out new technology?

Crew Hackathons

I came up with the idea of running some small hackathons within the crew and suggested we could use training days for these. The idea is that people will pair for a couple of days to create something new. This aligns with our company values: being in this together, actively learning, trust to deliver, and making a difference. But I also wanted to push the joy/excitement axis up a bit as well (see previous post).

Because people never want an extra meeting, we decided to schedule this as a special retrospective session. We kept the happiness axis exercise and collected a few actions based on that, but we spent most of the hour running a hackathon proposal exercise outlined below:

  • Everyone tries to write down a couple of ideas for 2-day projects they would like to work on, and spends a couple of minutes to get others excited about it.

  • Vote proposals. Everyone has 2 votes to pick a project (other than their own). Only projects with 2 or more votes survive.

The projects do not need to be directly related to work, but we should learn something from them. The idea is to spend one day together working out designs, and another day creating a prototype or something usable.

I explained the exercise a week in advance, so people had time to think of projects before the meeting.

Deciding on projects

The exercise went well and everyone seemed quite excited. It turns out that a few people had similar ideas, so we grouped some projects together. We then drew a matrix so everyone could cast their votes. This is how the whiteboard looked:

Hackathon Matrix

The top row of the matrix has the people initials, with the number of available training days written below.

We (a team of seven) decided to work on 3 projects. The projects with more votes will have a couple of hackathons associated with them – this is particularly useful if we can’t get together all at the same time. We can also start thinking at this stage if we are going to need any materials, e.g. books, that we need to buy before we get started.

Scheduling the hackathons

We have the ideas, the people, and most importantly, the excitement, so now it’s just a matter of scheduling these hackathons. If a person is working for the full 10 days in a sprint, they instantly become candidates for any of the hackathons they showed interest in. If we can find someone else interested in the same project who has enough training days available, we pair them together and schedule it in the sprint.

Some of these projects have more than two people interested – in this case we have a 1-hour meeting with everyone interested in it, to come up with a plan and decide how we’ll split the work. For instance, if it was a project that involved four developers and two different platforms, one group could work on one platform one sprint, and the other group could do the other platform the following sprint.

Conclusion

Small hackathon exercises can be helpful for people that don’t know what to do with their training days. Other people can bring ideas that suddenly open the curiosity box, and we can turn the learning exercise into a shared experience. Just as it is, it’s a valuable experience. But some of the projects can even turn into something bigger that brings additional value to the company. I think it’s probably worth running this exercise every quarter, to disconnect from your main duties and refresh a bit. If you can’t find the time to run this, just pack it inside one of your retrospectives. You can always use the happiness axis for a swifter retrospective, and move straight away into finding topics for the hackathons.

lap top, headphones: remote work important tools

fully remote working: my work station for a whole week

In the first week of December I ran an experiment: our entire team was made to work remotely from the two main offices. The aim of the venture was for everyone to feel exactly what our remote employees feel every day. As a result, we hoped to improve team communication, both within the team and external to it.

Our team is probably one of the most distributed engineering teams in Metail. While most of our engineers are in the Cambridge office, a few work remotely. We’re lucky enough they are in the same time zone as the headquarters. Nonetheless we still suffer a lot of the pains that distributed teams feel, especially when the rest of the company is more used to working between the two offices, based in Cambridge and London.

Our hypothesis was that we would probably miss out on a lot of incidental “water cooler” conversations. We also guessed that communication with the rest of the organisation would be somewhat difficult.

Before Kick off

Before we rolled out the experiment, I had to lay some groundwork. Firstly I checked with our crew director (we work in teams called ‘Crews’ at Metail) and the other engineering managers that this wouldn’t impact anything crucial. We communicated widely across multiple channels that our team would be entirely remote during the week before the start date. I also spoke to the team to hear their concerns. It certainly helped to draw up a few guidelines. This is in summary what we came up with:

  • We use Slack by default and Skype as a backup
    • We say when we are at our keyboards and when we’re not
    • Everyone is to use headset and have their webcams turned on.
  • In general we try to ensure that we are over communicating
  • If there is a problem or someone can’t be reached, people are to come to me (the engineering manager) or our crew director.

There were a few practical things to take care of as well. We made sure our contact details were added to all the meeting rooms’ Skype accounts. We also checked we could all access internal resources via the VPN. Just to be sure, we ran a couple of trial calls to make sure Slack and Skype would work for us (they did!).

So how did it go?

We were able to anticipate the problems we hit; there wasn’t too much of the unexpected. It was much harder to run work past people on a casual, in person basis. Attempting to do so required both parties to mic up and jump on a Slack call.

Meetings with the wider company is where we struggled the most. We noticed people in Metail occasionally talk over one another and because of this it was hard to participate in guilds and other group meetings. Usually it meant one person in the office would drown out another who was further away from the room mic. We also noticed that if there were multiple people in the office participating in a meeting, remote workers often ended up ignored. In some cases it was difficult to observe body language that would normally be cues for a person to start talking. From time to time it was hard to hear people in the office. Sometimes this was because of problems with the audio equipment, other times it was because of background office noise.

We encountered a few minor technical issues as well. Some of these things were easy to fix, like tweaking rules on a firewall. Others were harder to diagnose, like why a developer was seeing Jenkins time out during load, preventing him from being able to see when builds were finishing. A couple of times we had issues with Slack where one person in the group couldn’t see another but these were easily fixed by leaving the call and re-entering it.

Generally speaking the engineers found it easier to focus on the work they were attempting to do. On the other hand it was pretty difficult for myself and our crew director, being the main communications interface between the team and the rest of the company.

I also discovered that my house gets really cold during the day if I don’t put my heating on! I made a special effort to be a little more social, going out to dinner and to the pub for much needed social interaction.

Conclusions

On the Monday following the experiment we ran a retrospective where we recorded our experiences. On the whole, the world didn’t end and the company kept working. We recognise that it was a pretty short experiment, lasting only a week, but we still found it valuable. One thing we noticed was that we certainly affected how the rest of the company interacted with us by communicating that it was coming up. I can now say I have a much better understanding of the pain our remote colleagues go through every day. I’m definetely going to be reminding people in the office about it in the future.

Learnings

If you engage with remote employees or are planning to in the future, here is what I’d recommend:

  • When you are having a meeting with remote people and it’s possible for everyone attending to have mics, then do so.
  • Let remote employees know if you are starting a meeting late.
  • Respect meeting etiquette and allow all attendees to fully express themselves. Don’t interrupt until they’re done speaking.

Scrum retrospectives are a great opportunity to sit down with your team and make everyone’s voice heard. It’s about collective process improvement, by getting everyone involved and owning part of that process, it’s also about feelings, and about empathizing with each other.

A typical scrum retrospective

If you have a formula that works for your team, it’s good to repeat it: your team members will know what to do without having to repeat the agenda every week. However, it can be beneficial to try different things from time to time.

The most important source of ideas is probably the one-to-one meetings. Some team members may actually find the retrospectives boring or not particularly useful, and they may have ideas to improve them. Try some of them, discard things that do not work, and keep the things that people get more involved with.

We started our retrospectives with classical good / bad clustering: we draw two axis, time on the horizontal, and goodness to badness in the vertical, and people write down 2 positive things and 2 negative things, with a number from +5 to -5, and stick the post-its on the whiteboard. Every week, a different person tries to cluster the post-it notes into different categories. Sometimes, the time scale is a good indicator of a cluster, but we usually re-cluster them into more meaningful categories. Then, that person tries to explain what went well and what went badly during the sprint, asking the relevant people to explain their tickets. The important thing is trying to identify actions based on those notes, pretty much working out the start-stop-continue from that set. However, we don’t do this exhaustively. We focus on the immediately actionable items, the biggest wins and fails.

Some suggested we were wasting too much time on this, and we tried creating a thread on Slack for every sprint where people could write down thoughts as events happened during the sprint, and others would react with emoji. The thread died out after a few sprints, and we realized it was better to think retrospectively during the allocated time slot and get physically involved, i.e., standing up and writing things down.

Happiness axis

Our company wanted to measure happiness somehow. We discussed the option of having some anonymous surveys sent regularly to measure it, but many in the team were put off by having to fill in surveys online. So I decided to do something during the retrospective time, and get people directly involved.

I’ve selected 6 feelings or axes, 3 positive ones juxtaposed with 3 negative ones. Humans are complicated and full of emotions, so I tried to pick up things that I consider actionable in the work environment. This is our list:

Positive Negative
Enjoyment – did I work on something I enjoy? Boredom – most of the stuff was tedious and/or boring
Sense of accomplishment – I got that thing done! Despair – I’m getting nowhere
Powered up – learned something useful! Powered down – I feel I’m losing my skills

I think it’s important to keep it small, though. You don’t want to model the whole brain!

During the retrospective, we draw these axes on the whiteboard. Then, everyone stands up and casts up to 3 votes on any of the axes,

  • You don’t need to use all the votes (abstentions are counted as well)

  • You can vote in opposite axes (half of the sprint was really fun, but the other half was boring)

  • Preferably, add equally-spaced ticks, so we can draw a spider graph in the end.

And this is how it looks in the end,

Scrum Retrospectives Happiness

Happiness Axis

Actions based on happiness axis

Here are some of the recipes we have for actions based on the result of the happiness axis exercise,

  • … if joy is low:

    • everyone should have at least one ticket they would enjoy working on in next sprint;

  • … if boredom is high:

    • promote team work (e.g. pair-programming), from the premise that the conversation will make tedious tasks less painful;

  • … if not powering up:

    • plan for new things in next sprint;

    • schedule training time;

  • … when powering down:

    • discuss during the retrospective and/or one-on-ones which abilities are not being put to use. Try to find a place for them;

    • reduce time spent in repetitive tasks;

  • … when there’s no sense of accomplishment:

    • create smaller tickets with a well-defined goal;

    • try a “Demo-Driven Development” approach (this is a name I came up with): small features that are always “demoable”;

  • … when people feel they are going nowhere:

    • align the tickets with the company/crew objectives, so the goal is well defined;

    • identify blockers and deal with them ASAP (e.g. build issues).

Simple data visualization

In order to track the changes of the team mood over time, we also write the votes down in our Wiki. We keep 3 tables, one for each opposite axes, where each data point is just the date, the value on the positive axis, and the values on the negative one. Confluence can conveniently plot these for you,

Scrum retrospectives Happiness Data

Happiness data

From the graphs we noticed things like cycles in despair and accomplishment, that we regarded as being caused by having features that require a couple of sprints to complete, so the first sprint is full of despair, but when the feature gets finally completed in the following sprint, the sense of accomplishment spikes up.

Written down in words, it seems like a complex exercise, but it’s something that can be done really quickly, so we’ve kept this as part of our retrospectives.

Conclusion

There is no “correct” way of running scrum retrospectives, but the important thing is that they are dynamic and not too long. Also, make sure that people get involved in them. You probably know more or less what people feel from one-to-ones, but it’s important that they share some of that with everyone else in the team. At least, try to record the actionable needs. The happiness axis exercise is quick and it takes the scare out of surveys, and turns it into something a bit more fun. But if you feel stale, try doing something completely different from time to time, like brainstorming for ideas that people would like to work in with others. I’ll come back to that in a future post.