Why are we doing this?

I am always keen to try different ways of working. There is value in shaking things up; it forces people to try and think about things from first principles. It is rare for people to question their ways of working when it has already been established. If you join a development team and they are using SCRUM to deliver their work, you can read about SCRUM and just apply that way of working. Often people blindly follow these ways of working without questioning why. I’ve known developers who work on a project for years and end up spending days of their life pointing tickets, and when you ask them why they are doing it, they don’t know. I appreciate this is probably a sign they aren’t doing things correctly or they have a poor Scrum Master who isn’t facilitating these sessions properly. Despite this, I think it is widespread for people to take the easy path and not ask the question, “Why are we doing this”.

Keep it simple stupid

I also really like things to be simple. It is too complicated if it takes a long time to explain how something works. Especially when this is about processes or ways of working, processes should be simple and streamlined. There’s a good quote from Steve Jobs about how people who work on processes end up building an industry around them, and soon you have people managing the processes:

So they start to try to institutionalize process across the company. Before long, people get confused that the process is the content. That's ultimately the downfall of IBM. IBM has the best process people in the world. They just forgot about the content.

That's a little bit of what happened at Apple too. We had people who were great at management process. They just didn't have a clue as to the content.

Ultimately the problem is people forget the outcome and think the process is the purpose of their job. One of the Agile's core principles from the Agile manifesto makes it clear this is very much the antithesis of what Agile is trying to achieve:

• Individuals and interactions OVER processes and tools

Some of these large heavy-weight frameworks, life SAFe, are incredibly frustrating. They are often overcomplicated and are certainly process over people. It creates an entire industry of process people but rarely helps organisations achieve their goals.

Mission Briefs

Your mission if you choose to accept it

There is a way of working we have been trialling at Gemba Advantage on some of our projects. I wanted to share the concepts of it here. Hopefully, it encourages a “people over process” way of working and is relatively simple to understand. If you are reading this, I hope it helps you think about ways of working from first principles. Even if you don’t use anything from this blog, I hope you question your ways of working and make sure they are helping you solve problems for your users, not just process for the sake of process.

Before I explain what mission briefs are, I thought I should explain some of the initial objectives I wanted Mission Briefs to address:

• Spend more time on the problem - Force a slowdown so our development teams spend more time defining the problem. Ensure we build the right thing and help avoid the build trap.

• Maximise collaboration - Include more people in the process.

• Move developers left in the process - Ensure developers are involved as early as possible and have the most context possible.

• Focus on the outcome not the output - We want to ensure what we build unlocks value for our users

Help derisk the four risks identified by Marty Cagan in his book Inspired:

• Value risk (whether customers will buy it or users will choose to use it)

• Usability risk (whether users can figure out how to use it)

• Feasibility risk (whether our engineers can build what we need with the time, skills and technology we have)

• Business viability risk (whether this solution also works for the various aspects of our business)

Now the age-old problem of defining requirements in a way a developer or group of developers can build it. Enter what we term a Mission Brief. The Mission Brief consists of two parts:

• Day in the life (DIL) - Defines the problem

• Technical approach (TA) - Defines the proposed solution

Day in the life (DIL)

At Gemba Advantage, we work to improve people’s working lives. So most of the capabilities we build are used by people in a work context. Ideally, the capabilities we deliver should impact their daily working lives, making their working lives better, more productive and more enjoyable. The day in the life imagines we have delivered one such capability, and one of our users is so impressed by it they choose to write a blog about it. This blog outlines why they like this capability so much. They explain what it allows them to do they couldn’t do before or what friction it has removed from their working day. We imagine a user writes this so it doesn’t contain any technical jargon. It only explains it from their point of view in the language they would use and understand.

We imagine this future, and then our product manager leads on writing this blog. In some cases, we get our users to help write this blog. Once we have this blog written, we can then publish it like a real blog and share it with all the relevant stakeholders, including:

1. The product team.

2. The users.

