Actually, this blog is about “What does Agile Development mean in IT Service?” More about families at the end including a useful video for those with young kids.
The Open University is using agile methodologies to increase productivity and responsiveness. This has got me thinking about what it means for IT Service. Agile is all about breaking development down into manageable chunks (“Sprints”), regular user interaction, daily reviews and retrospectives to learn and improve. But it is hard to find references to Service and Support in Agile.
As a seasoned IT Service person, none of this is new – we have been doing daily service reviews (SCRUMS), small time bounded service improvements (SPRINTS) and learning through root cause Problem Analysis and Major Incident Reviews (Retrospectives) in IT Service and Operations for years! So I would argue that being agile is not new and unique!
Cynics (including some IT Service Specialists) tend to resist agile for the wrong reasons such as
- “There is no planning” – not true – discipline and control are still essential.
- “Testing is less structured” – also not true – indeed testing has to be far better and more automated to make agile successful.
- “It’s all about user functionality” – no, agile also does NOT mean ignoring Service and Support. However, we have to find different ways to build this in compared to a conventional project lifecycle.
The principles are the same – whatever methodology we use. Service has to be an integral part of the design big picture, and also each individual chunk of delivery. What we have to watch for is waking up one morning and finding a series of iterative developments has turned from a proof of concept into a critical business system by accident without the necessary resilience, scalability, support skills and monitoring tools being in place.
So as long as we place equal weight on service and functionality in whatever methodology we use, all will be fine. However, Infrastructure doesn’t always lend itself to iterative development, so some significant steps may still be required. The key is each step needs to think about Service as much as end user capability and to have a overarching plan for major deliverables such as underlying infrastructure. Are we doing that enough?
So what has this got to do with families? Take a look at this very interesting video clip.
It talks about how agile can be adopted in a family environment. I found it a very useful way to get my head around the concepts of agile in a different context. It’s well worth watching even if you are not an IT person – might even defuse some of those regular family arguments as well as help you understand agile development.
Mark, totally agree with your observation that IT Service has had “agile” as an ethos for many years. The next aspect of IT that could benefit from a more agile approach is in all likelihood the process of RFP creation and tendering. Both sides of these processes, that being customer and supplier, could benefit immensely. What I haven’t fathomed yet is how to apply the ethos to the reality. I’ll get back to you on that!