The horror of the standup

I hated standups when the team I was in started with Scrum. It was disruptive for my work, and we just answered the famous three questions and did nothing with it. It was just a status meeting. It was a daily chore that went fairly quick, so I thought it was more a coffee break than something useful. 

My standard answer each day was about the same:

• SM: "What did you do yesterday?"
• Me: "I worked on PBI x"
• SM: "What are you going to do today?"
• Me: "I'll be continuing my work on PBI x"
• SM: "Anything that impedes your work?"
• Me: "Nope"

This useless conversation made me resent Scrum. Until I actually opened the guide (when it was still more than the current 18 pages) and read about the purpose of the standup. It was not about those three questions, it is about making a plan for the day. It is about what the team is going to do in the next 24 hours to come closer to the sprint goal. It is a support meeting that promotes collaboration. Who is going to do what, to what purpose and who are helping each other to get things done. The questions are only there to support the definition of the daily goal, but are interpreted wrong. I guess that's why they removed the questions all together from the Scrum guide.

After this realisation I changed the way I do standups, they actually help me to get things done. I coach many teams and this is how I teach them to get more out of a standup.

1. Reorganise the board: the lanes are used for the PBIs. Don't order it by team members. But order it by PBIs with the most important ones on top, the least important ones on the bottom.
2. Make the columns as simple as possible: Todo, Doing, Done is more than enough.
3. Start at the first item that is not done and discuss with the team what can be done today to finish that item. Focus on making pairs to make sure the item is finished in the shortest time possible. At least two or three people should be working on the same PBI.
4. Check for anything that will impede progress on the PBI and make that the teams highest priority to solve.
5. Take the next item on the list until you run out of team members.

After changing a standup like this, I have found out that people value the standups more. Most of the time the standups took less than the allotted 15 minutes. And as a result the teams collaborate more, have better knowledge sharing, and they got more stuff done. 

 

How should we use metrics in DevOps?

At DevOpsDays Amsterdam I joined an Open Space about metrics. It was very interesting to hear that some companies make the use of DORA metrics mandatory. For those unfamiliar with these DORA metrics I will explain.

1. Mean Time To Recover (MTTR): the amount of time it takes to restore a downed service
2. Change Failure Rate (CFR): how many changes to production cause outage
3. Lead Time (LT): How much time does it take to bring a change from inception to production
4. Deployment Frequency (DF): how often can you deploy a change
5. Availability (A): what is the uptime of your main process from a users perspective

These metrics are derived from teams in a great number of people in companies (about 33.000) via a survey. It is important to note that these metrics are just a subset of what is possible to measure. Which means that they might not be best suited for your own situation. Teams in organisations should select metrics based on the goals they want to achieve. Metrics can therefor differ from team to team. Each team is responsible for their own metrics and it is crucial that they regularly reassess the metrics they use.

In the workshops I do with teams about metrics I explain the most important rule: metrics are owned by the team. No one outside the team should decide which metrics to use. You see that I struggle with the mandatoriness of metrics. Because metrics can help increase performance in a team, they should be in control of the metrics, they should use it as a learning mechanism.

Metrics should also not be used to compare team performance between teams, especially not from a management perspective. This will kill the dialogue between the team and the leaders that should facilitate them in growing. Discussing team metrics with a leader is good; they can understand and help a team remove impediments and grow. Comparison leads to competition, competition leads to selective development of capabilities and will most probably result in improvements on the measured items, which are not necessarily the items that the team needs to improve on.

As Peter Drucker said: "What you measure improves". In other words, if you know where you want to improve, start measuring. Just measure what you think will help you improve. There are a couple of things to bear with you. First of all think of the possible side effect of the metric, how you can cheat it. For instance: measure velocity of story points to see how much work gets done. This sounds like a great metrics, but can easily be cheated. The increase in story points will not guarantee more delivery of work. It might be the case that stories just get more points; thus cheating the metric. 

If you define a metric, you should also define a goal where you want to be with that metrics after a certain amount of time. Don't go for 100%, that will be demoralising, set achievable goals.

What kind of metrics might be useful to a team? Here are a couple metrics you might want to use.

