Agile in S4/HANA implementation

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.

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!

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.