I’m a pragmatic person and as far as I am concerned, there are 2 simple aspects to agile development: Tools and culture. Let’s talk about tools first.
“That ain’t workin’ that’s the way you do it“
In recent years, SAP has certainly been doing its best to fulfill agile requirements of customers by coming up with tools such as Composition Environment (CE), which entails its own Business Process Management (BPM). In addition, there’s Visual Composer (VC), a user interface development tool. Both BPM and VC use graphical editors. These tools cover most of the design time. Granted, in BPM’s case it stretches a little further into process design.
With the latest revision of CE (version 7.2) SAP has done a good job of introducing even more “zero-coding” solutions which are built to decrease development time. From a tooling perspective, BPXers and Designers have all reason to be cheerful: Agile (or rapid) development of standards-based SAP software has never been more of a reality than today, as my colleague Owen Pettiford recently pointed out in his The specified item was not found..
Hearts & Minds
As with so many things IT and computer, the obstacles are not tools or machines. It’s the paradigms, habits and routines of developers and users that pose the real challenge.
In many cases, IT departments want to work agile to begin with, but then realise that clinging on to producing an abundance of development documentation stifles this flame.
Or: Designers and developers can suggest usage of wikis and social media sites. But if IT security policies see the usage of latest browsers as a risk and therefore prevent usage of latest web based tools, then there is little that can be done in the short term.
I also find that Wikis and other Web 2.0-based tools are more likely to be adopted by IT themselves, not the analysts and hybrid managers that act as the bridge between business and IT. A tragic position to be in, as it is exactly these people you need on board!
In my experience software designers and developers can become very infatuated with tools such as Wikis, Twitter-style team messaging and latest collaborative tools. I’ve been there myself! A while ago I wanted to know which software tools are best for the Scrum Methodology and I asked the question on Twitter. I thought the most impressive replies were the those where people said: “We use sticky notes” or “A white board”. Respect !
Now, I’m not saying the software tools are no good. What I’m saying is that I do have a lot of time for pragmatic people who want to try to keep things simple.
So what can be done?
“You can’t always get what you want”
What’s important in my view is that a customer or client is being picked up at exactly the point of their own “agile evolution”. What do I mean by that?
I think it’s quite simple: it means being pragmatic and being flexible for workarounds. Rather than giving up on the idea of delivering working, good quality software, it’s more important to compromise on using a Wiki, for example. Instead, offer additional iterations or playbacks to compensate for the lack of collaborative documentation. Maybe even go back to emailed Word documents again if necessary. Or use screen grabs and screen videos to keep customers involved rather than insisting that only the latest video conferencing software will score the “agile high score” for you.
I guess I’m saying “don’t do agile for agile’s sake” and give other team members the time they need to adjust to a new way of thinking.
Now, you could say, “That’s all in the Agile manifesto!”. And you would be right. However a lot of what I read and hear about agile these days sounds like it’s a pill you take or a light switch you turn – eh presto! you’re in agile land. A “get agile quick scheme”. Sorry, but to me this doesn’t exist.
There is no shortcut to become agile
Realising that agile is a journey for a project team and not a destination, is the real eye opener here.
You better start that journey today.