The Agile ABAPer - 5 Reasons why ABAPers should be Agile - and what you can do about it today.

[bpgreen1]

The Agile ABAPer

5 Reasons why ABAPers should be Agile - and what you can do about it today.

It’s not often a day goes by that I don’t think about how much we all learn (and forget) over the years. Over 20 years after doing a CompSci degree I might have forgotten the detail of the course but I've gradually evolved a hindsight from the graduation-view of “This was all useless, it doesn’t reflect reality” to the current “well that certainly grounded me in the basics but it changes so fast that we have to do all we can just to keep up with reality”. It is the skills learnt, not the facts forgotten which allows us to cope with the pace of change.

The recent hum around digital economy, transformation and lean programming within the world of SAP might not feel like it has any bearing on your day-to-day reality - fixing bugs, delivering projects on time, ensuring down-time is minimized.

But it really, really does.

Agile programming isn’t something which has only just been thought up. And even when it was still fresh it didn’t just spring out of the ground. No, it evolved from something else (anyone remember JAD/RAD?!). And you can be assured that to will evolve into something else.

What you have to keep reminding yourself is that this is not some big scary new methodology; you haven’t missed the boat. Over 20 years ago JAD and RAD, Joint and Rapid Application Development, was the cutting edge of software and systems development. Agile is an evolution, a rethink, but most of all it is a chance to orient yourself.

So I thought it would be good to answer a few of your questions without you having to ask and feel embarrassed. Which you shouldn’t ever be, by the way - questions are always good.

1. Agile will decrease the pain of code rework - Each sprint will contain specific, agreed-upon capsules of work. You know what you have to deliver and you know what the criteria for successful delivery looks like.
   
   
2. Agile ABAPers are happier ABAPers. You will have stronger connections with colleagues because you’ll need to cross-skill with them frequently. Each work item is now so much smaller, you will also be happier - no more weeks stretching ahead working on the same thing day after day.
   
   You’ll get more job satisfaction because you are now empowered to work directly with with all areas of the business.
   1. In your Code Reviews there will be cross pollination of ideas, you’ll learn new techniques, methods and approaches.
   2. Development teams are happier places too - this cross-pollination drives multi-skilled developers, there is less likely to be that one Rockstar Coder who is never allowed to go on holiday for fear of it all collapsing..

3. It pays to know - The Agile ABAPer earns more. OK, so I have no evidence to back this up, but we all know that counts for a lot to have a CV or a development plan which describes you as being at the cutting edge of SAP’s technologies.
   
   
4. No more weekends. Before Agile the triangle of Scope, Quality and Schedule was always so inflexible that we all knew weekends would come into play because the only room for maneuver was the schedule. With agile, the flexibility comes from Scope.
   Agile techniques in planning the sprint mean that if when the schedule is decided on, it is you and your peers who decide on what goes in. There are a few techniques to get to the bottom of how long a particular work item will take but Planning Poker will always get people engaged!
   
   
5. Unit Test pain is significantly decreased because you’ll now use automated test techniques.
   1. Extended Program Check
   2. Code Inspector
   3. Coverage Analyzer
   4. ABAP Unit
      

The are just 4 of the internal tools which SAP include and maybe you didn’t think of them as being part of the Agile ABAPer’s toolkit. These and more can all make you unit testing easier. Yes, you would have to get management buy-in to get Docker or Chef used across the project but if you can explain how it will save time and money then see how fast it will get adopted then!

What you can do about it today!

1. Find and Read 3 blogs on how others are using/implementing agile methodologies and share one of them on Twitter - tag your post #AgileABAPer
   
   
2. Bookmark 3 pages:
   • The Agile Dictionary - http://agiledictionary.com/ - Your one-stop shop for rapidly searching for that term you heard but were unsure of the context.
   • Atlassian Agile - https://www.atlassian.com/agile - Atlassian being the owners of JIRA, the go-to agile work centre for many businesses (and yes, even Basis Technologies, where I work!). Invaluable in making sprint planning, execution and backlog an easier, intuitive part of your day.
   • DevOps.com - http://devops.com/ - Every day a new story, a new viewpoint on the future of DevOps-driven technology. Not SAP specifically, but it doesn’t hurt to expand our horizons right?
     
     
3. Talk to your manager or better still, whoever does your annual review about agile. Get their thoughts, share your own. Get something Agile put on your review objectives.

Please do comment below too - if you have any great blogs or twitter feeds which keep us on the top of our game then the community will all gain from this knowledge share.

