How do I manage Brave New Work

How do I, as a manager of teams, get to do the right things, be less operational, and let my people do the work they are good at. How can I help my people in bringing quality products to my customers and how can I help them do a better job. As a manager we need to look at strategic goals and how to achieve those. You cannot do this alone. You need the people in your teams to help you build this overview. Actually to build this overview in what you and they think the future should look like. We don’t need the situation as it is now, because it is already there in practice. We need a situation of how it should look in the longer term, say a year or two years from now. 

Get vision, mission and goals straight

Ask your manager what the long term vision is, when they don’t know, help them build it. We need to know what the company or department drives. What they think the world should look like in two years, what their position in the market is. A company vision, mission and goals can be translated into a vision for the department. Which can be translated into a vision for a production line. When there is a vision, the team can find out which product should be in the store. Combined with the BCG-matrix they can then choose what products to focus on to be able to offer the right products in the shop.

List your products

Let’s imagine we have a grocery store specialised in greens. There are many products in that store that we offer to our customers. Some sell fast, some sell slow. And depending on our customers' wishes we remove or add vegetables to or from our store.

Each crate in the store has only one product, like broccoli, oranges and carrots. In order to know what we are selling we take a look in the store. We see the crates of goods and we can see what sells good and what doesn’t. 

The first step in an organisational transformation is to get a grasp of the products we are selling. We are going to make a list of all the products we are offering to our end customers. We don’t sell half oranges, we don’t sell semi-finished products. Only the products that our customers buy from us are on that list. Products might be services in this case as well.

Find out who your customers are

Next thing we do is to find out who our customers are. We need to find the target audience and define them in a way we can work with them. For this case we are going to create personas. These are fictive characters that represent the entire customer base for one product. So we create a persona for carrots and we create another persona for broccoli. These personas have distinct characteristics. And have different needs. Someone who is buying broccoli doesn’t necessarily need carrots; they have different goals for the product they buy.

Map the products

Off all the products in the shop we can create a BCG-matrix. In this matrix we can see which products are hot and sell well. We can also see which products are not sold very well and have a small customer base. Carrots are always a popular vegetable and can be considered a cash-cow. It will generate money no matter what. But some vegetables like salsify don’t sell well. They have a low market share and don’t have any growth potential as an independent product, these are called dogs and we might be better off in removing those products from our offerings. The other option is to innovate and pivot.

You might find new products that you need to discover the market for, rising stars, like multi coloured carrots or tomatoes. You don’t know if they will make money but you like to experiment with them and they have a big growth potential.

Get the processes chartered

After we know what products we sell we need to find out how we come to the end product. For vegetables there is a field to plow, fertiliser to put in, seeds to be sown, crops to be harvested, sorted and put in crates, transport to the shop, putting it all on display and selling it. Now this process can be done for any product. This exercise is called value stream mapping and takes in account all the work that is done, the failures that occur and the time that is spent.

Get a grip on dependencies

One of the biggest problems in creating products is that you are always dependent on other people, processes and some form of technology. We need parts only when we need them, not sooner (then we have dead money in the form of inventory) and not later (then we slow down the process). We need our team to understand the complete picture and share knowledge so all the stations can be worked upon when there is a holiday or someone falls ill. And we need the organisation and all the processes to support the goal we want to achieve.

We need to find out all the dependencies we have on the process we use to create a product. There are technical dependencies, like machines and maintenance. There are dependencies on other departments which deliver parts for our product. There are dependencies on knowledge within and outside the team. Find all those dependencies and add them to the drawing we are making. Draw arrows to the parts of the process they influence.

Put it all to practise

Start with finding out what the company drives, why it exists. Formulate the vision, mission and strategic goals for the next two years. Then reformulate with some people on your teams what that means for your product lines. You can make the goals smaller in this exercise, formulate the goal for over two years and break them up into smaller goals of three months each. It is important to do this with the people in the teams because you want them to own the vision and changes.

Next up is to define the products that match those goals, this can be done with product line managers or with some team members. First you make a list of all the products they are making, then you make the list smaller by taking out what is not actually in the shop. Then you plot the products in the matrix to form a picture of what is important and what is not.

For all the important products, the ones you will still be selling over two years you are going to create a value stream map with the team responsible for creating that product. You do this with the team because you want them involved. When they are involved they will commit to the changes as well. As a matter of fact, only their opinion counts, yours is irrelevant. You are here to facilitate the process and to come up with products that everybody likes to buy and build. This might mean that your pet project is killed, we call that collateral damage.