1. Mean Time to Detect (MTTD): It measures the average time taken to detect issues or failures in the production environment. A lower MTTD indicates effective monitoring and alerting systems.
2. Mean Time to Resolve (MTTR): It measures the average time taken to resolve issues or failures once they are detected. A lower MTTR indicates efficient incident response and problem-solving capabilities.
3. Change Failure Rate: It calculates the percentage of changes that result in incidents or require rollbacks. A lower change failure rate indicates a higher level of stability and quality in the software delivery process.
4. Test Coverage: It measures the percentage of code or system coverage by automated tests. Higher test coverage indicates a reduced risk of introducing bugs and promotes code reliability.
5. Customer Satisfaction: This metric captures customer feedback and satisfaction levels, indicating how well the delivered software meets customer expectations and needs.
6. Infrastructure as Code (IaC) Compliance: It measures the percentage of infrastructure managed as code and tracks adherence to infrastructure automation practices.
7. Team Morale: While not directly tied to technical metrics, monitoring team morale and job satisfaction can provide insights into the health of the DevOps culture and its impact on productivity and collaboration.

My favourite metrics are the following:

1. Predictability: this is a percentage of estimated story points versus delivered story points. It tells you how accurate you planning is. Measuring predictability will improve refinement, planning and the discussion of too much work on the sprint log. It also reduces unplanned work. In other words, how well do you understand changes on your product.
2. Availability: how available is my product to the user of the product, this is measured from outside the organisation to simulate real users by running the main process of your product. This metric gives direct feedback on how the user is able to use your product.
3. Technical Debt: how much time do we need to resolve all technical debt (you can use SonarQube for this). Technical debt will accumulate if you don't act upon it. It suffers from compound interest and will eventually block any new features. It is very important to get a grip on Technical debt and as a general rule you should always keep it below 40% of your total work.
4. Age: what is the age of PBIs / Stories / Issues on your backlog. Stuff that is on the end of the backlog will probably never get done, or are total irrelevant when they are up. Define the maximum age of items and throw away stuff that is older. The odd thing about things you throw away is that if they come back, they will come back better (new insights are added, they are updated to the latest specs)

I have found these four metrics to help increase team performance more than the first four DORA metrics.

The big sidenote here is that it's up to a team to use them. They can remove or add metrics to this list. When I start with metrics in my teams, my first goal is to define one to three metrics to start with. Each retrospective we inspect the metrics and adapt. This means we are going to focus on something to improve. Which can result in modification (change description, measurement, KPI) or adding a new metric.

To conclude, metrics can really help you to understand the work and your performance. Metrics should be defined by the individual teams, they should be visible to everyone and are modified when needed.

What kind of metrics do you like to use with your team?

Why don't we have enough time?

 

Time is relative, there are enough sayings about this phenomenon. Time is important to us. Saying we don't have time for something means a lot more than just time itself. What are the reasons we don't have time?

1. No priority: the thing we need to do has no priority over other things. Or we think other stuff is more important than the thing we need to do.
2. No benefit: the thing we need to do doesn't benefit us. It has no gain in any aspect, be it money, time or anything else.
3. Angst: we fear the thing we need to do or the result it brings.
4. No dedication: we are not dedicated in doing the thing we need to do. The result would be sloppy.
5. No motivation: we are not motivated in doing the thing we need to do.
6. Too much work / overflow: it is too much work, our list of things to do is overflowing
7. No challenge: there is no challenge in the thing we need to do, it will be boring work, or we will not learn anything new
8. No fun: the work is not fun. If it's no fun, there is less motivation to make quality things
9. Too complicated: it is very hard to achieve the thing we need to do, work should be made simpler.
10. Not relevant / unnecessary: the thing is not relevant to us, we don't identify with the problem the thing should solve. It might feel unnecessary.
11. No vision: there is no vision about the thing we need to do, no higher purpose.
12. Fear of change and failure: we fear the change the thing we need to do brings us. We fear it because we can fail and feel punishment.
13. Not interested: we are simply not interested in the thing
14. Irresponsible: if we would do the thing the results would be irresponsible

Note: if you have any other reasons, feel free to add them in the comments.

So how should we change the thing we should do to have it done? First of all, the end result should be clear, there should be a vision and relevance about the work so the thing becomes important and can be prioritised. The thing we need to do must be described simple, the solution might be complicated, but the description should be clear and simple. It has to have some kind of benefit like fun, money or knowledge and it mustn't bring punishment with failure.

