Working in an agile team

How does working in an agile team differ from working in a traditional team? Working in an agile team for the first time can be very challenging and you might rethink the way you work.

The first rule of forming an agile team is multidiscipline. An agile team should be able to do all the work, but not everybody in the team has to be able to perform all tasks. The second rule is a clear product vision and purpose; what needs to be build and maintained and why. And the third rule is: don't meddle. Let the team decide and give room for mistakes. Help the team get better and never punish.

Traditional roles are fading in a team. A programmer is learning to test, an operator is learning to code and a tester is learning to develop. All roles become less important and the knowledge is shared. Local heroes are replaced by team players; who support each other in getting the job done. 

One of the most important behaviors of an agile team is working in pairs. This makes sharing of knowledge possible, facilitates reviewing and saves time. While this sounds counter intuitive, results show that lead time and cycle time for changes drop significantly when people pair up. There is also a lower defect rate, less technical debt and more customer satisfaction.

Over time the roles are becoming responsibilities. A multidisciplinary team consists of engineers who are responsible for a part of the development and maintenance of a product. They are responsible for the piece of knowledge they bring to the team. They are expected to keep developing that knowledge and share it with the team and similar interest groups within the company. It is not really important anymore what exactly the job description of that person is. When they belong to the team, they become engineers that want to build excellent products and services for their customers.

An agile team is all about customer value. They engage in customer relations and find the best way to improve customer value. Work does not come from managers anymore but directly from customers. An agile team is not part of any project, it is part of an organisation that builds stuff for customers. In a big enterprise vision and goals (long term) are shared by leaders and teams use that to focus goals on a quarterly basis and in sprints. They organise the work they receive from customers around these goals.

Because an agile team is responsible for the work they do they are multi disciplinary, because they need to serve the customer best they have self autonomy and because they need to know where to go they need vision. 

How to fail without fear?

Failing in production is bad. There have been many solutions, but non is guaranteeing a 100% success rate. There is always a chance things will go bad when we deploy to production. What can we do to mitigate this risk? Over the years there have been many solutions, albeit most of them are technical ones. Let's have a look at different solution that we have come up over the years and find out how we can minimize risk when we deploy.

Fix in production

The first thing we did when something fails is to fix it as soon as possible, most of the time this was in a production environment. Although we can bring our service back up real quickly, the uncertainty of the deployment makes us feel weary to actually do it more often than necessary or on any regular basis.

DTAP

In order to tackle all the problems we have encountered in a production fix, we introduce different environments to test every possible situation. I have seen up to seven different environments in one situation; just imagine the cost and the result is that a lot of environments are doing absolutely nothing for most of the time. 

Next thing we see here is that not all the environments are exactly the same. There is always a minor difference in those environments that can bite us in the last step to production. I've seen different size clusters, different machine configurations, different firewalls and even different data connections.

The strength of multiple environments that are dedicated to one phase gets nullified by the increase in maintenance, the extended process and the cost.

Cloud

In order to solve the DTAP-trap we can spin up environments on demand to test. This means we don't need idle DTAP stations. We can actually do with one instance of a cloud platform. Just spin up an environment, run the necessary tests and then kill the instance. We get billed by the time we use the system, the system is identical to production and our process is smaller.

Pipeline

In order to facilitate a solid process of testing and deploying it is mandatory to use an automated pipeline. A pipeline can be seen as all the steps that are needed from development to production within one automated process. When we hook this up to the cloud and we make it as fast as possible. We can almost mimic fixes in production this way. And because we can implement safe guards through the whole process we can be almost sure that our stuff works.

Experimentation

In order to fail without fear we need to move to pipelines and cloud solutions (either on or off premise) and we need to feel relaxed with experimentation. Experimentation early in the process gives us the opportunity to learn new methods, processes and technical solutions. The more experience we get, the less chances there are that anything will fail.

Conclusion

In order to be sure we deploy safely and with the lowest chance of failure we need to focus on cloud-like delivery through automated pipelines. 

Fight technical debt

Many software projects suffer from technical debt and there is not enough priority to solve them. With technical debt comes dependency and versioning problems, security issues and a non sustainable application. The longer technical debt is not treated it becomes exponential harder to solve.

When does technical debt occur?

Technical debt arises when the world around the application changes. For instance when dependencies are upgraded, supporting applications are upgraded, interfaces are renewed or new vulnerabilities are found. 

Another reason for technical debt is shortcutting, this means that we bring out a new feature that a client really needs but we take some shortcuts to make it work. The solution is there for the client, but it hasn't been implemented in a proper technical way. In this case we can reap the benefits of the new feature early, but we need to fix the implementation later on in the game. It gives us a short boost and an advantage over our competitors but it needs rework once released.

How does an application suffer from entropy?

Entropy is the aging of systems and the loss of relevance and compatibility of the application during this process. All systems are suffering from entropy, which is solved by updating those systems on a regular basis. When an application isn't updated while the surrounding infrastructure and application are, the application becomes seriously affected by entropy. Therefor refactoring of the application becomes mandatory.

