ABAPers, how is your team work organized?

[Jelena]

I'm looking for some examples of how different ABAP teams organize their routine work. In particular, I'm interested to hear about small teams (<15) but feel free to share any experience. Specific items of interest:

1. Assuming everyone has some sort of a ticket system, is it in any way interfaced with SAP? If not, do you reference tickets in some way when making changes (e.g. in CHARM or in transport name)?

2. If you use CHARM - what is your impression? Is it helpful or rather just annoying?

3. If you don't use CHARM - how do you manage changes?

4. Do you do code reviews? If so, what is your process like and are you happy about it?

5. Moving transports to QA - do you have any special process or any restrictions?

6. Any unusual processes that you have (had) and especially like or dislike.

Reason for the question: I've been a solo developer (with occasional help from consultants) for several years but even before that I happened to work in the teams where we just had good relationships and sort of a natural flow without any formalities. But currently I'm looking to improve organization in a very mixed team and simply don't have that kind of experience myself.

Thank you!

P.S. Some good information on ABAP work can be found in this post but my question is more about the organization and process.

[keohanster]

Hi Jelena,

We are a relatively small ABAP team... 4 people and one manager(who also does coding). Our tickets are not integrated with SAP, but our manager assigns them to us based on our application area of expertise.

When making changes, I always refer to the ticket in the comments of the code (please, don't anybody hit me). I also refer to the ticket in the transport name.

We do not do any code reviews, and I think we all wish we did. And I wish I knew of a way to start them...

Our transports are assigned to the appropriate Business Analyst, and we use (wait for it...) workflow to route transport proposals to the Basis team and then back to the BA for promotion to Prod. The BAs obtain sign off by the business area from QA, and this is attached to the transport request from their inboxes. Transports are moved to Prod once a week, and of course, there are provisions for emergency transports.

We've been live for over 15 years. In that time, the accumulation of code that may or may not be obsolete (and may not be written extraordinarily well either) has grown. It seems like it would be a whole-team effort just to get rid of this old code... and then of course we'd find out that it is extremely important to run this one report every 15 years and dammitall.

Hope this is helpful somehow...

Sue

[Jelena]

Thanks, Sue! Any information is helpful.

To clarify, your transport owners are actually BAs, not ABAPers? Like you go to SE01 and see BA names? Or did you refer to the transport assignment elsewhere?

[keohanster]

The development/correction is released by the ABAP, and then we change the owner of the Workbench request to be the responsible BA. When they release the request, it creates a transport proposal (and some more docu is involved) and the WF routes it first to Basis for import to QA, then back to the BA (while they wait/get confirmation to Prod).

So each transport has the developer on the correction, and the responsible BA on the request.

Hope this helps...

Sue

[Lokes]

Hi Jelena,

Ours is a team of 8 members( incldues QA people also) with one manager who will reagularly assign tickets and the below is the response:

1. We use SAP SOLMAN to create, assign tickets and get it fixed and tested by QA Team.

2. We do SYCM, ACT checks regularly and we fix all prio 1 & 2 points raised by SYCM & ATC checks.

3. We create TOC and request our basis team to get it transport.

Thanks,

Lokeswar.

[Jelena]

Thanks for a reply! What's SBD? I googled it but the top links are some kind of a wrist wrap company and an Urban dictionary article. 🙂

[nabheetscn]

Hello Jelena

We work in a team 15-20 people in a very controlled compliance driven environment, where lot of importance is given on processes, documentation, regulations etc.(Pharma client). Please find below response for your questions

1. Assuming everyone has some sort of a ticket system, is it in any way interfaced with SAP? If not, do you reference tickets in some way when making changes (e.g. in CHARM or in transport name)? -> We are using SAP Solution Manager(ITSM) for ticketing as well change management. It is already integrated with SAP. Their are few systems which are very old kind 4.6 etc. which are not connected to the Solman but still we use CHARM for documentation purposes. For such system the CTS contains the Change document number and in Change document the CTS is updated in the text log.

2. If you use CHARM - what is your impression? Is it helpful or rather just annoying? CHARM is definately helpful, since we control everything via CHARM. The documentation review, code review, movement to quality, implementation approvals, effort estimates etc everything is controlled via CHARM. The only complaint we have with SAP Solman is it is slow, we are working on 7.1 CRM WebUI.

3. If you don't use CHARM - how do you manage changes? NA

4. Do you do code reviews? If so, what is your process like and are you happy about it? Yes we do code reviews, the code reviews are controlled via Change documents. The overall flow is like you have a ticket->CR(Change request) -> CD(Change document with CTS related to CD). So initially the CD is in development once you want to move to Q you change status to code review. Then automatically Source code inspector is run once the status is changed to code review. Reviewer can approve/reject the changes, this goes on till CD is approved by Code reviewer.

5. Moving transports to QA - do you have any special process or any restrictions? - CHARM does it for us. First code review is completed and then status of CD gets changed to Document review where all documents(FS/DD/OQ etc.) are checked. Once documents get approved status is changed to In Testing where a background job is running every 15 minutes for such CD to move changes to Quality system automatically.

6. Any unusual processes that you have (had) and especially like or dislike. Something which i don't like is if during development by mistake some objects get locked in a CTS in order to remove them we need to ask another team as we don't have authorizations:(. Second is we don't have debug change in quality which is another frustrating thing.

I hope it will help in someway or other:)

Thanks

Nabheet

[Jelena]

Thank you, Nabheet! This is very helpful.

I'm curious who is responsible for CHARM support and maintenance in your team? Do you have a designated person/team for Solman? Do you by chance know if there is a lot of "care and feeding" involved?

[nabheetscn]

Unluckly i mange both technical and solman team😂 We have support team for new requests or set up or issues like CD not moving forward. Overall the workload is less it is quite stable. We have been using it for around 4+ years at least

Thanks

Nabheet

[BaerbelWinkler]

Hi Jelena,

here are responses to your questions (and thanks for linking to my discussion thread!)

We have a small inhouse development team (nominally 5 people) supported by several and long-time external consultants/developers. Some development is also done fairly independently in some subsidiaries.

1. Assuming everyone has some sort of a ticket system, is it in any way interfaced with SAP? If not, do you reference tickets in some way when making changes (e.g. in CHARM or in transport name)?

==> we do have a ticket system and changes related to a ticket are expected to show the ticket number in the transport title. This is only used for actual fixes where something or other is broken

==> for new implementations or changes requested by the users, we make use of Atlassian's JIRA to track the incoming requests and each request gets an ID assigned, something like 18-0815-C which is then expected to show up in the transport title

Needless to say, even though this requirement to have an identifier in the transport title is stated in our guidelines it still doesn't show up in many transports. I have experimented in a sandbox system with putting some checks in the relevant BADI but this hasn't made it to the live dev-systems thus far.

2. If you use CHARM - what is your impression? Is it helpful or rather just annoying?

==> we don't use CHARM

3. If you don't use CHARM - how do you manage changes?

==> we just track them manually with the help of JIRA

4. Do you do code reviews? If so, what is your process like and are you happy about it?
==> short answer: „No“ - The long answer to that question is in the discussion you link to

5. Moving transports to QA - do you have any special process or any restrictions?

==> developers are responsible to release their transports to QA and mostly also to release them to PROD. The decision of when to do that happens between the developer, the responsible process team member and after the user-department has signed-off on the changes.

==> (added) transports released from DEV make it into QA every 15 minutes automatically and the transport-queue for PROD is filled once per week with imports going in in the evening

6. Any unusual processes that you have (had) and especially like or dislike.

==> developers have to request special users for dictionary tasks which then are done in a central dev-system which feeds into two dev-systems where ABAP-work is done. These requests are released to production by the basis team after checking that they went into the QA-system without issues.

==> transactions need to be requested from the basis team as the TCode-names have a bearing on general auth-checks which are done in addition to the ones required in the programs

[Jelena]

Thank you for an answer! So are you saying you're using Jira and some ticket system on top? Are they integrated in any way? I kind of always thought that Jira was a ticket system but I might have gotten a wrong impression.

[BaerbelWinkler]

Well, we have a ticket tool which is used for everything, not just SAP- but also PC-, networking-, you-name-it-issues. And the tool is, to put it mildly - a nuisance and as non-intuitive to use as it can get. So, if there‘s really just a bug-fix in some Z-code needed, this tool is used. But as soon as it gets more complex, or is clearly something new the users want - instead of something malfunctioning in need of a fix - they have to request a proper change and this then gets processed and tracked via a JIRA-issue. Once upon a time, JIRA may have started life as a ticket-tool but by now I think it‘s a lot more than that. It‘s highly customizable and ideal as soon as you need tracking and dashboards and what-not. We have some fairly creative stuff set up via JIRA (and Confluence) but this might actually be a topic for a blog post or two (if there is interest in that?).

Oh, and no, the ticket-tool and JIRA do not talk with each other at all (and this is not JIRA‘s fault!).

[pokrakam]

Hi Baerbel,

I may be in a minority here, but Jira is my favourite task management tool and it would be interesting to read how other people use it, especially if you've gone the whole hog with Confluence.

My bugbear is that >90% of projects seem to have a hardwired obsession of documenting everything in Word documents squirrelled away in an impossibly complex folder/SolMan/SharePoint hierarchy, never to be found or read again. I'm always advocating something more like Confluence or Wiki-like, so I have a personal interest in the topic.

[BaerbelWinkler]

Hi Mike,

we are then at least a minority of two already!

And, I actually started to draft a blog post about a tool to keep track of testing we put together with Confluence and JIRA. Stay tuned!

And yes, to everything you state about whatever folder/server black-hole documents tend to get stored and forgotten in!

[BaerbelWinkler]

Here you go, Mike: Building a custom-made test tool with Atlassian's Confluence and JIRA

[pokrakam]

🙂

[pokrakam]

I've worked in a lot of teams over the years, and Scrum or Kanban are hands-down winners. Although similar, Kanban is more suited to ongoing work and can be tacked onto any ticketing system by just using the ticket number to reference your task as it travels through it's journey.

Have a read through https://www.atlassian.com/agile/kanban - the example board even includes a code review step. At it's simplest, it's just a matter of having short daily meetings and using a progress board (software or whiteboard) to visualise the workload. There are some serious (and complex) softwares out there such as Atlassian's Jira, but for a trial you can try it out using the free Trello app.

[Jelena]

Thanks for a reply!

Well, I think we've all heard of this (there is even Kanban in SAP purchasing 🙂 ) but how would you implement this in an SAP team specifically?

[pokrakam]

The beauty of Kanban is that it's so easy to understand and use.

It can be virtual using an app, or if your team is all in one location you can use a whiteboard. Draw a few columns to represent the stages and your tasks can be your Charm/Servicenow /whatnot tickets written onto a post-it (just number and title). Tasks move from left to right. Owners can write their initials on it. Daily meetings are key to make it work: Short, sharp, 'standups' where everyone gathers around the board, says a few words about their task(s) and moves it if needed. No more than 15 minutes in total.

Lots of examples on the internet, at it's simplest just start with the example from the atlassian link above (I would add a 'blocked' column).

But you can also add colours or horizontal lanes/elements to represent business areas, owners or whatever. Review the system regularly and change it to suit.

The reason I find it sol useful is that it's so much more visual to see the overall workload, physical space constraints are great at hilighting bottlenecks.

[matt]

1. Assuming everyone has some sort of a ticket system, is it in any way interfaced with SAP? If not, do you reference tickets in some way when making changes (e.g. in CHARM or in transport name)?

Change request number is included in the transport description. There's a release check to ensure that it is there - but no check to ensure that it is the right one!

3. If you don't use CHARM - how do you manage changes?

Servicenow.

4. Do you do code reviews? If so, what is your process like and are you happy about it?

This varies from team to team (I work for many teams in the same organisation).

In some, there's no code review, and I'm not happy about it.

In others you have to deal with the level 1 issues flagged up by ATC. The system is configured to prevent release of transports with level 1 issues. There's no eyeball check, which isn't good.

In yet others, the process was developed by me in another company in 2004, then one of my team members took it to my current client and implemented it there, with some automation. When I release my task, a "code review" task is created allocated to the code reviewer. He/she uses ATC and a custom program to check various aspects. If the code is ok, the "code review" task documentation is updated to say so, and the task and the entire transport is released. if the code is not ok,again the "code review" task documentation is updated with reasons, and a new task is created for me to fix the issues raised.

The only probelm with this last is that the checks enforce a naming convention with prefixes no longer recommened by DSAG nor SAP, and various other checks which actually militate against safe code, or are really just a matter of style. Further, there's no eyeball check for real quality - it's just a check of the so-called formal aspects. Otherwise, I think it's a good code review process.

5. Moving transports to QA - do you have any special process or any restrictions?

ToCs to QA can be made freely for testing, until the final release. We have a tool that generates them automatically. QA import all runs regularly, but programmers (on some systems) can also import manually. ToCs are not permitted to production.

[nabheetscn]

Was it you who implemented this workflow also apart from Batch stuff:) We used it for a long time, but now its all Solman:)