A VSM is simple for starters. Only the process is mapped from beginning to end. Then we are going to add on the mapping. We are going to add times it takes for each step in the process, we are going to add inventory stacks, we are going to measure defects. Defects are results of processes that are of insufficient quality. Nobody likes broken things, so we measure how much is broken and toss the defect in the bin (and preferably recycle when possible).

Improve

Since we mapped all the things we need to create quality products and we create a picture of the future it is now our task to improve. We are going to facilitate the team and the rest of the organisation to improve. We do this by working from right to left if we look at the VSM. We always start with the user experience. With our customers. For instance we take a look at what they need, how many of our products and what features of the product they use. We are going to improve on their needs. We are going to lower inventory based on their needs and try to deliver just in time (JIT). We will also put this JIT trick to work with our dependencies.

At least weekly we will go over our grand master plan with our teams to find what we can improve. Perhaps waiting time can be lowered. Perhaps we need to have more people able to work more stations and need some kind of knowledge sharing or transfer. Perhaps we need to go and talk to our suppliers to deliver smaller batches of parts more often.

With our managers we need to discuss what prevents our teams from reaching maximum performance. We need to discuss the impediments we face. They need to facilitate improvement, like we do. Operational concerns should come from the teams, strategic decisions should come from management. People should do what they are good at and they are perfectly capable of mentioning what holds them back as long as there is a safe environment to speak up. As a manager you need to create that safe environment, involve people so they own the product they make. Facilitate learning through reflection and regular intervals. Never tell people what they need to do, only show them the goals and the way to achieve that.

If you need help, just give me call. And as always, all feedback is welcome.

This is what it means to be transparent

One of the pillars in Scrum is transparency. But what does it mean and what should we do to be transparent. 

Transparency is about showing the work we do, to ourselves, to our peers and to our stakeholders. By being transparent, people around us can see what we do and help improve our performance. They can help inspect and perhaps notice things that we are unaware of. We might be too deep in our work, because of our expertise, to take a step back and oversee our work. People from the sidelines can share their vision and help us to see what we do and where we are going. They can be our extra pair of eyes and spot improvement opportunities. 

Besides improving they can also see what we do and therefor don't have bother us or the team with status reports; because they can see for themselves what we do and how we work.

Show work
We are transparent in what we do when we show the work we do. All the work we do. There are no hidden jobs, everything is on our work overview. When we use a tool to select work and plan the work, we can show the planning. We can create plans for the long term, but we surely want to create plans for the short term from one week up to four weeks. We also want to show our progress towards the goals we have defined for ourselves, this way we can inspect if we are still doing the right things to achieve those goals. As an example a team can use Jira and let everybody view the Kanban board used as sprint log. Everybody in the organisation can see what is happening workwise in the team and see the progress they make. It allows stakeholders to ask questions in order to improve the solution being build.

Show failures
We only learn from our mistakes. So sharing mistakes is useful. There is never one solution to a problem and in collecting mistakes or failures at least we know what the wrong solution was. In collecting those and making those available we can learn and teach others about problems we had and educate them on not doing the same. A knowledge base of post mortems is a very useful tool for the team and other teams in learning and solving problems fast. A fail party or the sharing of biggest screw ups is a nice variant of the board; those are not only insightful but also big fun.

Impediments
Keeping a list of impediments that are clearly visible empowers stakeholders and managers to do work for the team. They can help fix things when they are considered dependencies, whether it be technical dependencies, organisational dependencies, the lacking of knowledge or blockers in any other form. When those impediments are clear and available for inspection, they can work in our advantage so that others can help our team improve.

Inspection, adaption
We are transparent in order to inspect the work we do and how we do it. With transparency we open ourselves up to feedback from the outside. This might be scary at first, but most people in and around our team are there to make great stuff and want our team to succeed. When we inspect what and how we do things, we learn and are able to adapt. Adaption is a super power. Those who can adapt best, will survive. 

So in order to perform at out peaks, we want to be able to adapt. This we can only be done through learning by inspection. And we can only inspect if we are transparent in our work.

I'm curious what you do to be transparent and how well your team adapts. If you want to share, please leave a comment below.

First Time Right by Failing Fast

A leader buzzword is "First Time Right" at the moment. I hear it all the time. But I wonder if people really understand the implications of this. FTR means that when something is published to the target audience it will deploy into production without errors. It actually sounds to good to be true. In all honesty I have never seen a 100% success record of things going into production. So there might be more than just whishing everything will go flawlessly.

There is no try

FTR means that when a thing is put into production, it won't go wrong. Deployment into the real world is full of risks and we can mitigate them to a certain level. No one can guarantee FTR. But we can mitigate the risks in changing the way we make things. When we think about FTR we can see that it should be more than just prayers. I can still see the picture of a former project manager demanding FTR without putting in resources to make it happen. The words of the project managers where literally: "Just try harder to do it right next time". Which reminds me of Yoda's famous words: "Do or do not. There is no try".

