An IT perspective of DevOps - Part 2: What's on our backlog?
Comments (2) Visits (4046)
In my previous post I gave my definition of the term development operations, or DevOps, and how this related to the transformation underway in my organization. We knew that to create a closer partnership with our stakeholders we would need to work more like them and also understand all the work that we had committed to provide them. In essence we were saying that we needed to be more agile and understand our backlog.
The need for a department-wide view
In my organization teams have a good idea of what they are doing or are planning to do. However, at a departmental level it was much harder to see what was going on. This meant that prioritizing work was only possible at the team level—we couldn't determine whether, for example, provisioning a new machine was more or less important than setting up a new database. What's more, it was difficult to understand how resources could be deployed most effectively across the organization since we didn't know what most effectively actually meant.
Moving to an agile way of working
Like our customers, comprising local and geographically distributed software development teams, we needed to become more agile. In particular we needed to move to a more iterative way of working as this would provide more timely feedback, allowing department-wide decisions to be made sooner. Earlier in the year the whole department had been given a half-day “introduction to agile” education, which provided a whistle stop tour of the prin
Defining communities and delivery teams
A new department model was introduced whereby every professional was assigned to at least one of the following:
It was believed that this approach would help to breakdown traditional silos within the organization, which had formed as the result of the amalgamation of three distinct teams. The CoPs would address how we do our work, while the delivery teams would address the what.
Trying it out for real
While most of the organization continued to work in its original way, the first service delivery team (SDT) was created. As leader of the team I was responsible for introducing agile practices such as daily scrums and iteration planning. Additionally, I fed back to the management team our experience as we got into a rhythm of regular iterations, planning and reflecting. This allowed the management team to identify how to obtain a department-wide viewpoint, albeit with a single SDT, before rolling it out to the whole organization. This prototype phase lasted for six months, and at the beginning of 2013 the remaining teams joined the new model. The prototype phase allowed us to understand how to do the following:
At this point we prioritized our backlog ourselves to identify the most important work to start first. This was not ideal as it didn't involve our stakeholders directly. For this to happen we'd need to closer interaction with the development community and we'd need to provide visibility to our backlog ... and that's a whole other story.
What are your thoughts on the approach we adopted? To continue the conversation, leave a comment here or send me a tweet @jao1313.