Visualise BAU work items on the team board, allocate a team member daily to complete urgent items, and measure the impact of BAU items on team progress. Implement a telemetry toolchain from engineer laptop to test environments to live traffic, including a logging stack like EFK, a monitoring stack like Victoria Metrics, and an incident response platform like PagerDuty. Establish an automated telemetry toolchain.Introduce XP development practices such as pair-programming and test-driven development, use dynamic test data to parallelise functional tests, establish zero downtime deployments, and allow a fast revert on failure. Create a fully automated deployment pipeline.Eliminate avoidable dependencies, soften unavoidable dependencies, create availability redundancy, and share behaviours via APIs instead of closed-source libraries. Rearchitect digital services for adaptability.We recommend these practices to cope with BAU: Keep product teams proactive and productive
We’ve worked with organisations where on-call product teams have gradually eliminated many types of BAU, until it’s only a small amount to handle each week. If the percentage starts to go down, and team members complain about excessive time spent on intermittent alerts, deployments etc. Ask them to fill out a survey of how much time they spend on planned work, each week. The easiest way to spot this pitfall is to measure the amount of unplanned work faced by a product team each week. Monitoring dashboards and alert definitions aren’t fully automated.Deployments aren’t applied repeatedly and reliability in all environments.Digital services aren’t designed to gracefully degrade on failure.They already face a lot of BAU in managing their own infrastructure upgrades, applying defect fixes and security patches, and refining the telemetry toolchain. When you adopt You Build It You Run It, your product teams are on-call and responsible for running their own digital services. As long as you avoid this important pitfall. Surely, putting engineers on-call will delay planned work, because engineers will spend their time fixing live maintenance issues? The truth is, it really doesn’t have to be the case. If you are considering implementing You Build It You Run It, there’s an understandable worry amongst senior leaders. This usually happens because unplanned work (to keep the lights on) isn’t easily visible, and can start teams on the negative spiral of a reactive learning culture. The more BAU unplanned work you have, the greater the perception that teams are slow delivering planned work. The more unplanned BAU work you defer, the higher the risk of production incidents because of the lack of maintenance. The more unplanned BAU work you take on, the slower your planned product work will be. If you work in an enterprise organisation, and you haven’t adopted You Build It You Run It yet, I’m guessing there’s plenty of BAU. Minor changes to existing features, due to customer feedback.Support tickets, resulting from live incidents.It’s usually a synonym for ‘unplanned maintenance work’, and includes: We see the expression BAU (Business as Usual) used a lot. In fact, you can escape it completely, by following these four simple rules. In our recent You Build It You Run It playbook, my co-author Steve Smith and I take a deeper look at the BAU pitfall, and the risk of unplanned maintenance work becoming uncontrollable. However there are some pitfalls which, if not addressed, can drain the confidence of your senior leadership, and ultimately put the success of You Build It You Run It at risk. It accelerates your time to market, increases your service reliability, and grows a learning culture. It empowers product teams to own every aspect of digital service management. The problems and solutions are not just technical: dealing with the psychological impact of the problem and how it affects teams has been one of our biggest challenges - get it wrong and productivity and turnover are badly affected, further limiting the team's effectiveness.You Build It You Run It operating model is a powerful tool.
BUSINESS AS USUAL IT SUPPORT HOW TO
These are the 'business as usual' (BAU) things which probably underpin the current revenue of your business.Īs such they are critically important but are almost certainly unloved and possibly even loathed by the teams responsible for them! BAU includes fixing bugs, handling support problems, running regular or ad hoc processes, and dealing with legacy systems amongst other things.īased on four years of experience at the Royal Pharmaceutical Society, this talk presents some of these challenges and suggest tactical options for dealing with them day-to-day as well as how to go about understanding and fixing the underlying problems.
One of the challenges facing teams, particularly small ones, is having to balance the time spent on doing fun new things and having to support old (or antique!) systems and processes.
0 kommentar(er)