When I release my task, a "code review" task is created allocated to the code reviewer. He/she uses ATC and a custom program to check various aspects. If the code is ok, the "code review" task documentation is updated to say so, and the task and the entire transport is released. if the code is not ok,again the "code review" task documentation is updated with reasons, and a new task is created for me to fix the issues raised.

[Jelena]

Thank you, Matthew! Other than ATC part, it looks very much like the process in my last job (I'll post my experience from there as an answer too). I've been doing some reading on SCN on ATC, this question by 8b889d0e8e6f4ed39f6c58e35664518f is helpful and has a link to the blog as well.

What is the tool you use to generate TOCs? In my last job, I just ended up concocting a quick BDC program that was taking the "real" transport task number, generating a TOC for it and releasing TOC. Would be very interested in an alternative as I'd like to start using TOCs in current job.

Thanks again!

[matt]

Someone wrote the program to generate ToCs. You just choose your transport - it creates the ToC and then releases it. The ToC description used to be the same as the workbench transport, but about ten years ago, the client asked me to modify the program so that last x characters are the source tp number, and the description begins with ToC.

The program doesn't use BDC. We're a bit wild on the frontier - we use unreleased function modules. 😮

[UweFetzer_se38]

We are a team of eight ABAP-Developers + many of internal and external consultants are also coding (with more or less success/quality)

1. Assuming everyone has some sort of a ticket system, is it in any way interfaced with SAP? If not, do you reference tickets in some way when making changes (e.g. in CHARM or in transport name)?

Currently we are using Solman for CHARM, but we are planning to move to ServiceNow this year (not my idea...). Ticket number is in transport short description.

2. If you use CHARM - what is your impression? Is it helpful or rather just annoying?

CHARM is a must, no discussion from my side

3. If you don't use CHARM - how do you manage changes?

./.

4. Do you do code reviews? If so, what is your process like and are you happy about it?

Unfortunately no code review implemented.

5. Moving transports to QA - do you have any special process or any restrictions?

Once a week for normal corrections, emergancy transports for "real" production issues. Three month release cycles for regular enhancements.

During the release process of the transport, ABAP Test Cockpit (Code Inspector) checks on a central ATC server are processed, no transport with warnings are released

6. Any unusual processes that you have (had) and especially like or dislike.

Currently for most of the landscapes we have a 4 system landscape (DEV/QA/PROD + a special test system). Transport of copies are transported to the test system. The QA is really only for QA-release (STMS_QA) of the real transport. One landscape after the other we will change to a real three system landscape starting this year. Don't know yet how we will manage the transport of copies. Looking for a solution in the moment (basis don't want TOC for what reasons ever).