How can we find technical debt?

Finding technical debt can be hard. Luckily there are applications that can help us spotting technical debt. One of those applications is SonarQube. With SonarQube you can find security flaws when new security insights are found. You can scan for CVE and OWASP vulnerabilities. You can also use this tool to spot deprecated dependencies. 

What can we do to fight technical debt?

Reserving time to refactor the application is important. When someone touches code, they should also solve reported problems in that piece of code. Writing unit tests on all the code we touch helps us in refactoring without breaking the correct working of the code.

Having a clear understanding of the dependencies  we use in the code is important. We need to keep ourselves updated on the versions of the dependencies and we need to do refactoring when a dependency is deprecated. 

By regularly building and testing our code we can get a grip of all the vulnerabilities in de the code. Even when we don't touch the code for a while, we need to regularly test for new vulnerabilities and implement fixes when we spot them. Refactoring and unit testing here is important as always.

Last but not least we need to give ourselves time and priority to do all the above on a regular basis. In other words, setup a build that runs automatically at least every week, preferably every day that inspects against entropy, dependencies and vulnerabilities and act on the results as soon as possible.

Conclusion

By inspecting our code on regular intervals and refactor it, we can keep our application safe and up to date. Keep technical debt as low as possible by acting on a changing world. Implement an automated build pipeline to make life easier and write unit tests so you can easily refactor.

Vision, mission and goals

Your team, department or company is just another fish in the pond. You produce stuff that people buy and that's it. When the world changes you might face a serious problem. Many companies have gone broke and ceased to exist. Out of business, for good. How can this happen? Why do some companies survive while others perish? 

Kodak and Fuji are good examples. The first one produced camera rolls, just like the second one. But when the digital camera disrupted the market, Kodak chose to stick to camera rolls, while Fuji focused on film; all kinds of film, layered plastic film. Kodak could not pivot by lack of vision, they where short sighted and only focused on the analog camera roll. Fuji on the other hand understood that it was making film that could be used in analogue cameras, but also understood that there are many other purposes for film. The first one went out of business while the latter one still produces film.

In this example we see that Fuji had a vision, a broad view of the world and its needs over a long period of time. Kodak did not have a vision for a longer term and they gambled and lost.

Another example. Elon Musk is successful because he has a vision that one day, men will be living among the stars. To make that happen he needs to be able to travel to space, so he makes rockets. But he knows that the planet will probably not survive long enough to reach to the stars due to pollution. So in order to achieve his vision he needs to act on that as well, hence he started Tesla.

Vision

Vision is one of the most important aspects of a company. Small startups have success because their vision is still alive and clear. Big companies that produce a lot of different stuff with a lack of vision might survive, but have a big chance to fail at any market disruption because they are not able to pivot based on their vision.

Developing a vision is imperative to give a company focus. A vision is about what a company wants to achieve in four years or even longer. We should ask ourselves: "What is the purpose of the company?", "Why do we exist?" A vision is about one sentence capturing the essence of the company.

Some examples:

Nike - "Bring inspiration and innovation to every athlete in the world"

Unilever -  "Make sustainable living commonplace" 

Netflix - "Helping content creators around the world to find a global audience."

As we can see from these examples, the companies could pivot, change their products and still fulfill their vision. Nike could go into gyms, food and stadiums. Unilever could go into housing and farmlands. And Netflix isn't bound to the internet. 

Mission

A mission is about how you are going to achieve the vision. Typical questions are: "What will we do?", "How will we do it?", "What do I need to do to reach the stars?"

A clear mission is made for a middle long term, about one to four years. It gives meaning to the vision, makes it less abstract. A mission should be revised as soon as the market is disrupted, while probably the vision will remain the same.

A mission for Nike could be: to start a company that creates composites for new soles or they could produce a movie about the origins of the Olympics.

Goals

Goals are the short term anchors on which to focus in order to achieve the said mission. Goals stretch from three months to about a year. They are clear, market focused and descriptive. Goals are something like a plan for the next quarter or year.

Cascading

This system of vision, mission and goals can be cascaded through the company from C-level to teams. A company will have a vision, mission and goals. Departments will have their own vision, mission and goals to cover the goals of the company. The same goes for teams. They will formulate their own vision, mission and goals based on the goals of the department. The further down the chain, the shorter lived the three elements are.

Just imagine a pivot of a company, this means all department and team elements must be flushed and remade in line with the new company goals.

Battleplan

In order to have your teams, departments and the whole company move in the right direction, you should formulate a goal. Mind you that this is a hard exercise and should not be taken lightly. You are going to be stuck with the vision for a long time, so spent enough time on it to get it right. Get the people involved, sketch, write, bin it and start over. Refactor the outcomes, right until it feels right, gives you meaning and energy. Writing a vision can take days or weeks. It is important to get the feeling right.