We cannot try harder. We can improve our work methods to limit the chance of fails but it is impossible to add another 100 pounds of try. So we cannot try harder, but we can try smarter. Building up to FTR is possible if we focus on the process towards production. We need to fail before we go to production. We need to fail often and as fast as possible. This will reduce the risk of failure at the most critical moment. And even then, there are strategies that we can use to reduce outage when deploying.

Fail Fast

FTR is only possible if we Fail Fast. FF means that we run a lot of tests and experiments early in the process. To FF we need to focus on the process, get a grip on what we do and standardise our way of working. With standardise I mean that a team has a standard way of working. Preferably an automated process in the form of a build pipeline. To that pipeline we add the "Move it to the Left" principle. Which means that, when we look at a pipeline that starts left at development and ends right at deployment, we add tests early in the process on the left side. Tests on the left are cheap, they look at small parts of the product and test as much as possible. These are technical tests or unit tests. The next step is to create integration tests; to see if all new parts of the product work in conjunction with the old parts. These tests are fewer in numbers than the unit tests, but will take more time to complete. Take a look at the testing pyramid to get an understanding of the testing strategy. 

Failing fast means that if there is anything to fail at, that we do that as fast as possible, so we learn fast as well and can mitigate risks when going to production.

Deploy safe

When we mitigated most risks by failing fast the chance remains that we fail our deployment in production. Deployment is never 100% waterproof. But we can use deployment strategies to reduce the chance of an outage. We can use blue-green deployments; in which a deployment is made to a shadow environment and when all is up and running, production is switched from the old to the new one. We can also think of a canary release strategy. In this strategy a new deployment is made next to the old one and instead of switching all over to the new environment, we switch small groups of user over, say 10% at the time. We can measure closely the impact of the users on the new system and if things go south we can roll back to the old instance.

So to reach a First Time Right situation we need to focus on the process of development: Move it to the Left in order to Fail Fast. And we need to focus on the deployment by using a deployment strategy that fits our situation. If you want to achieve FTR you need to put in effort, be ready to fail a lot and be open to learn when you fail. Have fun!

How to set up a successful review

The review is a scrum event that takes place at the end of a sprint. Its purpose is to inspect what has been done and what is going to be done with the team and the stakeholders. During this event there might be a demo to show what kind of stuff has been created. In the review a new plan is made to tackle the upcoming work, to check if we are still on the path to the intended long time result. Participants in a review should consist of stakeholders and leaders. They can relay their needs and strategic goals for the product that is being build.

Sprint goal

In the review the sprint goal of the next sprint is discussed. This goal can be seen as a mission statement; what are we going to do the next sprint. A sprint goal is typically a sentence describing the desired outcome. For example: after this sprint component X will be live. Or application Y will comply to all security demands. A sprint goal creates focus for the team, with a defined goal they understand what needs to be done. A sprint goal should be derived from strategic planning by leaders, so the purpose of the sprint becomes clear. All sprint goals should be achievable in the allotted time frame of a sprint.

Planning

During review the team and stakeholders should gather those stories that are needed to complete the sprint goal for the next sprint. They need to formulate which tasks needs to be done to achieve the goal. Leaders should express their strategic goals so the team can understand what operational goals are needed to achieve those. Stakeholders should do the same, they have needs that the product fulfils, and therefor they need to be clear on what they need. This planning part is not putting stuff on an agenda, it's about setting out lines how to approach the next sprint and to find out what is important.

Demo

During a review there is room for a demo, a moment to check if what the team has build lives up to what was expected. It is like a debrief of a mission. The team should present their accomplishments and check with stakeholders if they are satisfied. During the demo, stakeholders can be invited to work with the product so they will get more involved and are able to give direct feedback.

Dependencies

During the review all the stakeholders are present. This is an excellent setting to find out dependencies and talk about them. There are technical dependencies; like machinery that is needed to make the product. There are process dependencies; like other departments delivering a piece of the puzzle (like a service that is needed for this product). And there are people dependencies; people are needed, or knowledge is needed to make a successful increment on the product. All these dependencies should be mapped, to mitigate risk and to make the team able to make a proper planning during the planning event.

At the end of the review event there should be a sound sprint goal with a description of what to do. It should be clear who and what the team needs to be successful. And last but not least, the team ought to have obtained feedback so they can improve in the next iteration. All in all it is imperative that stakeholders and leaders are present during a demo to improve performance of the team. They need to share vision and their strategic goals. And they need to let themselves be heard so the team can collect feedback and improve.