[Peter_Inotai]

Hi Barry,

Interesting topic :smile:

I believe Agile fits better to product development (eg ABAP Add-On). I did that together with using Jira and for that Agile made perfect sense. Now I'm doing custom z-development without Agile and somehow I don't miss it. Somehow it wouldn't fit that well for this as it did for Add-On development. At least this is how I see now :smile:

Cheers,

Peter

[UweFetzer_se38]

Now we only need a decent version management (GITlike) for ABAP. With the current >20 years old Life Cycle Management (transports to Q, test, back to D, etc.) it's hard to work "real" agile.

[bpgreen1]

Hi Peter,

You raise a good point and I can see how silo'd z-development can indeed work without agile. We use agile across the SDLC, even as far as including aspects of documentation, marketing material and feed it all back into future product development. So to treat ABAP outside of this process would be too disruptive.

Thanks for your input.

Barry

[bpgreen1]

Totally with you on GIT for ABAP Uwe - time we were brought kicking and screaming into the modern age of dev right?

Barry

[former_member182550]

>>Agile will decrease the pain of code rework <<

No it doesn't - it causes massive re-writes.  One actual example,  hiding full details to protect the instigators:

'We would like you to handle this input structure'.

(Ok - write the structure and it's validations)

Next:

We would also like you to handle this input structure.

(ok add a screen,  the structure and it's validation)

Next.. Another structure...  anoother structre and then:

We want you to handle these 50 different input screens but we want them configurable and we want to be able to include them in whole or in part on a screen with the input requirements configurable.

Ahh... Ok.   Throw away completely the first five screens because then it all becomes completely dynamic and the static stuff you wrote to start off with is useless.

Now - if they had said at teh outset - we have 50 structures which we want an input screen for with the fields and structure being dynamic based upon a product classifiication  then you would not have started off in the way that it did - you would go down the dynamic route directly,  saving a hell of a lot of work.

If you don't know the full requirements of a program or system before you start coding,  how can you code it efficiently and without re-writes ??  Agile is ok for teeny-weeny developements,  anything of medium of larger size it's a hazard.

Regards,

Rich

[bpgreen1]

Well sure that would happen if we were to treat ABAPers as the servant of the business, but instead why can't there be an equality where with 20+ years of experience in such things occurring wouldn't the developer ask at the start "are you going to want to have more of these structures" and if the answer is ever anything other than a completely justified "No" then we code it to be dynamic in the first place and accept that the dev cost might be higher up-front but the dev be adaptable in the long term.
That isn't necessarily agile thinking, its making sure future scope-creep is brought to the fore - which would probably be captured in a Product Approval Board.

Such large project should probably be split into many teeny-weeny developments anyway, that way any change in scope or re-think in-flight is handled with minimum impact on other objects.

[former_member182550]

Questions were asked and I was told it wasn't in the scope of this sprint.  Questions were also asked after the second screen.  I'm quite well known for future proofing my code,  however,  I also keep it as simple as possible.

Rich

[former_member183045]

The focus in agile methology is on the current sprint - but definitely not only

One of the big misunderstandings that frequently occur in Agile development is with focusing on the short term outcome (sprint, next interation, step or whatever word you use for it) ... lets stay with the term sprint.

Of course each agile development method says "focus on the next sprint" but this should never be mixed up with the term "focus only on the next sprint".

There is always something like a "Vision" to be communicated which means nothing else than that everybody has to know what the final result of the whole project should be.

When we are talking about long running projects there is (with or without agile development methods) nearly always a not detailed picture of this final result available because the scope in such projects is simply to big for a detailed specification and of course the final result will change while the project is running, there is not enough time for specification, and ...

So to put it together everybody should know, what the desired final result is - but not in detail. And everybody (but especially the developers) should focus on the next sprint and deliver complete features which are adaptable in future to reach the final result.

In other words the scope is entirely specified. But the more imprecive the more the implementation lies in the future.

Thats my two cents on this not unimportant topic.

Side note: To think about the methology, especially a change in methology makes in my opinion only a big difference when applied on big projects. In small projects like small custom z-development the used methology has not a big impact, if and only if the small developments have not to fit together.

[bpgreen1]

You raise some very good points Andreas - we have certainly seen the short-termism in our developments but it reiterates that Agile isn't some magic which solves all problems without constant control. As with any methodology it needs commitment from all levels and an ongoing planning level to ensure the mid-term and long-term strategies are upheld - your description of it as a 'vision' is very accurate. - thanks for your input - it is reassuring to see that others have opinions and are willing to share.

[SimoneMilesi]

I completly agree with you Andreas.

I cannot find a real use of AGILE methodology in "common ABAPer life" (i.e. Common AMS / Small projects) and even in big projects I found pretty hard use it, but this due the lack of the "vision" as you stated.

But this was a lack starting from the PM in charg and falling down like a cascade thru the Businnes ppl, the functional analyst and down down down.

So, yes, AGILE is cool, nice, it's the new charming method everyone requires in a job interview but... it's something that can be applied only when you got a strong and clear leadership and vision of the big picture.

Otherwise you'll end like Richard stated: endless and useless rework

[former_member182550]

"vision of the big picture"

And that is exactly my point - if you don't know the big picture how can you develope an efficient coding strategy ??

Well said Simone

[matt]

My experience of an Agile project is that the code rework has been quite painful. This was probably due to a different understanding between business and IT over what was agreed. The business spec was quite woolly and wasn't tied down.

Not necessarily a fault of Agile of course.

Anyway, my main reason for posting is to ask why you consider Extended Syntax Checker and Code Inspector have anything to do with automated testing?

[Peter_Inotai]

Hi Barry,

Meanwhile some other thoughts came to my mind:

1) Danger of pre-matured delivery:

I have the impression, that with Agile there is a bigger chance, that untested, pre-mature feature/product is delivered. Kind of "we can fix it in the next sprint" approach. Eg SAPGUI 7.40

2) Daily team meetings:

Happened quite often, that someone from the team has difficulties and someone else from the team can help. Without the daily meetings, this communication option could be missed. It also helps to have the feeling, that the members are really part of the team and they enjoy it. Of course you need nice colleagues :wink:

Cheers,

Peter

[bpgreen1]

Hi Matthew,

We use those two as just a small part of the approval process for getting anything into test in the first place. By automating their inclusion into the Dev->QA approval cycle via Transport Expresso (its our product afterall), we found that the code sent up was better and less likely to fail tests because I'd coded something stupid.

Does this mean they are part of a traditional Automated Test in the strictest Agile sense? Not sure - perhaps I was using a little latitude there.

But to ask back - where do you see automated testing in the SAP world? Does it have a place and how can it be implemented so that it is relevant to the developer?

[matt]

I think Code Inspector and Extended Syntax Checker should be used. So long as they're not enhanced to enforce stuff that should be at the discretion of the programmer, they add value.

Coverage analyser should be far more used than it is. You barely hear of it any more. I've been asked by a few clients to look into it, and always recommend its use to ensure all paths have been tested in a development, but I've never heard of a company that uses it.

ABAP Unit can also be useful, but really it's in a context of test driven development. I've a few classes where I've implemented it - but generally, I find it rather awkward and doesn't feel really suited to most ABAP developments. Probably because mostly we're not designing entirely new applications, rather filling in gaps.

[vwegert]

IMHO, setting up the coverage analyzer to produce meaningful results is too complicated at the moment. I have used it in the past, both to monitor the coverage of automated unit tests and to check which parts of the application were left out during manual functional tests, but it did take me longer than I thing would be necessary to set it up and produce meaningful results. Then again, that was a few releases ago, maybe things have changed?

The trouble with unit tests (in any language, not just ABAP) is that the application needs to be structured in a way that allows for individual units to be isolated and tested, if possible regardless of the current state of the system. That usually means splitting the application into much finer-grained classes and interfaces than the average ABAP programmer feels comfortable with. For instance, separating the database access from the application logic feels like a lot unnecessary effort when you can just SELECT flag FROM z_cust_table WHERE whatever. IMHO this is a problem of perception and education, not a technical problem. Stuff like "program to an interface, not an implementation" and "don't litter your code with CREATE OBJECT" should become second nature. Unfortunately, many die-hard classes-are-just-function-pools "developers" fail to see the point...

[former_member186783]

I don't think it's a good idea. If you're working for SAP and developing a new module, then it can work. But on the customer side, the clear and stable functional specification is a must. It cannot have sprints, because you have to know the functional needs when you start your work, and if you let it changes, then the project will never end...

[paul_bakker2]

Very perceptive. I think one of the main reasons that 'Agile' has caught on, is because functional consultants no longer have to sweat over a detailed functional spec.

They (and the project manager) like it much better when they can specify their requirements by waving their arms and making vague statements - just enough detail for the next 'sprint'. Once they've provided this verbal spec, they can tell the developer to 'be agile and get on with it'.