Once the vision is done, start with the mission. This is also no more then about a sentence, it describes how we are going to achieve the vision. It is important to stick to the how. Again sketch a lot, throw all away, start over and refactor until it is right.

Based on vision and mission the goals need to be created. There might be many goals, the rule of thumb is that there are about as many goals as there are departments, so every department can fulfill one goal. Do not base the goals on departments though, if there is no match, perhaps the department should be reworked and not the goal. Form the company about the vision, mission and goals, not the other way around.

Refactor

The world is constantly changing, we need to adapt to survive. The only way we can do that is to keep our eyes and ears open and pivot when we need. Pivoting is changing the course of the company to match the market demand. Pivot is what Fuji did and Kodak did not. 

In order to pivot, we need to refactor or rework our mission and goals often. We need to inspect them on a regular basis and we should adapt them when we see a disruption. Managing a company, department or team is hard work, these three mentioned elements should be at the core of that work. 

New world leaders

A new world leaders is someone who owns the vision, mission and goals. That leader can explain why a company is working the way it does. Why stuff needs to be done. A new world leader is always explaining why we are doing the things we do, because of the vision the leader wants to achieve. When you can explain the why as a leader, you build a successful company, department or team.

Vertical silos

"Dev(sec)Ops: everything you do to overcome the friction created by silos ... All the rest is plain engineering" - Patrick Dubois on Twitter.

Removing horizontal silos between different parts of the organisation is getting pretty common. We see ops and test integrated in development teams, shifting all the work needed for a product to one team. Disciplines in the team are shared and taught to each other and greater knowledge of the product and the process is obtained. The customers are benefitting from these results and are receiving better quality products.

But there are still hindrances when it comes to organising all this. We are still keeping old structures of hierarchy in organisations and push operational tasks to the teams. Impediments are solved through escalation processes and there are still change advisory boards and other boards that try to direct the operation. We call this vertical silos.

To get rid of vertical silos we need to do something. We need to scale. One way is to scale with the use of frameworks like SAFe, Nexus or LeSS. The other way is to de-scale. Let's have a look at the latter one.

First step: leading from behind

De-scaling is a multistep operation. The first step is changing how we lead the organisation. We should lead as wolfs do: Lead the pack from behind, not from the front. Teach and show, don't impose. This means that leaders let teams do their work, ask them if they can help them achieve their goals. Leaders must start propagate their visions and goals, and explain why those goals are important. 

They should not do any operational work, or influence the work being done. They are here to support the teams in improving their performance. Leaders need a bit of know how of the work, but not too much. They need to be experts in leading. 

Second step: reduce layers

When the leaders are thinned out, the next step can be taken. We start to remove management layers in the organisation, these layers are making your organisation slow to respond to the market. Each layer is a processing step in the vertical organisation. Information is consumed, processed and given to the next layer. We see that all these layers don't add any more information on problems and only make communication more complex. Thus resulting in a slow performance.

Take a critical view on the management layers that are in place, think outside the box, have a look around to find answers to how to reduce layers. As a rule of thumb, try to have a maximum of three layers from management to teams and less if possible.

Third step: autonomy

In order to make teams perform better, they need autonomy. In a complex IT environment the best engineers thrive if they are given enough autonomy. This is a two way street, autonomy and responsibility. Whilst they get autonomy they are becoming more and more responsible. They need the right people in the team, they need to do the right things and they need to raise impediments when problems occour. 

Fourth step: small startups

With great vision from the top, middle management reduced and teams than can find the way themselves because they have the autonomy to do so you are ready for the third step, creating small organisations within the bigger whole.

Then it is possible to look at teams as small startups, little companies within the company that are trying to achieve something. Those small startup should be fairly self sufficient, they will ask support from the organisation when they need it, not the other way around.

De-scaling in short:

1. Start showing vision, mission and goals
2. Remove surplus of management, reduce layers
3. Reorganise autonomy and responsibility
4. Make teams independent as small lean startups

How to be successful in the cloud?

Teams switching from traditional environments to a cloud model face many challenges. Working with cloud demands new skills from the team and a radical different approach to the development of software.

What are the factors that contribute to success?

To be able to survive in the cloud, a team needs to understand measuring. One does not simply drive to Italy with the dashboard blacked out and the windshield painted black. A team needs to implement measuring to see where they are going. This means application, infra and team metrics.

In order to take advantage of what the cloud has to offer, a team needs to invest in automation. Fully automated build pipeline, scaling infra, infra as code. These are fundamental for working in a cloud environment. They are also very practical when you work in a traditional environment, so you can start whenever you want.

A team needs to be multifunctional, this means that the team should be able to develop and maintain their product. Not all team members need to be able to do everything, but in total the team should not need external support. 

When a team needs to make decisions they should be able to do so themselves. They should not need to get authorizations from anybody else. After all a team knows best what they and their application is doing. A team should be in control of all their environments, pipelines, application and development.