For example. Vacuuming the house is a task with a simple description which might work out very complicated when you have a couple of teenagers, some pets and things laying around the house. Vacuuming has enough  benefits like health and ease of mind when everything is tidy. It might also be fun when you use a nice vacuum cleaner.

TL:DR whenever somebody says that they don't have time for something. It is always another reason, find out that reason and fix it to get stuff done.

No time

There is never enough time. Every successful company has more work than they can handle. There is no problem in that, it is more a luxury problem. Except when you can't handle it. A lot of work can lead to stress and stress leads to suffering. You can work harder, make more time (time is relative) and try to go faster but that depletes resources in no time. There are a couple of common pitfalls we see that leads to too much work and no time to do it. Let's have a look at those and find out how we can resolve this issue.

The loudest customer

First of all there is the situation of the loudest customer. That is the customer that screams the hardest and makes the most emotional impact on the introvert engineer. The engineer feels threatened and will try to make this go away by implementing the change as fast as possible. We can mitigate this by denying direct contact between engineer and customer and place a product owner in between them. PO's are more extravert, they manage the backlog and can do politics with customers, shielding the engineer in the process.

The most persistent customer

Besides a loud customer it is also possible there is a very persistent customer, who doesn't play on emotion, but will frequently contact the engineer or PO for a specific change. Because it is impossible to do all the things at once, prioritizing is the solution. We call that prioritization the backlog. A PO is owner of the backlog and plays all the games with the customers to order the items on the backlog by importance or business value. With a persistent customer the PO can forward the customer to the backlog.

The helpful employee

A helpful employee sounds good, but too helpful isn't good at all. When the employee helps the customer, and make them happy, they don't work on the backlog and are thus not working on the most important items. They dissatisfy other customers who's work has been planned and possibly delayed or not done. A team should deny working on anything else than what is on the backlog, forwarding the customer to the PO to negotiate a spot on the backlog.

The planning PO

In many occasions PO's assign work to engineers in the planning session. They focus on efficiency instead of effectiveness by doing this. Which means that everybody is busy with individual work, forgetting about sharing, building knowledge and most importantly they forget to put the team in control. Work should be ordered by the PO in the backlog. Engineers pick the most important item during the planning of the day and form a team to build a solution to that particular change. More than one engineer is working on the same change, ensuring quality. This way of working focusses on effectiveness and getting things done.

The important manager

Oh, how often have I seen managers walking into a team room and sorting out one engineer to do something for a particular customer completely skipping the product owner, any agreements, any priorities. The engineer will not say no to a manager (most of the time). This form is very disruptive and undermines the position of all team members, the product owner and the scrum master. Modern leaders should facilitate, not delegate. Solve this by coaching managers into a role of servitude; great leaders serve the team.

Feature driven

Nowadays most teams are setting a step from agile to devops, by incorporate run into their daily work. This means teams need to reserve time for maintenance, housekeeping and incidents. Too much focus on developing new features will result in an increase in technical debt. The more technical debt is acquired the slower development of new features will get, ultimately grinding to a halt. Reserve time for maintenance and incidents and keep technical debt to a minimum to ensure flexibility to build new features.

SPO(F/K)

A single point of knowledge is a huge problem. Engineers with a lot of knowledge in a team with less knowledge, are busy doing all the work while some team mates sit idle. Forbid any engineering work for this kind of people and make them teach and coach until the rest of the team is up to par.

In summary, get PO's in place to handle the backlog and set priorities fencing off customers and management. Forbid working from anything else than the backlog. Let the team plan. Share your knowledge.

About the importance of LCM

Life Cycle Management is about keeping your assets up to date. When systems are not up to date they tend to create unplanned work in the form of incidents. Unplanned work means we cannot deliver business value that we promised to our customer. Teams that don't have grip on maintenance are going to be reactive and fix assets when they are broken. The cascading effect of not having systems up to date can be big. It can even result in so much technical debt that your team cannot work on improvements and is dead locked in maintenance.

