Skip to main content

Agile in S4/HANA implementation

Last post 03:22 am May 1, 2021 by Soumyadeep Mishra
3 replies
11:39 am April 28, 2021

For the past few years, all of my Agile engagements were brownfield web dev projects delivering pieces of software every 2 weeks and wherein I double hatted as a scrum dev and a scrum master (yep, not advisable). Right now, I got a new long-term engagement (pharma industry) as a full time scrum master which, to be honest, is quite an uncharted territory for me as this one is:

- a greenfield

- a different platform (S4 HANA) and

- the outputs (for now) are more on process designs (fit/gap analysis followed by workshops)

 

I'm in a shadowing phase currently and from what I observed:

- The project is utilizing full SAFe config (which I find quite top-down heavy) and SAP Activate methodology

- 1 scrum master handles 3 to 4 teams (how does one teach focus and lead by example in this setup?).

- Though teams are setup cross functionally, the team members are mostly external SAP specialists, consultants from one of the big 4 accounting firms, and internal hires (how do we encourage T-shaped skills in this case?).

- Team members are also vastly distributed (most in various US locations, some in Asian countries) and only get to meet and collaborate in few certain hours in a day (the hours I am awake are the hours that most them have already gone to bed so how can I serve the team apart from the basic ceremonies?).

- "Daily" standup is twice a week only due to above situation. My fellow SM's echoed that finding common schedule is already a challenge in itself.

- No sprint review, only workshops at the end of the 6-sprint iteration (or whenever there's a need).

- Sprint planning occurs on the last day of current sprint.

- It's a challenge to set 1on1's due to the size and "dislocated" setup that we have.

- It seems that the org sadly and obliviously setup the scrum master role to only fulfill the basic scrum ceremonies.

 

However some of the good things I observed and are worth mentioning are:

- The client invests a lot in employee welfare

- Attrition rate is low

- Leads and managers I've interacted with are warm, kind and the type who listen (it seems most of them are already aware of the above however, at times, one can only do so much)

 

Anyone who has the same experience? How was it and what do you advise in this case?


04:55 pm April 28, 2021

If the organization "sadly and obliviously setup the scrum master role to only fulfill the basic scrum ceremonies", Scrum outcomes cannot be expected. Then again, if they are implementing SAFe -- which is a quite different framework -- perhaps Scrum outcomes are not really anticipated at all. Your organization may be quite happy for people to observe "ceremonies" rather than the inspect-and-adapt events of Scrum, for example.

My advice is to find out what outcomes are really expected here. Also, if there is a misplaced conceit within the organization that Scrum is being implemented, for whatever reason, then perhaps you need to shine a light on the gap between the Scrum Guide and current practice. The 5 Scrum Values are always there to fall back on.


05:04 am April 29, 2021

Appreciate the response, Ian! I just had a quick meeting earlier with my RTE and PO and took the chance to share a gap I've observed between the guide and the sprint planning in place (which occurs on the last day of the sprint along with the review and retro).

I mentioned that with the current practice, we may impact the focus of our team members since their primary concerns on the last day are the tasks for the current sprint (catching up on their remaining stories, helping team mates so as to avoid spillovers, preparing for the retro discussion) and that part of our role as an SM is to support the team's success by empowering them to focus on the work at hand. I've had experience as a scrum developer so I know how it feels and how chaotic it can be during the last few days of a sprint so I had to voice this out.

The PO and RTE aired their side (primary reason are the time zones and scheduling) so it's implied that we have to stick with the current process. The RTE kindly advised that I just also need to be flexible and creative, that they already are aware of the situation and that we may not be always able to follow the Scrum Guide.

"Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum, covers up problems and limits the benefits of Scrum, potentially even rendering it useless." --- this is where my mind drifted when the RTE shared her last line.

My next item is your other advice which is to discover what outcomes are expected here :) Again, thanks a bunch!


03:22 am May 1, 2021

Hi @Mai S

Although this is a very context-specific situation but I can share some of my thoughts based upon some similar experiences I have had previously. Again these are just thoughts and opinions!

- The project is utilizing full SAFe config (which I find quite top-down heavy) and SAP Activate methodology:

SAFe concerns itself more towards the scaling part and resolving dependencies/ constraints & risks while working with a number of Agile teams in a Program/ Portfolio or Large Solution set up. Looking at your comment, it looks more of a team-level issue. We first need to address the challenges that we have on a team-level and if they're following Scrum, we need to see whether they're acting as a Scrum team or not, in the first place.

 - 1 scrum master handles 3 to 4 teams (how does one teach focus and lead by example in this setup?).

I completely agree with @Ian Mitchell on this point that in this case, the Scrum Master would just be expected to 'run' the ceremonies and he cannot possibly help the team in realizing the Scrum outcomes via transparency, inspection and adaptation. You need to observe the challenges, see the impact of this on your ability to help the teams and bring this to the note of the Senior Management. Again, Transparency is the key here. If they are still fine to continue with this setup, I dont think there's much left for you to do in that case. You would have atleast aired your concerns to them; if in future, issues happen to any of these teams and they're not getting the expected outcomes, they would know that you have already raised the red flag earlier.

- Though teams are setup cross functionally, the team members are mostly external SAP specialists, consultants from one of the big 4 accounting firms, and internal hires (how do we encourage T-shaped skills in this case?).

In ideal sense of the term, your team members don't really need to be part of the same organization for you to be able to help them being cross-functional. As you'll be working with the teams on a daily basis, you can bring forward the gaps they may have in collaborating closely to solve their problems; the challenges of having an 'us versus them' mentality which is imparing the transparency and hence, may limit their ability to consistently achieve their Sprint goals. If you can make them believe that your intentions are honest and you're trying to help the team achieve the Sprint outcomes and not just being a 'flag-bearer' of your respective organization, they should realize that. Again, however, since you need to be a Scrum Master for 3-4 different teams, it would be a challenging proposition to be able to do any real facilitation exercise like these, other than to just run the ceremonies.



- "Daily" standup is twice a week only due to above situation. My fellow SM's echoed that finding common schedule is already a challenge in itself.



We need to put our step down firmly for some of the biggest discrepancies in the team. Not having a Daily Scrum is one of them. Daily Scrum can just not happen twice a week...period. I think a Scrum Master (or group of them) should be given the required 'credentials' to work with their team members to discuss and figure out a common overlap time for members belonging to all the different time zones, even if that means only for 15 mins per day. It can be start of day for one and end of day for another, but thats fine. Eventually, if the team members are not able to share with each other whether they're able to make progress on achieving the Sprint goals on a daily basis, this is going to severely limit your ability to timely facilitate the removal of any impediments team may face.

 

- No sprint review, only workshops at the end of the 6-sprint iteration (or whenever there's a need).



Not having a Sprint Review session at the end of every Sprint will again severely restrict the ability of the team to be able to showcase any real progress or value being achieved each Sprint and get valuable feedback. In case the required stakeholders are not available every Sprint-end for a Review, team can at least showcase all the completed and non-completed work items to their PO (as & when they're done and not wait till the end of Sprint, in this case) and get some valuable feedback from him/her. In cases like this, the PO should act as a business representative and should be able to proxy for all required stakeholders.

 



- Sprint planning occurs on the last day of current sprint.



Even if it must be scheduled in this way, a Sprint Planning session for the next Sprint must happen after the Sprint Review and Retrospective sessions for the current Sprint, else it will not be productive enough for the team.



 


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.