Learning is the most important factor when it comes to working in the cloud. Continuous improvement can only be achieved by letting things fail, inspect and measuring. Teams need to learn how to fail fast, inspect early and improve skills and architecture.

How to be successful?

Measuring is done by defining KPIs with the team. Define reachable goals on performance, predictability, learning. Think about what you and your team want to improve and start measuring that. Make a simple and broad dashboard on which you show our KPIs and rework them on a regular basis. For the application and infra tools like ELK, Graphana en Prometheus can help a lot in getting insights in the application performance.

Rigorous automation is mandatory. By automating manual processes, a lot of time and quality is gained. Reserve enough time to improve automation. It is important that all team members contribute, all disciplines can reduce work and improve quality by automation. Build pipelines, automate triggers, incorporate quality.

Have you ever seen toddlers playing in a sandbox? Notice that they sit next to each other and play their own game. Only after they grow they learn to play together and share toys. This is the same behavior we see in teams, everybody working hard in their own discipline. It is only after we pair and learn to share knowledge and develop each others skills that we become more mature in our work and can become multifunctional. One of the nicest workshops you can do is to make T-shape profiles with the team. People will find shared interest that they can use to team up. 

To get authorization to the team, we need more than just the team. Management and change advisory boards must be willingly to give away their powers. But with great power comes great responsibility as well. So the team should be very transparent in order to gain the powers. This starts with getting grip on the flow in your work. Create a value stream map for all the products you create. Map the delays, risks and dependencies. Get management involved in the flow of things and your challenges. This will build trust and will grant you more powers.

You can only really be successful if you know how to fail. Make failure small and simple, define quality standards, inspect all failures thoroughly in order to learn. Involve the people around the team in the inspection and learning process. One start is to learn how to read error log files with the team, inspect stack traces and logfiles. You can also use tools to try to break your application like chaos monkey or attack proxies.

Have success

When you implement the points above you have a good jump start at being successful in the cloud. By regular inspection and being transparent, you, your team and the people you depend on can help grow a successful cloud implementation. And the beauty is, that it also works if you working in a more traditional environment.

What are the characteristics of a DevOps team?

Putting Ops in a Dev team or vice versa it is not sufficient for practicing DevOps. There is more to it. So what does a DevOps team typically do?

1. Measure

A DevOps team measures itself, it's product and the business value it generates. The team measures itself via feedback and reviewing of goals. The product is measured via tests through automated pipelines and value is measured via stakeholders and performance indicators in the application it builds.

2. Performance

A DevOps team strives for performance and improvement at all time. By regular inspection a DevOps team looks for performance improvements in the way of working, in the application and in its organisation.

3. Risk and refactoring

A DevOps team will do risk analysis, refactoring and supports secure coding and operation. The team is on top of its game when it comes to security and uses tools to measure the static code and does penetration testing on the running application. It refactors code, rewriting code blocks for better performance, improving code quality and readability. 

4. Automation

A DevOps team will strive for full automation of changes from testing, building, deploying to maintaining. Full automation is achieved by coding a pipeline, using gates to test for quality and automate deployment. They get rid of all manual actions in the process. They try to achieve a self healing system when production falters.

5. Transparency

A DevOps team is always transparent and open in what work and when they perform it. Visual management is available for all who want to see it, that is the team, but also stakeholders and leaders. Opening up the ability for them to help and improve.

6. Vision

A DevOps team has a vision and strategy for each product they support. That vision is derived from the company vision. Strategic goals are the lighthouse on the horizon for the teams, so they can create focus on what needs to be done. Vision created by leaders must be simple and clear for everybody to understand.

7. Mixed roles

Members of DevOps teams work together mixed in multiple roles. Not everybody needs to be able to do everything, but the team should have the capabilities to do everything. No outside support should be needed. With pairing knowledge is shared so there is no local hero or one weak spot.

8. Dependencies

A DevOps team keeps track of all life cycles, versions, licenses and dependencies it uses. By actively managing dependencies a lot of misery is avoided. Understanding versioning and deprecation is mandatory for good life cycle management on dependencies, but also for the application that is built.

9. Autonomy

A DevOps teams strives for full autonomy and loose coupling in the organisation, processes and technology. Hard coupling makes a team dependent on other parts of the organisation or on a certain technology. By trying to interface with dependent things, dependencies are loosened, which makes the team and application more flexible.

10. Responsibility

A DevOps team is solely responsible and in full control for the product they work on. This must be supported by leaders. Leaders are stakeholders and impediment removers, they support the team in improving performance, they should not interfere with the work that needs to be done. If they need to interfere it is via the vision, mission and strategic goals they develop for the team.

Disclaimer: A team practicing DevOps does what's on this list, but a team that does what is on this list is not per se practicing DevOps.

Good is just not good enough

You have tried as hard as you could, only to find out you have been beaten. Sometimes doing your best just isn't good enough. This doesn't mean you didn't try. It just means that someone or something else was better than you. High performance teams want to deliver fantastic products for their customers and they need to work hard for it.