The first step in overcoming reactive maintenance is to plan it, and reserve resources for it. Each new feature that is developed by a team will result in extra capacity for LCM. Keeping a healthy balance on maintenance and new features is important to keep quality of work on an acceptable level. Unbalanced LCM can lead up to 90% of time spent on maintenance, reducing to amount of time that can be spent on delivering new business value.

To get a grip on LCM it is advisable to create a year calendar that shows when assets need to be updated. This includes hardware, software, licenses and certificates. For all those assets the current version needs to be know and the current available version. The current version doesn't need to be the latest and greatest, it needs to be a recent stable version with all security updates. Alas, the newest version can break your systems sometimes, so be alert on running the newest (n) or the one before the newest (n-1).

When you have the basic information start extrapolate on the history of the versions from your assets, nine out of ten times you can find this information on the asset providers website or in a changelog. Plot out in cadence the upcoming versions. 

Now we have a view on all the LCM work that needs to be done in the upcoming year. The next step is to calculate the workload on the items and get a grip on the time needed to maintain the assets. The calculation is just a sum that you and your team predict for what is needed to perform this maintenance. You end up with a table of all the assets, the predicted maintenance dates and the manpower that is needed to perform that maintenance. All maintenance can now be planned in the correct timeslot you use for planning, be it sprints or months for example.

The collected LCM information can be feed back to any roadmap plans to make realistic planning on upcoming sprints, months or quarters. You just made LCM planned work instead of unplanned or reactive work. 

Working together

Once there where two kids next to each other, playing with toy cars in a sandbox. Their parents were in joy because they saw their kids playing together. But where they? The kids played with their own toys in their own patch of sand. They didn't play together, they just played next to each other.

A couple of years later, the kids sat in the sandbox again, but this time they shared their toy cars and build a road in the sandbox. Now they just didn't sit together, they were actually playing together and had a lot of fun.

Most teams work together as the little kids in the story, they don't actually work together, they just happen to be in the same team. They pull their work individually from the worklog. They are just individuals sharing a desk space. Each morning during standup they tell each other what they did, and no one has a clue about what it exactly is they have done or they don't care. 

Some engineers put their name on a couple of items to claim them as future work. When they have one item done, they move on to the next. Others finish their work and pull stuff from the backlog into the sprint because there are no free items to work on. See where this is going? Not everything the team committed to is done but extra stuff is delivered as well. This doesn't fall well with stakeholders.

What can we do about it? First of all no team member can have more than one story on their name. Second, in the daily scrum we talk about the work that is on the scrum board. From top right: the stuff that is almost done, to bottom left: the stuff that still needs to be done. We ask ourselves: "What can we do today to finish this story". Then we ask if anyone wants to help finish it, together. As we progress through the stories in the end we run out of engineers.

So now we have at least two engineers on one story. We need something to enable us to work together. The idea is that everybody participates in fixing the story. We use pair or mob programming to accomplish this.

With pair programming there is a single driver behind a computer and there is one or more navigator who sit close to the driver. The driver is just inputting in the computer, they put in their implementation. The navigator(s) talk about the problem and try finding a solution. Every once in a while the driver switches with a navigator.

When we use this setting we can skip peer review, we are peering the whole time, so there's no use for that. Because more brains have worked out the solution it is of better quality which result in less incidents. And most importantly we shared knowledge and learned from each other. 

Below are a couple of resources to have a look at, the first is Stacy who talks about pair programming, the second is an article about mob programming on medium.

Stacy Cashmore: How to really work together as a team

Sam Fare: I did mob programming every day for 5 months.

The cascading effect of the DevOps way of working

When you are going to work in a DevOps way it all starts with removing the first silo. This means removing the wall between Dev and Ops by putting them together in a team. The consequence is that the whole team is responsible for change and run. When the whole team becomes responsible, no individual can fall back on their role, they are all committed to the cause. Dev can do Ops, test can do Dev, Ops can do test and Dev and so on. This means more collaboration in the team and less push off of work to another role. As a DevOps team you are all in it together.

Working together is only possible if it is done in a small team, and with a small team I mean no more than five engineers (I like to call all team members engineers and not by their role). I state a team of five is the best, a team of three is minimum. With five it will still be a team, with six it will become two teams of three. Six or seven is still possible but communication and therefor collaboration will become increasingly harder. 

