The majority of organisations I’ve worked with deliver new system functionality as development projects. These are funded with capex, and have a start and an end. Even projects that are ‘agile’ are still expected to finish at some date in the future, then once the system has been delivered it will undergo ‘handover’ to ‘BAU’. The project team usually moves on to new projects, developing remarkable cases of mass-amnesia along the way.
Projects deliver exactly what they promise. Project teams have little incentive to invest in the long term operation and maintenance of the systems that they create. I’m not saying that the team doesn’t care or are intentionally acting irresponsibly, but when delivery pressure is applied the first things to be dropped from the project schedule will be the cross-functional concerns that make the system reliable, monitorable, deployable, and maintainable ongoing.
The project effect:
- the project team do not have to live with the long term results of their own architectural and design decisions.
- BAU support/maintenance teams are generally under-resourced, have extremely limited opportunity for handover from project teams, and have to support many different systems. This usually leads to less than ideal development practices and deteriorating quality over time.
- the project team never have to be involved in problem analysis for production outages. They’re never forced to put the right kind of monitoring and logging in place to find root causes.
- the project team only do a limited number of releases to production, so have little incentive to invest in reliable automation or production-like test environments.
Therefore – I believe that many projects are the source of ‘instant legacy’, and a major cause of the development and operations divide.
What’s the alternative? Form long-lived teams around applications/products, or sets of features. A team works from a prioritised backlog of work that contains a mix of larger initiatives, minor enhancements, or BAU-style bug fixes and maintenance. Second-level support should be handled by people in the product team. Everyone in the team should work with common process and a clear understanding of technical design and business vision.
This approach is not easy – it introduces new challenges particularly around balancing priorities and budgeting. I’ve observed that the benefits in terms of long term system health definitely outweigh the drawbacks. Like everything – hire good people who care, and give them the right incentives, good things will happen.
Spot on Evan!!!
This post is just perfect.. Thinking about root cause analysis, this is really one of the biggest reasons why people behave the way they do on “projects”…
We have been talking about these concepts on our current engagement.
Merging as much as possible BAU and Projects… Eventually, they will be only one.
Very well put
Cheers
Pingback: Continuous Delivery and ITIL: Change Management | Continuous Delivery
Terrific post. I’ve referenced it in my own post on Structure Agile for Product Teams.
Keen to read more about your recommendations on “balancing priorities and budgeting” for product teams.
Pingback: What DevOps Means for Enterprises — Agile Web Development & Operations
Is this complicated by the fact that some of the work will be funded by capex and some will be funded by opex? Might a develoepr not work on stuff in 1 iteration that has to be attributed to different cost centers? That’s not too big a deal but are there other ramifications to a single team taking on both operational and feature based work? I’ve worked on teams like this before where someone in the team had to wear a pager at all times (rotating) and respond to unresolved L2 tech support calls. While we did realize some of the benefits you describe, it was also very difficult to poredictably complete feature work due the the unpredictable and bursty nature of the support work. We simply worked to make this labor distribution very visible to all stakeholders BUT when we did that people started clamoring for a seperate team to handle all the operational work. Square.One!
I can identify with all of it. Our latest endeavour has been to do exactly as you’ve suggested, but like Gregory Smith says, our ‘dedicated’ (rotating) support person regularly gets sucked into support problems, and if they need help from other team members, they also get sucked into the vortex, causing real impact on other progress.
I’ve used this as customer bait to get them to prioritise unsexy, but supportability focused stories/requirements in the hope that it eventually makes development team progress more focused, with the added benefit that we can hand over a more simple system to a ‘BAU’ team.
I am so surprised this article has not received so much more attention. For many IT organisations this is indeed the fundamental root cause of a lot of their problems in IT (costs to high, projects over budget, projects exceeding deadlines, no productivity, no delivery of quality software and much more). I have the strong feeling management heavily underestimates the way a project is financed impacts how people behave (incentives) and thus the results.
Pingback: Continuous Delivery and ITIL: Change Management