3. Business stakeholders, e.g. policy or compliance people.

This should be a quick and enjoyable read, just like a blog. Anyone can then leave comments on the blog. Users might just say, “This would be amazing”, OR they might question the value this would provide to their day-to-day working life. Business stakeholders might ask, “Doesn’t this violate GDPR?” or “This sounds very similar to capability X”. A developer in the product team might ask, “Are you getting these data feeds in real-time?”

This helps us address risks early in the process. Writing this blog is cheap, quick and easy, and we can learn much early in the process. Users are helping us derisk the Value risk. Business stakeholders are helping us mitigate the business risk. Our Product Manager can then reach out to the people commenting and iterate until we get it right. We can get to a point where our users are excited, and business stakeholders know early on what we are looking to build and know we are dealing with their concerns. Once this process is complete and we are confident we have an idea worth building, we create a finalised blog. This includes any relevant comments with their corresponding responses. These comments now help capture some of our non-functional requirements. We might not always get to a finalised blog; not all ideas work. Users might not be excited by the blog - this is excellent news! We haven’t wasted time building something they don’t need. We learnt this in days, not months (or sometimes even years). It means we can find another problem to solve that does address their needs.

You may notice this now looks very similar to the Amazon press release. We have worked backwards, outlining the value, and the comments are very similar to the set of FAQs. This is not by accident. The DIL is our mini version of the Amazon press release.

Technical approach (TA)

Only when we have a blog that we know has users excited we move onto this step. We only want to work on stuff that users want. The tech lead in the team owns the technical approach. The aim is to mitigate any feasibility risks and usability risks. If the solution involves something user-facing, you will want to include a designer in this step. The tech lead and designer are encouraged to prototype to learn and derisk at this stage. The Mission Brief is all about learning as early as possible.

If the solution is low risk, we might only need a little in the TA. However, if we are doing new things, for example, if the solution is going to require new data from another team, the tech lead might want to make a quick prototype that grabs some data from this team. This means we know the API spec and authentication model required. It also means we know if that team have a dev environment, we can use for our development. We might gain some contacts in that team we can use. If there is a UI element, we would want the designer to have prototyped and tested a number of wireframes with the users. Make sure it is easy to use. The tech lead should be derisking the feasibility risk while the designed is derisking the usability risk.

Once we have the TA written out, it should include some high-level designs, wireframes, recommendations etc, we can share the TA with the full product team. This allows every member of the team to question the approach and ask any questions. We can go around this cycle a couple of times until the team is happy to start work on it - they can accept their Mission!

Developers should now know the problem context from the blog and shouldn’t hit any significant technical hurdles. It should still provide them with scope for creativity in their solution. Their main aim is to make the blog a reality.

The amount of derisking is more of an art than a science. It’s important to note the tech lead owns this, but they don’t have to do the work. They might want other devs to do some of the de-risking activities. However, the tech lead is ultimately responsible for the technical approach. How you want to do this depends on the setup and culture of the individual team, but collaboration is strongly encouraged. It's essential for developers to feel they have ownership and aren’t just ticket monkeys doing the tech leads bidding.

Summary

In summary, the process of a Mission Brief is as follows:

1. Write a blog outlining a future our users want to see.

2. Share this blog with a variety of stakeholders, including users, to get feedback and refine the blog. Any questions people ask that are not addressed directly in the blog, leave as answered comments under the blog. If the blog doesn’t have the reaction we need from our users, we ditch it and try again.

3. Create a technical approach outlining the approach to the solution after derisking any technical hurdles or usability risks we foresee.

4. Share with the product team and iterate until the devs are happy to accept their mission.

5. When work is complete, review the blog and make sure the future we outlined at the start is a reality. If not, continue until we have unlocked the value for our users.

The last step is essential. We need to make sure we have solved the problem for our users. It’s possible our initial solution doesn’t work as expected. If this does happen, we should produce a new TA that does solve the problem before we move on to the next mission.