If you have smaller teams, you also need smaller software components and with smaller components you need more interfaces. These interfaces are twofold, one is the technical one with APIs, versioning, release cycles and so on. The other is the communication interface. How do you, as a team, communicate with other teams, how are your dependencies organised? You need to think about hard and soft dependencies and come up with a plan. Hard dependencies are those that make your team wait for work from another team or individual. Soft dependencies are those that interface with another team but don't require any work from another team. One of the goals for a DevOps team is to lessen hard dependencies and turn them into soft ones. This can only be done if it is clear who your teams customers are, which is one thing the team should know and investigate.

Working in a small team means a lot of collaboration, you need to share information and to improve sharing it is wise to minimise the work in progress by introducing a WIP limit. A WIP limit is a limit on the amount of work that can be in progress. If you need to learn a lot, make it a low number, so all team members need to work on the same thing together. One of the most errors I see is that every engineer works solely on items of the backlog not sharing knowledge and information. When two engineers work on the same item, they need to communicate and explain what they are doing, teaching the other one about their ways and maybe even learn something themselves.

It can happen that an engineer can't collaborate and that the WIP limit is reached. The purpose of DevOps is not to be as efficient as possible (max. resource utilisation) but to be as effective as possible (max. customer value). This means that when an engineer isn't working on items on the backlog, they should investigate improvements, refactor or learn.

Investigating the way of working and finding new ways to work leads to better processes and automation. When a DevOps team starts automating, many quirks in the process will be found. By solving these the quality of work and the speed of work will increase. 

So what are the steps to take?

1. Form mixed teams with the disciplines needed to convert customer requests in a usable product or service
2. Find out all the dependencies of the team
3. Make communication plans with other teams, technical and social
4. Introduce WIP limit to increase learning
5. Automate

Let's start doing DevOps!

Why we do things in Scrum

We do daily scrums by answering the three questions.
We give a only a demo in the review.
We skip retrospective.
Planning is distributing tasks
But we do Scrum.

That is not Scrum, that is doing what we do in another form. For me the basis are the three pillars: transparency, inspection and adaption. Every event in Scrum is based on these pillars. 

Take the standup for instance, it is transparent because everybody is welcome to attend and the work progress is made visible. It is a moment to inspect the work for that day and come up with a plan to deliver stuff. It is a moment to adapt the way we are organized to get things done. 
I can't withstand those annoying questions: what did you do, what are you going to to and do you have impediments. The result is somewhat in the area of: "I did x yesterday, didn't finish so I continue on x today and I need to visit the dentist". We are not interested in your status or your agenda. At a standup we are inspecting if we get work done. Nothing about the individual, all about the team. So stop with those questions! One approach you can use is to talk about the work items on the board. Go from almost done in the top right corner, to stuff that can be started in the bottom left. Ask yourselves: what do we need today to get the top story in the done state. Don't make it individual work, but group up to finish the work. Find a way to finish it, then move to the next item on the list until you run out of team members. The work on the top is the most important, so it is also very important to finish it first.

Next on the agenda is the review. A review is a key moment to talk to the stakeholders, inspect the work that has been done, agree on the next goals. You can do a demo if it adds to the experience of the stakeholder. But most important is that you talk about what needs to be done and what you need from each other. Offer insights in work, show metrics, ask what the stakeholder needs and measure. Become predictable. Stakeholders don't need status updates or reports, they want to be involved and this is the moment to do that.

Then comes the retrospective. Most teams draw a boat or a racing car and talk about what is slowing them down and what can speed them up. It's a nice exercise, but it doesn't get to the point of the retrospective. Where the review is about what we do, the retrospective is about how we do it. What is our way of working, are we a team, can we trust each other, what can we do to improve flow and focus. In the retrospective you inspect and adapt on the way you work as a team.

And the last event in Scrum is planning. In this event we don't distribute tasks, we inspect our parameters. What capacity do we have, how does that relate to our speed of delivery and how much work can we take on. Is there any unplanned work we need to take in account? What stuff are we not going to do. Can we finish all the work and be predictable? So we inspect the work load, we adapt our forecast and we publish our sprint log to make it transparent.

We've talked about four Scrum events and how they relate to the pillars. Transparency is needed to build trust, inspection is needed to learn and adaption is needed to improve.

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.