[Jelena]

Thanks for a reply, Uwe!

It looks like ATC acts as sort of a simplest code review in your scenario. I'm curious: do you deal with a lot of code that wasn't written well or is just very old-fashioned? If so, how does that affect your ATC process? If you make changes in such a program, do you update it also to pass ATC check? Or do you make an exception?

[UweFetzer_se38]

There's something called Baseline in ATC. And it works 🙂

[Jelena]

Thank you all very much for the replies! It seems fair to post my own answers based on the last job (which no longer exists, so not a secret 🙂 ).

1. Assuming everyone has some sort of a ticket system, is it in any way interfaced with SAP? If not, do you reference tickets in some way when making changes (e.g. in CHARM or in transport name)?

We used Service Now (SN) globally, the whole IT, including local help desks and multiple SAP teams used it. Just like others here, we put the SN change request (CR) number in the transport description. We implemented a user exit in the transport creation (can be found in Google) that triggered a pop-up with some fields like module name, CR number, etc. Then transport description would be generated using those fields. Of course, this did not prevent wrong CR numbers entered.

3. If you don't use CHARM - how do you manage changes?

We used change process in Service Now. A change request generated several tasks that had to be closed in sequence. When transport was ready for UAT, we'd move it to QA and close the development task in SN.

4. Do you do code reviews? If so, what is your process like and are you happy about it?

