Skip to Content
Author's profile photo Former Member

Agile Is A Journey

Unless you’ve lived under a stone you would have noticed that “Agile” has been a buzzphrase for a while now in the IT industry. The declaration of the Agile Manifesto in 2001 has certainly been a milestone for this movement. A lot of what is now called “agile” was already mentioned during the 80s and 90s under the name of “Rapid Application Development”. 

I want to put into words what the impressions of my “agile journey” so far are. I’m going to focus on “Agile Development of SAP software”, as this is my area as Composite Application Designer.
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.

Assigned tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Thorsten Franz
      Thorsten Franz
      Thanks for these encouraging words. Sometimes it seems indeed as if a magic pill or a "get agile quick" scheme was the answer, but that can't be it.
      I hope you'll keep us posted on the progress of your journey to agility. I've been doing the first steps of my own and I'll be glad to read what's around the corner.
      Author's profile photo Former Member
      Former Member
      Due to the nature of my work, I usually have teams in multiple countries. When business users and developers sit several timezones away from each other, it is already quite hard to make it work with waterfall approach that we are very familiar with. My expiriments with Agile didn't go very well either, once the scope was large. The only time I got good results with Agile was when I had part of the team co-located for some time and taking care of one small (but important) part of the scope.

      So I am trying to find if there is a happy medium - a hybrid of waterfall and agile that will work for my situation.

      I have not thought about it through completely - but I suspect that there might be issues with how contracts are written with customers, if you switch to Agile for large deals.

      Author's profile photo Former Member
      Former Member
      Blog Post Author
      Hi Vijay,

      a very interesting point! Initially I was planning to weave it into this blogpost, but then decided to leave it for a follow-up, so stay tuned.

      Generally I agree with you, I think Agile is difficult to handle in a distributed, global environment.

      As far as Agile for large deals is concerned, I'd start using it on a small scale first. Again, it is about getting the hang of it first.


      Author's profile photo Former Member
      Former Member
      Hello Vijay,

      When you have a wide scope it is hard to use Agile development. For this purpose, you'd have to divide your scope in several smaller deliverables that are achievable in shorter terms and then distribute these deliverables across sprints.

      On the other side, if you have several teams on several timezones, you might try to have these teams working on consistent topics. Then having a cross-scrum meeting in order to coordinate the work of the different teams.

      Of course, this would require an additional effort of coordination but that would still be possible. And this is the very cases where collaboration tools such as Wikis would prove helpful.

      Author's profile photo Twan van den Broek
      Twan van den Broek
      Hi Vijay,

      Large scope?
      When you have a large scope you can still do your project in an Agile way. You will have multiple iterations with a small scope to reach your end goal. In what order will you go through the scope? That is all about priorities, to be set by the team and the productowner.

      Contracts are about distrust.
      Agile is about collaboration and trust between demand and delivery.
      Forget about the false security that waterfall projects bring. Start talking about how to jointly reach the project goals. (I am aware that this requires a huge amount of trust at both parties).

      Agile in distributed environment?
      Difficult but not impossible. Use online dashboards, wiki for documentation, google wave for collaboration, gravity for online modeling, conference calls for standups, webcams, ... (I am aware that this requires a lot in the skill set of all involved team members, you will have to do a lot of change management)

      Kind regards

      Author's profile photo Dagfinn Parnas
      Dagfinn Parnas
      Excellent blog and totally agree on that get agile quick scheme doesn't exist.

      In general agile methodologies such as Scrum bring the dysfunctionalities of the organisation and the impediments the team faces to the surface.
      They have always been there, but now they are visible. It is then up to the organisation if they want to face up to them or just ignore them.

      One way of getting the impediments up to the surface having short iterations for implementing new functionality which provide business value. Scrum recommends that this iteration is keep to 2 weeks and the reason is the same as why Scientist working with genes experiment on flies and not elephants.

      Looking forward to your next blog on the topic


      Author's profile photo Twan van den Broek
      Twan van den Broek
      Hi Michael

      Thanks for great blog. There is no shortcut to being agile, no pill. Hey and even when you are doing agile it doesn't mean that all evil project disturbances are gone... (Sorry if I have disappointed anyone) You're still doing projects and you will steed need people to reach your goals.
      Agile is a journey, it is a road to your destination. Agile is not your destination, your project goals - that is the destination. And by being Agile you will experience a lot of fun doing that project:
      - Focus on collaboration between business and IT
      - Focus on the endsolutions
      - Discussions on priorities in stead of deadlines
      - Small comprehensible iterations to end result

      Don't study on it for 6 months, do it, be pragmatic. Come along and travel with fellow Agile SAP SDN/BPX-ers.