Fantastic products
In order to create great or fantastic products for your customer you need to create quality. You need to deliver your best performance and try for even more. Most customers don't precisely know what they want, but they have a fair understanding of the problem they are facing. They should name their wishes but not the solution. You have a fair understanding of all the possibilities and are in a position to come up with even more after a couple of hours of digging.

In order to create the best solution for a customers problem, find out the problem behind the question they are asking. Try and create a solution to the best of your abilities and include the customer. While you are in the solution process you and the customer are finding even more solutions to the problem you are facing. Fantastic products are fantastic because they seem simple. This often means that the process of coming to that solution is hard. Performance is key to simple solutions. Not text book solutions, but solutions that are the result of a creative process between you, your team and the customer.

What is good, what do our customers think is good
A right solution for the customer doesn't mean it is good enough for us. Do we want to deliver what the customer wants or do we want to deliver solutions that make us proud? Sometimes they match, most of the time they don't. Push your team to the best solution, the one that looks simple but is most of the time hard to obtain. A seemingly simple solution will make the customer happy, make the team better and makes the product easier to maintain.

How do we find the sweet spot
In order to find the solution that fits our customer and our needs we need to find the sweet spot. We cannot achieve victory without making choices. And sometimes we need to make sacrifices. Sacrifices in product creation are abandoning a solution you worked hard on but doesn't do it for you or the customer. It is better to let go and take the loss than to keep on going with a bad solution. Pivot if you need. Our sacrifices can include: putting more hours in, moving a deadline, getting rid of a chosen technology or process, switch people and so on.

Inspect and adapt
View your solution from the eyes of the customer, is it simple enough to understand? Can we use the product without reading an extensive manual? Do we need all the features in order to reach our goal? Is the design or layout correct and intuitive? Have we made a safe or secure product? Can we break it easily?

All these and more questions need to be asked, reviewed and improved upon. Only through regular inspection of the product and the team can we improve.

Do we know better than our customers
Yes and no. We don't know exactly what our customers want, but we know the processes and technology that we need to use in order to make a great product (or we know how to learn it). As a team we know how to work together and get all the important information from the customer. We are ready to change everything we do in order to come up with the right solution. We understand that nothing is written in stone when it comes to delivering the best product to our customers.
Our customer probably know the problem best and needs us to extract it, understand it and solve it. We can do that when we have a high performance team that is capable of customer interaction, that has extended knowledge about the processes and technology involved.

So if you want to be good, if you want to be a winner, if you want to be a high performance team, be ready to inspect and adopt as much as possible. Aim high with the team and the customer. We are not looking for mediocre results, we are not looking for something that just works, we are looking for the creation of seemingly easy to use product, with the highest quality that satisfy our customers more than they expected.

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.

Team skills for cloud solutions

If you want to go to the cloud, you need to learn how to fly. In order to prevent castles in the air, teams need to have a fair understanding of the risks and capabilities that are needed to successfully move to the cloud. Whether internal or public, any team needs to obtain knowledge to prevent screw-ups. A cloud environment is a hostile environment, without proper knowledge or experience any team moving to the cloud is bound to fail if they don't educate themselves.

The main risks of cloud are complexity and costs. Both can be managed if a team understands them well. Let's start with costs. In the cloud, we are talking container platforms here, billing is done by compute. Compute means usage of system resources. Containers with apps that are switched off don't cost a thing, containers with apps that are running are billed by the second. Traditionally apps ran on (virtual) machines, which were always on. So a monthly bill about the costs of the VM was about it, there was a fair understanding of how much the app would cost upfront. With cloud this is a bit harder to predict. If your app isn't very much used and is always available, the bill might be high. If it is not used and switched off (ready to start when a request to the app is made) the bill might be much lower. And if your app is populair and scales up, thus using more compute, it will costs you a lot more than perhaps anticipated. 

To take advantage of the cloud model, up- and out scaling is important to understand. Breaking your application down into micro or macro services is paramount for a successful scaling model. This model can be used to take advantages of the cloud in shutting down low used services, limiting costs, or scaling up much used services to improve revenue.

A team building and maintaining the app in the cloud needs have some capabilities to support this cloud model. They need to be autonomous, command themselves, be able to take action without approval (or with implicit approval). To facilitate this an agile way of working is required. It doesn't have to be a particulair practice, method or framework. The agile concepts need to be understood and implemented. 

What they need to do next is to automate the development pipeline. Everything from check-in of a change to deployment should be automated. There cannot be any manual steps in this process. This requires rethinking of testing, approval and deployment. Another part of automation is monitoring. The app needs to be monitored, the business process needs to be monitored and the team should monitor its own performance. All these metrics should be easily available in a transparent manner. This enforces interaction and trust with the stakeholders. 

