International DevOps Certification Academy™
How Should You Enable Your DevOps Flow?
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.
Define a Mission for Your DevOps Transformation
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:
- 75% reduction of average lead time from code check-in to live production systems in 3 months.
- 33% reduction of average lead time from request to live production systems in 6 months.
- 50% reduction of number of production incidents in 12 months.
What is Value Stream and Who are Involved in Your Value Stream?
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.
Build Your Value Stream Map to Find Out the Improvement Potentials
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.
DevOps Value Stream Mapping Example for Software Engineering Process
(which presents significant improvement opportunities to enable faster flow)
Eliminate Handoffs, Constraints and Waste As Much As You Can
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:
- You need to challenge the duration required for each handoff. For instance according to above value stream mapping example, it takes 80 hours until a successfully tested code is picked by deployment team. Why is this like that? Can’t we automate this process? Of course we can.
- You need to eliminate the waste caused by repetitive handoffs. According to above value stream mapping example, test team hands off 65% of features back to the development. Fixes for some defects need to be delivered up to 3 times until they are approved by testers. Couldn’t we speed up these iterations by enabling better integration between development and testing teams? And high number of defects show that something does not optimally function for your development team. The reasons of these quality issues need to be identified and sorted out.
- You need to challenge and remove handoffs as much as you can. According to value stream mapping example above, once a request is refined, it takes 320 hours until it is processed by signed-off authority. Why do you need such a sign-off authority in your organization? What is the value of this authority for your value stream? Has this authority got sufficient level of information and vision to give a good decision? Why doesn’t this sign-off authority become part of request refinement team, so it knows far more better about what is being signed-off and there will one less time-consuming handoff which takes 320 hours. Unless you remove constraints and barriers which slow down your flow, you can’t really expect much from DevOps.
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.
Make Your Flow Visible for Everyone
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.
DevOps Kanban Board Example
(from Design to Development and Operations)
Limit Batch Size and Work in Progress
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.
Use 20% of Your Time to Reduce Technical Debt
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.
CONCLUSION
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.
DEVOPS-CERTIFICATION.ORG
