Agile Hacks for SAP
I have a confession....
I found the transition to Agile hard.
Phew.... I'm out!
It actually feels good saying it!
Over the course of the next couple of blogs I'm going to share some of the Agile tips and traps that I've found along the way, so let's dive in....
Go Agile
I've met my fair share of Agile Coaches / Evangelists.
When you're transitioning to Agile you don't need an Agile Evangelist, you need an Agile Pragmatist. The benefits will not be realized without some difficult cultural and process changes.
Agile tools help some of the problems, but for teams with a large code base built under a legacy model, the transition can be very challenging.
This is really really important because you need to set the right level of expectation around what your Agile team can deliver.
In my last blog I talked about some of the benefits of Agile, but these won't appear like the click of a switch in day one.
It takes a lot of effort to transition to Agile and you better make sure your key stakeholders are well briefed and buckled in for the ride.... the whole ride, don't let them get off.
I'll talk more about stakeholder management strategies when I've painted the transition picture a little more, but I'm going to share my tip traps roughly in the order that I discovered them....
Agile Hack #3 Don't Automate Everything
One particular problem that I ran into was how to ensure sprints deliver releasable artefacts in the absence of a shiny automated regression test suite.
Que the Agile Evangelist
“You must automate everything
Ohhhh if I had a penny for every time I've heard that one.
For the record, I'm a big advocate of automation, the debate over the merits of continuous integration was settled a long time ago.
It's just that I haven't found the Agile advice helpful when trying to transition a legacy product and waterfall type approach with low levels of automation to the new world of Agile and Sprints.
Retrofitting test automation is like trying to paint the skirting boards after the carpet has gone down.... messy!
The fundamental problem with retrofitting test automation into a code base that predates automation is that developers change the way they write code when they adopt test automation.
And it's very difficult to go back and fill in the gaps without refactoring the original source i.e. pulling the carpet up and starting again.
For example, I'm working with Automated Unit Tests in SAP ABAP where database queries are often written inline without the need to create a connection object and hide the complexity behind a class.
I'm not teaching anyone to suck eggs but unit tests need to be re-runnable and independent. This allows you among other things to scale your tests and run them quicker.
In this example, the database call is inline which means that we can't use techniques like dependency injection and mocking to stub out the database call, which means the unit test isn't independent.
Adopting test automation from the off would naturally force us to tackle this problem up front and save time in the process.
So how do you deliver a releasable artefacts with test automation?
Well, I'm afraid the simple answer is it takes time. The reality is that if you will grow your test automation over time, which means you will depend upon manual testing to demonstrate the viability of the product.
If your existing code base is large it may take a considerable amount of effort to automate the testing, you just have to be sensible about what to automate and how much manual testing you can live with.
"Doing" Agile
Does this make me an Agile Heretic?
I've had this debate with several Agile gurus, to the extent that I've felt like I'm testing their faith!
To me this just another example of where Pareto's 80:20 rule kicks in, it's simply too expensive to retrofit test automation, so you have to be pragmatic.
The tech kinda looks after itself, I mean you'll either intuitively or empirically know the right level of automation to aim for.
But do not neglect your stakeholders.
Agile Development is a journey
The moral of my experience is that you must look after your stakeholders, they really need to understand that the transition to Agile takes time.
This can be challenging, especially if your Agile transition is perceived to be pushing out delivery dates.
I’ve used several techniques to pull the Stakeholders back from the daily grind and look at the bigger picture.
Keep an eye out for my next blog where I'll share some of the strategies that I used to manage Stakeholder expectations during an Agile transition.