This was all about mitigation, but what if the shit hits the fan and there is a disruption in the service provided by the app? Think of break ins or outages. The first thing is security. This is a discipline that should be practiced by all members of the team. It's just like locking your house or car, or providing a good lock on your bike. A team should understand security risks by applying some form of thread modeling (STRIDE) and they should practice outages on a regular bases. The last one can even be automated by the use of a Simian Army. 

Also think about when there is actually a compromised situation or an outage. No one else is going to be called upon then the team. So they need to organise themselves to be available at all times. 

Moving to a cloud solution might sound easy, but it's much more complicated. Teams need to learn a lot of new practices to be able to safely navigate the complex cloud world. They need to feel responsible, they need to inspect their performance constantly and they need to learn new things each day.

How to start a DevOps team

DevOps is about the removal of silos. Breaking down barriers between different parts of the organisation. It is about getting everybody on the same team and be more effective. Teams focus on one product and making sure it works for the customer. It is like moving along a makeline with the complete team to build a car. Everybody has their own specialty at different stations in the process and instructs the team how to operate that station. The whole team works together to pass the quality standards of that station. This ensures the team owns that build, and be proud of it. It ensures sharing of knowledge of that particular station to all team members. 

For (team)leaders it becomes most important to lay out the goals, to work on a strategic level instead of an operational one. They need to work on resolving dependencies. If for instance a supply line to a certain station stagnates (they are running out of bolts for instance) they need to go over to the supply line and find out how to help that line speed up production.

The operational level is covered by the people working on the product, they are skilled and trained to work on those stations. No leader is needed to tell them what to do. The team therefor needs a fair understanding of what they can and cannot do. For the latter one, they also need to know what they need to fix the impediment of not being able to perform a certain task to the level they need to. They need to understand their short comings so a leader can help them overcome that. This often means injection of knowledge. This knowledge can only be obtained from an external source, either a specialist that runs with the team for a while or a training course. For the specialist the most important task is not to fix the knowledge gap, but to inject their knowledge into the team, so they can leave safely after a while.

A typical DevOps team incorporates different disciplines. In software engineering this means that there are at least developers, testers and operators in the team. While they have a certain job, working in a DevOps team also means taking interest in the other disciplines as well. Pairing up to fix stuff is one of the major aspects of an effective DevOps team. Therefore I prefer to call all team members in a DevOps team engineers. It doesn't matter which profession somebody has, if they are not able to switch roles and help the team perform better, there should be no place for them in a DevOps team. DevOps teams are about performance and delivering stuff to customers they need. 

When you want to start with a high performance team, make sure all the disciplines needed to build a product from concept to grave are in the team. Not all disciplines are roles, some people can perform more than one role. But do try to avoid a local hero, one person that can do everything, this can prevent knowledge sharing. As a leader find out how you can best help the team, remove impediments and resolve dependencies. Start with forming a small team (3-5 members) and formulate the goal of the product. Use an agile work method to create small iterations with a lot of room for inspection and improvement. Keep stakeholders close and get them involved. Take small steps and keep things as simple as possible.

A DevOps team is a high performance team that will take responsibility and pride in their work as long as they can be autonomous and are supported by the leaders. Leaders that help them overcome impediments and resolve dependencies. With clear goals, a small team and a supporting leader, DevOps teams will outperform any other team all the time.

All about removing silos

Organisations are optimised in silos. This makes work efficient. Costs can be reduced by economise work done in a particular field. This has been the way of working since Taylor died. It does optimise work in factories for people working in a particular order on an assembly line. In a modern world where we build software, saving money on one silo can result in extra costs in the other. The taylorism way of working is therefor no longer rewarding. Taylor had some ideas of improving efficiency in production systems which we massively copied and still use. His idea was to improve the productivity by improving the efficiency of each process step; how would the world have looked if he had chosen effectively instead of efficiency?

What do we mean with silos? Silos are people of the same expertise put together. Put together in teams to build a small piece of the end product. Silos result in many handover moments. To reduce those moments factories implement assembly lines. Software development is a creative processes and it cannot be put into an assembly line model (no matter how hard we squeeze). How can we get rid of those silos and improve our effectiveness?

1. Product focus

Instead of focusing on process optimalisation we should focus on delivering a product that a customer is willing to buy. Our responsibility is to deliver that product with enough quality to satisfy the customer. A team should be focusing on the customer and only deliver what the customer needs.

2. Merge expertise

We merge expertise in a team, so one team is responsible for all the work done on a product. Including development, testing and maintenance. No single silo of experts remains, this is important. Of course there are experts, we just need to know where to find them. This will result in no handover and no waiting moments between teams, but it implies a lot! 

We need to know what work team members do, we need to learn, we don't have to ace it but we need an understanding how stuff works. In a DevOps team we need at least 10% time reserved to learn, just to keep up, learn and share.

3. Transparency

In order to find the right people for the job, we need to know from each other what we do. So instead of working silos, we have silos of knowledge sharing. We organise teams around products and customers, we gather to share knowledge.

4. Responsibility

