Managing Customer Expectations: Slas And Agile Maintenance Teams

The Challenge of Aligning SLAs and Agile

Service level agreements (SLAs) define expected service performance metrics like uptime percentages, response times, or feature release cycles. They codify the service quality customers can expect. However, traditional SLAs often struggle to align with modern agile software development processes which emphasize rapid iterations and fluid priorities.

Agile methods like Scrum focus on quickly delivering working software in small increments. Requirements evolve through constant customer feedback instead of detailed upfront specifications. Teams adopt just-in-time planning to maximize flexibility and responsiveness. This agility enables aligning output with current customer needs but makes committing to long-term SLAs difficult.

For example, pushing new features every 2 weeks can make it hard to guarantee a major release by a fixed date 6 months away. Scope creep from continuous client input expands functionality but reduces predictability. Changing priorities shuffle roadmaps and backlogs, jeopardizing time estimates. Unforeseen issues or dependencies suddenly appear, delaying sprints. Such inherent agile variability challenges rigid SLAs optimized for waterfall development lifecycles.

Examples of Agile Development Hindering SLA Conformance

Imagine an SLA which specifies releasing a customer portal with integrated dashboards by June 30th. However, April client feedback asks to prioritize a new mobile experience instead. The team spends several sprints on responsive UIs and progressive web apps, causing the portal to slip. Even if the underlying agile process functions smoothly, dynamic reprioritization prevents meeting the original SLA.

In another case, an SLA might promise portal upgrades will take less than 4 hours for 98% of changes. But adding CI/CD automation and infrastructure as code unexpectedly expands update complexity. What once took 2 hours now requires 6 hours due to more deployment steps. Despite increasing agility via continuous delivery, the SLA metrics degrade.

These examples demonstrate how agile teams, despite working well, can still struggle with SLAs defined for traditional plan-driven development. Reconciling responsiveness with accountability requires rethinking SLAs for nimble environments.

SLAs in the Age of Agile

To maximize customer satisfaction, SLAs for agile teams should focus less on long-range timelines and more on iterative achievement. Rather than a fixed delivery date, they should define a reliable cadence of incremental value. Instead of an hours-based service metric, they should specify feature-based priorities and production quality levels.

Exemplary Agile SLAs

Rather than promising a full customer portal by June 30th, an agile SLA might establish reliable 2 week release cycles: “The team will deploy portal updates to production every 2nd Friday with new features prioritized by the client.” This maintains accountability via regular deliverables without forecasting far ahead.

For the 98% 4 hour upgrade SLA, an agile alternative could be: “New dashboards will be subscriber-ready within 1 day for A-priority items. B-priority tickets will be production-ready within 3 days.” By emphasizing feature delivery speed over service downtime, this SLA syncs with agile prioritization.

For agility, SLAs should specify more process than product. For example, instead of a fixed go-live date, focus on proving consistent sprint velocity. Or establish an allowance of 20% per sprint for unplanned items to accommodate change. Such SLAs provide standards without sacrificing flexibility.

Planning for Success

While agile teams value responding to change, they still require accountability. Careful planning and diligent tracking helps balance dynamism with dependability. The key is limiting long-term assumptions while adding short-term confirmations.

Aligning Roadmaps, Backlogs, and Sprints

Product roadmaps should frame objectives at a high level without overspecifying interim milestones. Feature backlogs can then elaborate priority areas in granular but non-binding detail. Only sprint commitments represent formal promises to customers for what the immediate iteration will deliver.

Treat roadmap elements as hypothetical targets subject to learning and change rather than fixed deliverables. Backlog items are candidate capabilities not guarantees. By avoiding top-down assumptions, teams stay nimble to handle new inputs. Distill concrete accountability to small sprint increments which lend confidence to agile adaptability.

Capacity Planning and Forecasting

While sprints create reliable near-term delivery cycles, some view of future release reliability still benefits customer trust. But traditional multi-month projections rarely fit agile environments. Instead, focus forecasting on empirically-derived iteration velocity:

For example, if historical data shows a team closes 35 points per sprint on average, they can reasonably commit to 10 sprints over the next 5 months. This aggregates to around 350 points worth of new features, though precisely which features remains flexible according to continuous reprioritization. By pairing fixed iteration cycles with variable itemization, teams conjure dependability despite uncertainty.

Combine such extrapolated throughput with historical defect rates and project size estimates to forecast release cycles. If sprints produce about 500 development points annually and typical client projects require around 2000 points, clients can expect 4 development cycles spanning 8-12 months. Framing projections based on past sprinting establishes plausible reliability targets.

Staying Accountable

While agile teams want flexibility, customers still seek accountability. Monitoring processes against reasonable standards provides needed confidence. However, traditional compliance tactics like Gantt charts or PERT diagrams rarely suit rapid development cycles. Agile SLAs require fitting accountability methods.

Tracking Progress via Accountability Markers

Have each sprint commit to producing a predefined output demonstrating continued if partial progress. For example, an e-commerce portal project might establish specific milestone targets like:

• Core product catalog integration
• Shopping cart ordering workflow
• Inventory status dashboard views

Though specifics fluctuate, seeing regular delivery of concrete functionality provides assurance. Have sprint reviews showcase achievements to customers to affirm accountabilities are being met.

Automating and Analyzing Agile SLAs

Automated DevOps pipelines provide speed; instrument them to also ensure compliance. Bake SLA status monitoring into build tools via metadata tagging. Track feature development, test pass rates, deployment times and other benchmarks in pipeline task metadata, then feed these DevOps data streams into analytics tools to determining aggregate SLA achievement rates.

Analyzing aggregated cycle times, lead times, and productivity across sprints provides empirical insight into both system and team performance. Compare benchmarks to SLA targets to prove both progress and reliability. Statistical process controls alert when variances threaten SLA conformance so teams can adapt before obligations are breached. Data and automation provide objective accountability.

Exceeding Expectations

Amidst balancing agile adaptability with reliable deliverables, overachieving customer expectations should remain every team’s goal. As processes improve and workflows stabilize, teams often exceed initial conservative SLAs. Such upside both delights clients and provides protection should future volatility cause temporary downshifts.

Delighting Customers by Beating SLAs

One portal project squad beat their 2 week release cycle by shipping to production 6 times in just 7 weeks. Their sprint velocity increased 30% over planning rates by refining processes. Clients loved accessing new features faster than expected while the team still met its original SLA obligations, demonstrating exemplary performance.

Another team narrowly missed an A-priority 24 hour production-ready window for complex dashboard by just 2 hours. But in missing, they identified deployment inefficiencies. By optimizing CI/CD scripts and clarifying code ownership earlier, they shrunk the lead time for subsequent dashboards to under 16 hours, impressing customers with their dedication.

Such SLA overachievement delights clients while providing error margin for teams. As agile practices mature, balances between accountability and agility find the sweetspot satisfying both business disciplnes and customer needs.

Showcasing Achievements Beyond SLAs

Structured SLAs and disciplined tracking provide a foundation of reliability. But the most successful teams complement their measured outcomes with humanized overviews. Augment cycle time graphs and burndown charts with user stories capturing how new features delight customers. Put faces from client testimonials alongside regression reports. Quote executives on how software successes enabled their business ambitions.

Such qualitative perspectives enable dry delivery statistics and perplexing process analyses to showcase meaningful value. They remind executives of the ultimate purpose behind all the development data, affirming how accountability to benchmarks still aligns with customer priorities. Paired with the quantifiable assurances of progress against SLAs, they provide proof that agile teams can deliver both flexibility and reliability better than traditional approaches.