Earlier this week I blogged about customers that I've spoken to this year and their desire to work towards adopting DevOps tools and ways of working.
In case you missed it read Unicorns are cool, but DevOps horses pull a lot of weight
The day after clicking "Publish" I met with another customer from the Financial Services industry who identified with the model of Unicorns and Horses; the former being teams that have capabilities like continuous deployment, integration, heavy use of version control and automated testing. The latter being the rest of the world that don't but recognize that their release and delivery pipeline would be smoother if they had.
The chap I met managed BACS payment systems and started by telling me about the difficulty in recruiting people into the lower echelons of his IT organization that had experience in BACS, or even had an interest in investing their time and talents into such a legacy system. I didn't have the heart to ask if he had a complete set of automated regression tests for his 30 year old BACS system.
The four characteristics of teams that have highly developed DevOps capabilities represent an almost insurmountable challenge for some customers but I want to repeat my mantra from my previous blog post:
The value for teams embarking on a transition to DevOps is not at the destination, but on the road itself.
Meaning that teams shouldn't consider the culture, tools and process changes associated with DevOps and worry that value is only delivered when all four characteristics (deployment/integration/version control/testing) have been achieved. Lots of the value is realized by the first few steps towards agility, and those steps are available to everyone today that uses ServiceNow today for IT Operations.
Starting the DevOps conversation with the IT Operations side of the organization could be seen as taking the better but more rocky route. Development teams are more aware of agile practices and incorporate practices like iterative development, visualization of work in their own silo.
Operations teams are more geared towards stability than change, and might offer more resistance to the type of cultural changes that DevOps demands.
It is said that every IT organization is under two simultaneous and opposing demands. React more quickly to changing business demand, whilst providing more secure, more stable and more predictable IT services. Operations teams are all about delivering the second of those two demands.
What small step can I take towards preparing my operations team for a DevOps evolution
One other conversation I had this week, on Twitter, was about the approach that organizations should take towards a change like introducing DevOps. David J Anderson, Pioneer of the use of kanban systems for improved service delivery, replied to a tweet I had posted.
The idea of evolutionary change in a system as opposed to a decision point where change is introduced, is key to Davids formulation of kanban as applied to knowledge work. Something that I definitely respect, and will cover in later blog posts.
What it essentially means is that people often don't react well to change that is imposed upon on them. One key message that I've taken from various conversations about DevOps with companies attempting a transition is that IT Operations see the change as a threat to their way of working, and the stability to their services.
Of course the data says otherwise - highly performing teams that practice DevOps enjoy faster delivery times with fewer failures. But culture change is hard and DevOps a leap into the unknown to some extent for all that attempt it.
So what can you do today to introduce your Operations teams into a new way of working. The way of working with task data has long been defined by two user experiences in ServiceNow: Lists and forms.
Those metaphors aren't inherently bad - it's the way we've worked with process data for multiple generations of tools; but there are limitations that can be lifted with just a click or two in the platform by viewing the list data in a Visual Task Board
This change doesn't require any ServiceNow coding and is safe to try on your instance right now. Go to a list of incidents, locate the menu dropdown next to the State field. Click Show Visual Task Board
This takes the same set of IT Operations data and renders it into a user interface that represents each state as a lane, and each task as a card within the lane
Immediately you can see an more interesting way of interacting with the data. Note, if you wanted to switch back to a list you can toggle between Lanes|List at the top.
Why is this relevant to IT Operations teams preparing for an evolutionary approach to DevOps? The Visual Task Boards represents a flow of work through various stages on the journey from raw, unrefined work (Incidents in the New state on the left side of the image) working rightwards towards the final product (Incidents in the Closed state, not visible, but to the right side of the board).
The 3 benefits of Visual Task Boards
This definition of a flow - or in DevOps speak the value chain - is an important visualization for DevOps teams. How is work completed, what transitions are made and what handoffs happen between individuals or teams?
IT Operations teams can visualize the progression of work, and because we are interested in evolutionary change we haven't changed anything. Incidents have the same states that were available in list or form format.
A second benefit is the visualization of workload and potential bottlenecks. Typically teams deal with a high volume of tasks, and when viewed in list format it isn't apparent just how much work is at play, especially if the list spans several pages (1 to 20 of 88, for example)
Visual Task Boards allow teams to see where the work is located. A quick view of the image above shows that the majority of work is located in the Active lane (or state). As we talk more about constraints we'll learn that might be an indicator of a problem and how we can attempt to solve that.
Smoothing, measuring and regulating the flow of work through the value chain is another point of value on the DevOps transitionary path. You can get started with a few clicks by viewing Visual Task Boards.
Lastly - teams that attain agility are able to respond quickly to the most urgent business demand. Whilst viewing IT Operations data in a list the methods of classifying by priority, urgency or impact are fairly blunt. At any one time you might have multiple Priority 1 incidents but which task is actually most important.
Visual Task Boards, when shared with a team which is easy to do in ServiceNow, allow for a wider understanding of what is the most important next task. By dragging a card to the top of the lane, and informing the team to always take from the top of the stack when they are free, managers can respond to requests for reprioritization.
Again - this kind of business alignment is common amongst highly performing teams. Why not get started today?
In summary
I wanted to leave you today with a technique for introducing a low-impact, quick change to your Operations team that doesn't change their workflow or cause disruption. Teams can realize 3 benefits from VTB
- Visualization of the value chain
- Visualization of workload, including potential bottlenecks or constraints
- Global understanding of priority and high value items through ranking
We'll come back to Visual Task Boards another time and we'll continue talking about the first few steps towards DevOps in the next post on Monday.
In the meantime please share this article, and let me know on twitter how you found Visual Task Boards on first inspection.
Note: Visual Task Boards were released in Eureka and developed further in later releases