With creating a team of mixed expertise around a product and its customers we are getting more responsibility. The teams makes promises, it needs to deliver, they are expected to keep up quality. Getting more responsibility means even more learning, the teams will be small companies inside the umbrella of a big one. The big one shares vision, mission and strategy. The team will follow the strategy, but gets its work from the customers. This also means that managers get less responsibility about the product, but more about developing team expertise.

5. Autonomy

All this results in autonomous teams that are capable of delivering quality and value to the customer through a product. 

By removing silos an organisation will change significantly. Work will shift and change. Teams will be in the lead to deliver customer value. DevOps has even a bigger impact on management comparing to teams. Teams know about software development, testing and operations. Management needs to learn to let go, to inspire, to share and to help removing impediments.

Do you still work in silos? What is the most difficult thing you are experiencing adopting DevOps?

Five capabilities of a successful DevOps team

So you have gathered developers and operations and put them in a team, voila DevOps! Or not? What kind of things does a DevOps team need to know to be successful? Are they developing safe software? Let's see.

Metrics

A DevOps team needs to measure everything, they are responsible for everything, so they need to know about performance. Performance of the application they are responsible for. Performance of the team to be able to improve. And performance of their delivery of value to the customer. Here are some basic metrics I think are important to measure.

• Lead time of a change: how long did the change live before it was put into production?
• Mean time to recover: how long do most outages take to be resolved and availability is restored
• How predictable is the team: prognosed work / delivered work (the closer the numbers, the better).

Security

A DevOps team owns the security aspects of the application, no one else is responsible. Things like static code analysis, OWASP Top 10, basic thread modeling and service accounts should be understood.

Testing

Testing is not the job of one person in a DevOps team. All disciplines must have a fair understanding and even an implementation of testing. Think about the testing pyramid and accompanying strategy. Think about unit testing on at least all new functionality. And least but not last; knowledge of disaster recovery or use of chaos engineering.

Transparency

Being transparent as a team means to show what you do and what you didn't do. It is about communication with all the stakeholders, including the DevOps team itself and management. A visible backlog and open review sessions are key to transparency.

Learning

In order for a DevOps team to be successful and stay successful they need to learn. While the world keeps moving, a team cannot stand still. Any lack of learning will result in a form of debt. New technologies appear, team members can change, the organisation will change and dependencies change, just to name a few. DevOps teams actively need to learn and develop their skills as they do their applications.

This is just the tip of the iceberg about what a DevOps team needs to be able to do, there are many more. But on a basic level you need to understand and own the above. With an increases autonomy that comes with being a DevOps team also comes more responsibility of doing the right things right.

What are the most important capabilities for your team?

Kano vs WSJF

How do we decide what to put on the top of the backlog? How can we prioritise one story over another? I have seen many different ways, here are a couple:

1. low hanging fruit: pick the easiest items that can be solved fast. These are not always the most important ones and can lead to technical debt or dissatisfaction of the customer.
2. The loudest yeller: in a group, there is one stakeholder that yells the loudest about their item, silencing the other stakeholders. This leads to a dishonest balloting of items and doesn't put the most important items first. 
3. The managers priorities: in traditional or hybrid organisations that are adopting scrum, managers are about people and projects. This can lead to managers making priorities instead of the stakeholders or customers and thus not delivering the most important items first.

So how can we do a better job? I want to mention two: the kano-model and WSFJ.

Kano

The Kano model is an approach that prioritises stories based on customer satisfaction plotted against functionality.

• In the left top customers is the functionality that brings excitement to our customers. If you invest in those, your customers will be delighted. Mind that not implementing these doesn't lead to customer dissatisfaction. A minimal viable product will not include these functionalities.
• On the right bottom are the basics for the service to work. These are basic functions which are taken for granted. Customers won't be satisfied by these functions, but will become very dissatisfied if they are not implemented.
• And on the top right are the performance functions. The more you invest in these functionalities the more the customers like it. The better the performance the happier the customer.

You can read more about the Kano model on the website of ProductPlan: https://www.productplan.com/glossary/kano-model/

WSJF

WSJF is an abbreviation for Weighted Shortest Job First. I came upon it during a SAFe course. It is based on the idea that we can weigh stories on importance and work and get the most economic benefits. For WSJF we need a bit of simple math. First we need to find out what our CoD (Cost of Delay) is. So how much money will we loose when we don't implement this functionality? We plot that against the job size with the formula: WSJF = CoD / Job size.

It is easiest to make a table with all the functionalities or stories or stuff you want to make, add a column for size, CoD and weight (which is CoD / Job size). After plotting this in the table, the item with the most weight is the most important to implement.

You can read more about WSJF on the SAFe website: https://www.scaledagileframework.com/wsjf/

How do you do your estimations? Which model do you prefer and why?

Five signs you know you are working in an agile team

Working agile is more than just a daily standup, but you knew that already. What are more distinct features of working in an agile team? Here are a few of them.

One: everybody is a developer

