I have previously covered what DevOps is, there is a greater question of whether or not DevOps is a good thing or not. I believe that DevOps can help but may not be for every working environment or organization.
I was working with a team recently on a proposal to help a customer who wanted to implement a DevOps and service catalog framework. One of the team members sent me the Statement of Work (SOW) and it had a few objectives and associated goals and tasks. All in all a very nice representation of an SOW for project related activity. What it wasn’t though or at least not in my opinion was an implementation of a DevOps model.
We went back and forth via email on what DevOps is and what first phases were it went something like this:
Them: We are looking to do an application rationalization engagement and build out the hybrid cloud service catalog.
Me: But you said the request was to transform their teams to utilize a DevOps model of application and infrastructure management. That means we need to help them visualize the work they have in process (WIP), identify their workflows, and leverage the team mentality that will reduce deployment cycles and improve time to value.
Them: Right we are going to do that by showing them where their application workloads should sit.
Me: …
This back and forth got me to a point where I realized we might not have the best talking points when it comes to DevOps as a service delivery process. How do you help someone transform from a traditional silo’d IT organization into a DevOps short feedback loop powerhouse? So I started doing some research on implementing DevOps and Lean processes. I have been down the Lean Six Sigma training path before as well as ITIL certification courses, which made the material a little easier to consume. Everyone says that DevOps is about people and processes and this is so very true, but it’s about understanding the work and business need that’s what drives the changes in processes and should motivate the people.
How do we get started?
First step is someone needs to own the transformation: you need management buy in. This person is in charge of pushing back against the traditional forces of IT stagnation and that person needs top cover.
Once the owner is established they need to begin by looking at business objectives. What are the key initiatives the organization is trying to reach? What groups outside of the IT organization have these requirements and what do they need to meet the goals set?
With the knowledge of what the business needs\wants then it’s a matter of looking at what types of work are being done, and what the workflows are for each type of work. The process of work mapping has multiple steps. Most go like this:
Work Flow Mapping
Workflow (process) mapping is one of the fastest ways to lower errors, increase productivity, and affect customer service. It generally follows these steps:
1. Choose a process. You have to first decide what you want to improve. Some examples are the process of making reservations at a corporate travel center, handling a customer’s repair order at a car dealership, or registering students at a college. The best bet is a process which is time-consuming, error-prone, or critical to success; starting where there is a strong potential for improvement will build morale and help launch later mapping projects.
2. Assemble a team. Preferably, the team will include people from the lowest and highest levels directly involved in the operation, such as customer service agents, their supervisors and managers, and the head of operations. The team must be empowered (given the responsibility and sufficient authority or leeway) to make significant changes in the workflow.
3. Map out the way work is currently done. Diagram each step, showing decision branches, time spent, any distances traveled or people contacted, and other important aspects of the work. It is often be easier to sketch out the individual tasks first, then go back and fill in the details.
4. Identify problem areas. These are areas where people feel there are currently major issues to be resolved, such as poor customer satisfaction, “dropping the ball,” large expenses, or significant delays. Where there are many areas to choose from, try to follow the 80/20 rule: work on the 20% of the areas that cause 80% of the problems.
5. Brainstorm solutions. Identify all possible action steps for each problem area, without evaluating them.
6. Evaluate action steps. Set up a set of “final” action steps by group consensus.
7. Determine responsibilities. Figure out which groups or persons are responsible for each task and try to determine through evaluation the time it takes for them to complete those tasks.
8. Create a master plan. Summarize who has responsibility for what actions and the deadlines. Distribute the plan and make sure everyone agrees with it and that it accurately reflects the decisions made during the sessions.
9. Follow through. The meetings are useless without appropriate follow-through. Try meeting again every two weeks to see what went well and what did not. When the time is right, try having another brainstorming session. This is where having a detailed, clear, and well-communicated master plan is invaluable.
This has to be done for each process or workflow you want to include in your DevOps team portfolio. What that means is your DevOps team isn’t going to take on all of the work of your IT shop, a lot of operations will be left to traditional silo’d activity until you are able to prove the track record of the transition. Bite off what you can chew; maybe it’s a new project or software deployment process.
Use tools to make this possible, a KANBAN board is really helpful to visualize the tasks as they move from To Be Done through the Work process be it teams or checks to QA and finally production. Be sure to leverage collaboration tools to have the team talking and on the same page.
Once you establish the executive buy in, map the workflow and pic your projects you are ready to establish your team. Ideally you want to be all encompassing, during your workflow mapping you no doubt identified the stakeholders in your selected projects. Talk to the stakeholder managers and get them to commit their resources to the team. (Expect some who don’t buy in to DevOps to send you their B-team. Don’t worry if the process works you will be able to show where their department or team work constraints are from this.*) Make sure you have someone from across Ops (Servers, Dev, Storage, Networking, Apps, Monitoring, Helpdesk, Tech Writing, and of course Security). Identify to them in the kickoff meeting what the business goal is and what the business value of this new project will be. Explain the concepts of DevOps and show them the visual and collaboration tools they will use. Then set the first deadline (be reasonable you will see time to value gains over time). Make sure your team is working together and has daily goals along with weekly, monthly and final project goals.
After the project is complete be sure to run a post evaluation to get feedback on how the project was run and what can be done better the next time. Adjust your processes as needed and tackle the next one. Congrats you are now a DevOps team.
Hopefully this helps get you started, I am sure I will be writing more about this in the very near future.
*Note: Work Constraints can be a lot of things, it could be the tools by which a process is done, or that only one person holds the knowledge to complete a task. By identifying constraints you can mitigate their impact by automating tasks, or creating Knowledge Bases (KBs) of the persons workarounds or fixes.