Waiting for detailed functional specs was always one of the biggest bottlenecks in our projects, and now that problem has all but disappeared.

But at what cost..?

[SimoneMilesi]

Even more, when I worked as consultant, SAP was a minor businnes in the total of the company.
And I had to fought over and over with my  former boss because he cannot catch up within the difference between a SAP development and a .NET or Java one.

In SAP you cannot start without a clear functional analysis because SAP developments are more functional-focused than any other complex .NET devs.
This because SAP is a damn ERP, with a bunch of connection more or less known, and the AGILE method can be more dangerous than  useful.

The more I think about this and the more I find that AGILE cannot fit in SAP world.

[former_member182550]

No,  not disappeared,  passed down the chain to us Abappers.  The work that should be put into a functional spec gets put into countless re-writes.  As I said above,  Agile is useless for anything but the smallest piece of development.

[bpgreen1]

Hi Paul & Nandor, I certainly don't disagree with you about the functional consultants being vague and divorcing themselves from responsibility - we've all been there and it will continue unless something is done.

I'm also not saying that agile is just for us ABAPers. If the whole project (functional, UI coders, stakeholders, whoever...) gets buy-in then all parties have that responsibility.

And lets not kid ourselves that the func specs are EVER finished or set in concrete.

Business changes mean that some changes are inevitable. Even those changes where they didn't think about the whole picture from the start. I just want to make those changes as fast as possible so the business can start getting the benefits. If they change their mind later for a new column on a report or a bit of altered logic in an interface then they would have to justify that to their superiors to get a change (and budget for my time) approved. So apart from my frustration at changing the same code *again*, agile means the business will get their improvement without having to wait for the next quarterly release.

Dare I raise DevOps as a topic for discussion next?

P.S.
I do like that we can have these convs on SCN without them turning into name-calling or worse. It gives me great confidence that senior (not in age, but experience) ABAPers really do think about the future of our language.

[Patrick_vN]

An interesting point of view and discussion. In my opinion it will only work if the agile methodology is applied to the entire project, and undersigned by the whole of the team working on it (customer included most preferably).

For while the Agile ABAPer in an agile project might be happy, he's likely to turn into the scapegoat in the other cases..

[former_member186905]

The most important lesson I learned from the agile movement is to ask for feedback often and regularly. And although that's best done in an agile project, you can do this in a waterfall style project as well - without telling anyone that you are trying to "agileize" your environment 🙂

[bpgreen1]

"Agileize" - new verb of the day :smile:

[former_member187315]

I am hearing about agile a lot everywhere but i did not have a clear picture of how to adopt it in my projects.

Agile sounds interesting and many people are interested to explore it.

[former_member182550]

Hi Venkat,

Unless it's really really small and can be specced on the back of a stamp IMHO you really should not Agileize (See above... :wink: ) your projects.  It just brings a whole load of re-work.

Rich

[former_member187315]

Hi Richard,

I take your point, it is just my curiosity to know how agile will make change in my project development against the traditional model. :smile:

Venkatesh

[Former Member]

Nice one from Barry.

my 2 cents on this.

With fixed no. of user stories per sprint being the norm,

1) Along with development, It would help to have approvals & migration (Dev to QA) too in agile mode. Hope there's some support to this with the CTS+ mode.

2) Like Uwe mentioned GIT like branch support for ABAP Code. Isn't it time, we leveraged the existing versioning & build on it. The current way to use SVN or MS Visual Source Safe is a bit monotonous.

[former_member182550]

What's wrong with using standard SAP version control ?

Rich

[UweFetzer_se38]

The objects are locked. Not possible that two different teams are working on the same object and merge the changes later.

The teams currently have to wait until the whole development cycle of one object is finished until they are able to start their development. Not really agile.

[former_member182550]

And thus new problems arise.  What happens when two teams not only are changing the same object and are also making almost identical changes.  (How often do you have projects communicating their changes with each other ?).

To me,  that is a potentially dangerous thing and whilst not particularly an Agile thing,  another nail in it's coffin lid.

[UweFetzer_se38]

Sure this is a problem. Same in all other (non ABAP) developments, especially in Open Source projects. But this should not be a reason to NOT use a GIT-like tooling.

[former_member182550]

I'm not against GIT like tooling - I was using the same type of version control years ago - SCCS and I absolutely loved it.  What I am against is the idea of Agile in itself.

Rich

[former_member186905]

