In DevOps, Flow means end-to-end manufacturing chain of software from idea to running lines of codes in your production systems. You and your DevOps teams are in charge of building and sustaining a reliable, consistent and fast flow to meet and exceed your organizational goals and to outcompete other products and services in your particular market.
After you have your DevOps team in place, the next step is to define a mission. Only by having a common mission, your team will be equipped to correctly function. Without a mission your team will never be able to prioritize the critical work and distinguish showstoppers from errands. The mission should be challenging and impressive, but it still needs to be achievable in a given timeframe.
A mission should be tailored for your own DevOps team. It is based on organizational characteristics, challenges and objectives to serve internal and external clients interacting with your DevOps team.
Some example mission statements to get your DevOps transformation started can be:
In order to improve your work, you need to know your value stream. A value stream in information technology systems is a sequence of activities required to design, build, and operate a specific software product and service. Furthermore, a value stream defines human resources, knowhow, utilities and materials which enable the value stream to flow.
In a complex organizational structure, no one is fully capable of identifying an end-to-end value stream. Therefore, it is important that all members of your DevOps team, stakeholders, providers, client representatives, if possible your clients themselves should participate to identify your value stream.
A value stream map enables you and your DevOps team to visualize how a typical work in your software development and delivery organization is performed. By building a value stream map your goal is not to make a comprehensive documentation about each and every step to get your work done. Your goal is to gain sufficient insight about your typical workflow to identify where major inefficiencies, constraints, issues and waste of time and resources lie.
When software development and operations engineers for the first time sit together and build a value stream map, it is usually the first time for an operations engineer to comprehend the negative effects of misconfigured database servers without table spaces on development teams. Similarly, it is usually the first time for a software development engineer to see the consequences of delivering software without built-in monitoring, availability, testability and configuration features.
Some of the most significant, but overlooked factors of efficiency are handoffs, waste and constraints. When an activity is handed off from one team to another it requires signalling, requesting, scheduling, prioritizing, deprioritizing and resolving conflicts.
When a work is passed from one team to another, each handoff will not only result in loss of information, but it also negatively impacts overall lead time of your value stream.
To overcome these problems:
DevOps expects you to ask such questions to break the status quo. Not everyone in your organization will be of course happy to hear such questions. But you are already prepared for this.
In order to make sure that your work flows from left to right, and your DevOps organization accomplishes its goals, you need to have tools and mechanisms in place which make your flow visible. In information technology business, it is a matter of a mouse click to assign a work from one team to another in your value stream. However, due to incomplete work, inconsistent dependencies and misunderstandings, it is part of your daily business that your work bounces from one team to another (so called “one step forward, two steps back”) and it flows too slowly if it flows at all.
Therefore, it is important to make sure that your flow is visible. Not only for your team, but for everyone. DevOps relies on Product Backlog, Sprint Planning Backlog and Kanban boards to visualise flows. These boards do not only involve the works (tasks) which belong to your own DevOps team, but they should also make the entire flow visible from the idea conception of your products and services to operational maintenance and end of life. In this way, whenever a work doesn’t flow, it will be quickly visible for everyone. And it will be the joint responsibility of everyone to remove roadblocks and impediments to enable continuous and successful flow of your work.
Research conducted at Stanford University found that multitasking is less productive than doing a single thing at a time. The researchers also found that people who are regularly bombarded with several streams of electronic information cannot pay attention, recall information, or switch from one job to another as well as those who complete one task at a time.
What does this mean for your DevOps team? It means that you need to reduce work in progress and limit the batch sizes of your code deliveries. As an illustrative example: Your team can have maximum 6 work in progress tasks in development to avoid continuous context switching and enable full focus on work at hand. Alternatively, you can estimate each task with a story point weighted by Fibonacci numbers (0, 1, 2, 3, 5, 8, 13, 21, 34, ..) and your DevOps team processes up to a certain total number of story points (velocity) in a given timeframe (sprint).
Beside increasing quality and productivity, by limiting batch sizes of deliveries, you will be quicker to identify root causes of issues and resolve them. Once a task is finished, you will check it in your common code repository, validate it with your continuous integration platform and subsequently deploy it in your production. As the batch size is small, identification of production issues due to code deliveries will be easier, potentially required rollbacks will be less cumbersome. Furthermore, by continuously delivering in production, your team will have the constant pride of contributing your organizational mission. We will leave this to you to compare this mode of working with morale, motivation and technical challenges of teams who build their codes for 8 months without delivering one single line of code to their production systems.
When your organization doesn’t reserve time to reduce its technical debt, but continues building workarounds on the top of workarounds, it will come to a point where all engineers spend all their times to fix issues. In financial analogy of debt concept: Your organization will be only paying debt interests.
In this chapter we covered for you what value stream and flow in DevOps are, why they are important and what you do to make your work flow in value stream.