Shouldn’t we have put the Science of DevOps before we put the Art? In many cases, yes, but not when you are dealing with large SAP programs.

Why? Join us in this fascinating journey through creating and executing a DevOps roadmap for a multi -million $ SAP program, and find out why.

The program is currently structured in a traditional Development and Support model. The driver for DevOps is a need to be able to fluidly manage the demand funnel without the current rigid boundaries, increasing responsiveness and flow.

The authors partnered in applying a DevOps maturity model to the program, and came with against this:

• “This stuff may work else where, but this is SAP”
• “SAP already does what you want”
• “Branching in SAP? Haha! How can you do DevOps?”

This session will cover the model, the analysis approach, its application in a SAP specific program. And you know what? It is indeed true that SAP DevOps needs some changes to account for how the SAP product is structured, and its ways of work.

To those wondering how SAP DevOps isn't just regular DevOps, here are just some examples that make SAP DevOps more interesting:

1. Continuous Integration is hard to achieve, as there is no separate build process, activation is the build.

2. No access to binaries.

3. Rollback of transport requires significant effort.

4. Concurrent development hard to achieve as the SAP version control system uses locks.

5. Manual retrofit of the changes to the same object.

6. Difficult to achieve on demand infrastructure.The costs and lead times to provision and manage SAP environments are relatively high.

7. Tight coupling of multiple modules.

8. Missing strict enforcement on the workbench for the errors, only guidelines available.

But the real Art is in being able to demonstrate to a skeptical group of SAP specialists that DevOps provides value, not matter the platform.

Join us to find out how.

7 scripts. 30 performances a year. 4 venues.
And close to nothing in the bank.

Theatre on Bengaluru (www.tob-group.com) seemingly was on a roll, selling out performances regularly at multiple venues, with actors lining up for roles, and a healthy list of scripts in the pipeline.
There was just one problem - once the venue, costumes and amateur cast were paid, TOB was running on fumes - one poor collection would leave TOB in the red. Vineed Menon (the founder) was wondering - how do you increase monetization when your performances are already full?

A serendipitous meeting with Avinash (SAFe SPC, New Product Development certified, Agile coach) led to TOB adopting the LEAN startup approach to offering development and to increase revenue.

Today, TOB has three lines of business:

1. A Theatre 'PaaS' offering where interested directors can stage their plays via the TOB platform - venue, publicity, ticketing and staging are handled by TOB for a % of the receipts.

2. Children's theatre workshops during holidays, at apartments around Bangalore.

3. The original plays continue as well!

The results are unarguable - money in the bank is now 10X the amount that TOB started the LEAN startup journey with 8 months ago. This is our LEAN startup story, and there are valuable lessons for IT (indeed for any industry) in this story.

After having scaled Agile development using Scrum and successfully delivered an award winning 10,000 Mark II FP product in 2 years, how can the client consider the same program as failing a year later?

This cautionary tale presents a 3 year journey from Waterfall to successful scaled Scrum development, and the incremental changes that led to the gradual dilution of Agile into Scrum-Fall. In this session, we present the order of magnitude improvement that Scrum delivered over Waterfall, and then present the changes (and the rationale behind the changes) made to the model and quantify the impact of changes made to the Scrum model.

We use delivered functionality and cost as the basis of comparison between each model used. The effects we compare are in terms of Rework, defects injected, and team morale. We will show (just as Lean principles predict) that increasing the time before getting feedback increases defects; we also see that increasing the length of the iteration has an outsize effect on team behaviour – the longer the duration, the easier it is for the team to fall back into deeply engrained Waterfall behaviour.