From my point of view the standard SAP version control facility makes it very hard to group changes: Imagine that for implementing a feature you have to change 5 methods in different classes. If you want to roll back your changes later on you have to go manually into all 5 methods and reset the implementation to the previous version. I would highly appreciate a way of grouping changes in different objects into a single "transactional unti", like in other version control systems.

[former_member186905]

Hi Richard,

I feel that you somehow get the whole idea of "agile" wrong (like many others, unfortunately). If you check out the http://www.agilemanifesto.org/, you won't find any prohibition of grouping work into meaningful packages or of some upfront thinking about the system architecture.

However, some people seem to equate the statement "upfront analysis and design of 100% of the requirements not recommended" with the statement "no upfront analysis and design allowed at all", which is not correct from my point of view.

And, BTW, where did you get the idea from that agile practices prevent developers from gaining an understanding of the big picture?

Of course the problems you mention can (and do!) occur in projects. But this is not a problem of "agile" itself but more of how "agile" is understood, applied and maybe communicated.

[former_member182550]

I have worked on various 'Agile' projects which is where I am drawing my experiences and conclusions from.  And Yes.  Agile practices do prevent seeing a larger picture because you are presented with a spec for just that sprint.

Rich

[former_member182550]

Precisely,

Give the developers a sheep.  We've done our job.  They can produce the camel.

Rich

[jemil_victoria]

Barry that was a good article .

I also Agree with Richard Agile is not good for Large scale Companies.

as he said Project managers and everybody else must have a "vision of the big picture"

and well said Simone and Andreas.

[GreggHinkle]

Hi Barry,

I am an supporter of Agile, however what is frequently left out when implementing Agile (particularly Scrum) is the necessary agile development practices. Some of these practices are:

• Integrated Unit Tests using ABAP Unit
• Refactoring
• Continuous Integration
• Pair Programming

Also what is needed for the use of the Object Oriented programming paradigm (ABAP Objects). Now you can technically still be agile using old school procedural ABAP, but implementing the necessary agile development practices works better using ABAP Objects. This is the stumbling block that I have seen most commonly. In companies that have old SAP implementations, there are developers who do not want to use ABAP Objects and those who do, end up writing their classes like programs in which they end up with procedural objects.

So to be truly Agile, the agile development practices need to be followed as well as the project management aspects of agile. Also using proper Object Oriented development practices (ie SOLID principles) will help.

[former_member182550]

Hi Gregg,

From my experience it doesn't matter what technologies or methodologies you use.  Agile is ok only for the teeniest of developments.  Anything else needs to be as near fully specced as possible before starting.  One thing though that has just occurred to me is that if you do not have a complete spec,  how to you prevent scope creep ???

Rich

[GreggHinkle]

Hi Richard,

From my 25+ years of development experience including 14 years in the SAP arena, I have found that the concept of the complete spec for large projects is a myth. In large projects using traditional methodologies the requirement gathering, blueprinting, and specification creation activities can take months if not years to complete when trying to be complete up front. The fact is that they never are complete since there are always unknown requirements, things that the business didn’t think of, or unforeseen technical constraints, issues, or dependencies. So what ends up happening is that depending on where the development is at a particular time, these additional requirements and issues are included or the business is told that is it too late. Adding these new requirements to a project where the date has already been estimated based on the previously defined requirement risk the delivery date and make the developers work many extra hours. Telling the business no to important requirements that were discovered late fosters bad relationship between the business and IT since the business is not getting what they want. In addition technical problems are typically found once development starts that require the development to change instead of performing it the way it was written in the technical spec.

So with all of this change that occurs, why fool ourselves in thinking that these specs are complete when they never are.  With agile you still gather requirements, do blueprinting and create specs, but you don’t spend as much time trying to get everything complete upfront since it is known that change will occur regardless of how thorough you think you are. The product owner works with the agile teams to make sure that the most important or foundational things are completed in the first few sprints and they may change or add things as they see results along the way. At the beginning of each sprint the developers will collaborate to come up with the technical design of the items which will be delivered during that sprint. Now if the product owner adds a bunch of stuff it may affect the end date, but instead of just saying no, changing the end date or making developers work mandatory evenings and weekends, conversations can be made with the product owner to remove other features that have not been started that were initial requested for new ones that were discovered later. This continual reprioritization of item to be completed for each sprint helps insure that the developers are working of the most important things first and features that eventually are seen as not important or unneeded might not be delivered saving development time.

I could go on concerning procedure vs. object oriented development and other development practices such as Unit test, refactoring, continual integration but I thing that I have put enough people asleep already. :razz:

[former_member182550]

