So far in our quest to define a workable four-lane release strategy, I’ve covered Lane 1 (high priority emergency changes) and Lane 2 (routine, often weekly support changes). Now let’s look at what I see as the key lane – Lane 3, carrying continuous deliveries of working software packages.
Lane 3 accelerates delivery of major enhancements and business-requested change orders. Depending upon your organization’s size, complexity and change volume, it may promote changes to production in monthly or even quarterly cycles. For a large organization, this qualifies as near-agile development.
There are some striking similarities to the agile development techniques of smaller organizations. For example, Lane 3 essentially divides what could be large projects into smaller units of work and delivers them more frequently.
Of course, such an agile-like approach requires strict controls in a large system and sometimes we’ll probably need to change lanes. Still, Lane 3 provides the needed mechanisms for accelerated small-package delivery when practicable.
Many IT teams are being tasked lately to devise continuous release delivery strategies specifically to accomplish Lane 3 objectives: Replace large, infrequent change releases with smaller, more frequent releases and tune systems better to business needs. Done well, the approach will also reduce the disruptions that large, infrequent releases invariably introduce.
Change control is often the logical central coordinator in this approach, though of course companies must select release management tooling to fit their current needs.
That said, business wants IT to deliver stable working software as rapidly as possible – and more frequent releases can have the flexibility to serve rapidly changing business needs in today’s markets.
The near-agile approach is slightly different than how most companies currently manage their SAP systems. But we do see businesses moving away from large go-live projects. As complexity grows, confidence wanes in the all-at-once, “waterfall” deliveries typical of large projects.
There are challenges, of course. Accelerated delivery, greater control and heightened stability do not make an intuitively obvious combination, but failing at any of these would impede successful continuous change strategies. The flexible, multi-lane approach lets you adjust your development, testing, review and approval policies to fit different delivery schedules for each lane. On complex systems, it’s worth taking the extra care.
Companies with manual processes can struggle with a multilane strategy but automated processes help you deliver packages into production rapidly and reliably. If big projects have caused problems, a more agile strategy will give your business users confidence you’ll help them meet market opportunities effectively.
Next month I’ll finish this series with a look at Lane 4, where large projects arriving in six or 12 month cycles deliver major SAP projects, bring new modules online, upgrade major systems, and so forth. Until then, if you missed our recent webinar Build Your Own ‘Super Highway’ to Manage Continuous Delivery of SAP Changes, you can access it here.