Everybody in the team has the same goal: getting stuff done. The distinction between your job and that of you peer is fading as you progress to developing stuff that works for your client. Everybody in the team shares the same responsibility. You do refinement together, work together in a peer setting most of the time. You share knowledge and you even take over from other disciplines in the team.

Two: you are the A-team

The team is more important than its individual members. You avoid local heroism with people that know it all. The best hero is the one that shares the way stuff is done. A hero is the one who shares most and educates the team on development principles. A hero helps all team members in getting a better performance so that all members become hero's. 

Three: reflection together

Reflection is done with the team. Together you reflect on what has been done in the review, feeling proud of what you, as a team, have achieved. You inspect what you failed to deliver and know what you need to change to do an even better job next time around. With the team you inspect how you are working and come up with things that increase your performance as a team and as an individual. You do peer reviews to inspect each other in an honest way so you learn and are able to improve. This implies no functional reviews by managers as well.

Four: dashboarding

As a team you use dashboards to make performance visible. Just like you use a dashboard in the car to read out speed, fuel and overall car performance. You have stopped sharing status in the form of reports or meetings. Reporting the old fashioned way has no added value to the customer. If anyone in the company wants to know how your team is performing they come to reviews and ask.

Five: working on products

The most important indicator of working in an agile fashion is perhaps that it is focused on products instead of projects. Your team works on a product with a distinct customer base. You and your team are solely responsible for the product and its success. A project is timebound while a product is customer bound.

What are the most important indicators for you? Please write them down in the comments.

Make it smaller

To learn faster, to deliver more value and to have a better general performance we need to make stuff smaller. Little stuff is easier to oversee than big stuff. Small problems are easier to fix than big problems. What can we make small in our work to make our work easier?

Shorter sprints

The shorter our sprints are, the more moments of inspection are available to us to learn and improve. A sprint is between two to four weeks according to the Scrum Guide. We don't need to adhere the framework here, if we can improve faster by shortening our sprint, we respect the framework as well. There are teams that run weekly sprints, and some even run shorter ones. A shorter sprint will provide more inspection moments and thus result in faster learning through more inspection and adaption moments. Because all events (except the standup) are relatively sized to the sprint, it will not consume more time.

Smaller PBIs

The smaller our product backlog items are, the faster they can be build and delivered to the customer. We get more revenue and more feedback. PBIs or stories are sometimes really big, they tend to have epic proportions. An epic PBI is one that can not be overseen or fixed in a certain amount of time. For most teams any story that takes more than three days to fix, the story should be considered an epic. So cut up the story into smaller chunks, make them independent of each other and smaller than three days. This might be hard at first, but practice makes perfect; think about the smallest possible change that might work. 

Less hierarchy

Hierarchy makes stuff complex. Hierarchy results in interdependence of PBIs, while we would like to have PBIs that we can resolve without any relation to another change (check the INVEST acronym). So an epic PBI, which is a PBI of epic proportion (and nothing more), should be made smaller. This will result in a couple of independent stories and the original epic story should end up in the trash. There is no added value in the original epic and it will only clutter the backlog with relations between stories that are useless to the outcome, because it's redundant.

There is another form of hierarchy, which we experience daily, that can decrease our performance as well. This is organisational hierarchy. The more autonomous a team is, the faster it can make decisions and learn from its mistakes. In a hierarchy people that don't do the work are made responsible for that work. Weird isn't it? Responsibility and autonomy go hand in hand. Make teams more responsible for their work in giving them the authority to make decisions about their work. Scrum solves this problem with two accountabilities: the Product Owner is made accountable for the work, the Scrum Master for the performance. 

Shorter meetings

I hear a lot of people complain about too much meetings, and too long meetings. I help them reorganise their agenda by skipping meetings that don't add value or performance. 

From a Scrum team perspective there are a couple of meetings: the daily; in which progress towards the sprint goal is shared. There  is refinement; in which stories are scrutinised with stakeholders until it is clear which work needs to be done. Each sprint there is a review, a demo and a planning session in which is talked about what is being or going to be made. And there is a retrospective in which the team introspects how it does the work. 

No other meetings are needed!

Many people find themselves in a hybrid form of Scrum with archaic roles and responsibilities in which they are obliged to attend some meetings. There are three types of meetings: informational, decision making and cake. The informational are most of the time unimportant and could be done with a memo; when you are invited think about what you are going to get out of the meeting and decline if it is not enough. It is no shame to not waste your or anyone else's time. The decision making meetings are a bit more important but again, choose to go if you think you can gain something by attending. In the meeting, steer towards decision making and go when done. A one hour meeting can mostly be shortened to half an hour by this approach. The last meeting is the cake meeting, this is the fun meeting, this is the one you should always attend!

To summarise: make everything smaller. Small work items, short meetings, less hierarchy and short sprints. This will increase performance and added value. Sometimes it needs a bit of courage when you need to make choices. But it is worth it. 

Let me know in the comments what you do to make your work smaller.