I did say 'as near fully specced' as possible.  I know end users will look at stuff and say 'wow - can it do that - can we make it do this ???' but then it's down to a good project manager to prevent scope creep of that like.

Also,  a lot of what you talk about in terms of feature prioritisation is also spoken about by Steve McConnell in his book Rapid Development and continually changing priorities ends up with lots of partially completed code amongst other things,  changing of end dates, mandatory overtime,  forced weekends etc etc which eventually an out of control project boils down to doesn't do programmer moral any one bit of good.

Perhaps it was badly managed Agile projects I was on but all they caused was grief.

As I keep saying - If you know what the future is you can plan for it from the start rather than bolting on something that has been cobbled together or having to go through a re-write because what you have got is not the most efficient way of doing it.

Rich

[former_member186746]

Hi Rich,

I disagree (partly).

The functionality or minimum viable product should be as fully as possible specced, not the end product.

I have worked on a project where an information analys team worked for a year spending 1M Euro to come up with an almost fully specced design. However in practice we found out that it didn't make a lot of financial sense,

For instance customizing and developing all 7 different flavours of one specific functionality cost more than 200 hours. We found out that 2 of those made up 99 percent of the functionality, dumbing it down to flavour 1, flavour 2 and the rest was less than 40 hours work.

And on the other hand I worked on a big project using SCRUM, however the sprints were nigh impossible to demo to the users because there was no functionality to show them, just some empty screens, or technical stuff.

My experience from these instances is that I find it very important to have the basic functionality well/fully described and built before showing it to the end users.

After this has been done, and after they have played with it and thought about it, then it makes sense to develop the full production viable product through agile

Cheers, Rob.

[GreggHinkle]

I have felt that same pain in both traditional and agile project that turn into death marches for the developers. But this is also where the agile development practices come into play if used correctly. If you have a traditional procedural ABAP program that is a couple thousand lines long, making additional changes to that can be very impactful depending on the type of change it is or if it requires the program to be re-engineered. Using an Object Oriented approach where the classes are properly designed (key word, properly) and follow SOLID design principles, changes can be made easier especially if you have coverage with ABAP Unit test to verify that your new change didn't break existing functionality. These Unit tests can also be setup to run on a daily basis to insure that other work done has not broken existing functionality. Also continuous refactoring of classes is a must to insure that the classes stay focused and keep with proper design principles. Refactoring must be a planned part of every sprint or else the code ends up getting fat and violates proper OO principles. These development practices are what is usually left out of agile projects which causes problem with changes. In Robert Martin's book Clean Code, he illustrates how these proper development practices allow for better maintainability, reliability, and ease of future change since change is always constant.

The trick is trying to get developers who are resistant to change to use these practices and not take the easy way out just to save time. It is this mental paradigm shift and not the technical aspect that is the hard thing for some developers grasp. If you think and work in the same manner as you were previously while doing agile, you will fail. Just breaking your work into time boxed sprints will not make the project successful. All that creates is a project of iterative waterfalls which is actually worse than before.

[former_member182550]

<chuckles>

Resistant to change ???

<roflmao>

Moi ?????

:lol: :lol: :lol:

[GreggHinkle]

Rich,

I wasn't referring to personally but instead to developers and consultants that I have seen in my own organization that have been resistant to change and how that impacts the success of an agile project. The fact that you actively post on the SCN and engage in conversations shows that you are interested in learning new things, sharing, and are not closed minded. We who do so are the minority of developers out there however. The other ones are who we need to influence.

[former_member182550]

Gregg....

Meet the original Dinosaur.... (as I have been called).

Please don't take offence at me laughing at myself - it's a healthy obsession!  You have no need to offer an explanation!! 

[bpgreen1]

Rich and Gregg; Wise words from both you guys - thanks for continuing contributions to the discussion. It certainly gives me encouragement that us more 'seasoned' ABAPers are out there and giving to the community.

[Former Member]

Üdv Nándi, :smile:

Going agile doesn't mean you don't have clear specifications (this seems to be a common misconception). Acceptance criteria for user stories are still clearly defined but the chunks of development are smaller and thus feedback is quicker. Big upfront design is missing but that's actually a good thing because it never works well in real life as others have pointed out.

I agree though that it only works if everyone is signed up for the quicker cycles including business participants which can be an issue.

[SimoneMilesi]

"Big upfront design is missing but that's actually a good thing because it never works well in real life as others have pointed out."

Different experiences, different opinions.

I found extremely difficult to work on something without the big design defined and explained.