There was no one to do a code review for me, unfortunately. I did manual code review for the consultants, at least initially, to make sure it follows our guidelines and general good practices. Unfortunately, sometimes I simply did not have enough time for that, which resulted in some poorly written code going live. Some of it I quietly fixed later when the users requested an enhancement in the program.

5. Moving transports to QA - do you have any special process or any restrictions?

We didn't have a batch job and used STMS_IMPORT (neat shortcut for STMS, takes you right to the import queue) in QA to import the transports manually. Another SAP team introduced us to the TOC concept few years in and at first we thought it was preposterous but then ended up using it a lot. TOCs really helped to cut down on the number of "real" released transports.

Moving transports to PRD: we had two "transport days" per week. On those days, at 4 pm the person responsible for transport to PRD would run a report in SN that showed which CRs are ready to go. There was a transport task in CR with the transport numbers (the ticket owner would fill it in). Those transports were then scheduled for import at 8 pm and an email with the CR list would be sent to the SAP team and local IT managers. Emergency transports would be moved in at any time but still had to go through the whole SN CR flow.

6. Any unusual processes that you have (had) and especially like or dislike.

Initially, we had some incredibly stupid requirements. E.g. after the changes went live, the ticket owner had to close the ticket by 11 am next day or they'd get a nasty email at 11.01 am. And if they didn't do it by the afternoon then a nasty email was sent to the manager. This had no value whatsoever and sometimes people would be on vacation or out sick and couldn't "do the needful" in time. So I suggested we just stop this and the team voted almost unanimously with the exception of the person sending nasty emails. 🙂

Not an unusual process but I liked that we could attach documentation to the ticket in SN and then easily find it by CR # in the transport, if there were any questions. This was very helpful. The drawback is, of course, that you lose the documentation if you lose the ticket system. Which is what happened with our previous ticket system when we implemented SN.

[Jelena]

Closing the discussion without picking one answer since there is no right or wrong one. Thank you, all, for the replies! Appreciate your input: se38 , matthew.billingham , 8b889d0e8e6f4ed39f6c58e35664518f , nabheet.madan3 , susan.keohan , mike.pokraka lokesh.b