skip to Main Content

Mindset Remote Development

Recently, many in the SAP development community has transitioned to remote work at a scale we’ve never seen before. At Mindset, we’ve experienced this change along with most of our customers, and have grappled with the question of how we keep development projects humming along.

We are extremely fortunate that a significant majority of our work has been done with distributed teams for years. This has eased our transition immensely, making it invisible for many of us. Even so, we have had to make adjustments as we moved towards 100% distributed teams. I want to share some of our processes, some of the changes we are making, and some of the practices we already have in place that may help your team.

Mindset’s process

Mindset’s end-to-end development process begins with Design Thinking, transitions into agile development, and then move into our 360° Deploy methodology.

While each of these steps is important, I want to focus on design thinking and agile delivery. Especially in this discussion. Each of these has 4 high-level steps. Design thinking moves through empathize, define, ideate, and prototype stages.

Meanwhile, agile delivery is predicated on backlog refinement, sprint planning, sprint execution, and the agreement on the existence of a shippable product at the end of a sprint.

Our design thinking process has been the most hands-on and in-person of the processes that make up our development methodology and was the most in need of an immediate enhancement to meet the needs of the current working environment.


The largest and fastest change we needed to make was to our design thinking process. We’ve done both fully and partially virtual design thinking before, and done it successfully! This has included fully remote sessions as well as the inclusion of remote participants. However, we’ve always seen real value in generating excitement and camaraderie through in-person participation in design thinking sessions.

Dan Flesher and Jen Gnerer, our design thinking and design gurus, took up the challenge of generating that same excitement and interaction in a fully virtual environment. By incorporating learning from our previous virtual design thinking experience and our extensive in-person design thinking experience, they’ve developed a framework and tools to consistently drive a compelling and valuable virtual design thinking session. Dan outlines the process and tools HERE.

On the agile delivery side, our teams haven’t needed to make nearly as drastic a set of changes. Mostly, we’ve needed to help those few who are more used to in-person work make the transition to remote, and simultaneously double down on some of the practices we already have in place.

Things we’re just doing more of:

At Mindset, we have recognized for years that finding the best person for a job and finding someone who can travel (or even commute) are often incompatible goals. Due to this, we adapted our agile process to accommodate distributed and time-shifted teams. Our adapted process is based on open and constant communication channels, dedicated time for the team to collaborate, and a regular sprint cadence. A few key points:

  • Daily standups

    We use Zoom or switch to other conferencing systems if participants require it. We prefer to use video in these calls so that everyone is engaged and starts to make more personal connections.

  • Daily collaboration time

    Usually, after the standup we will reserve between 30-90 minutes for team collaboration. The use (or disuse) of this time is up to the team. However, we keep the time open in case we need to be able to pull the whole team together. This reduces the need for developers to spend too much time being calendar jockey. If the time isn’t needed, everyone can get back to their work.

  • The project record, agile board, etc, are in Jira

    For many customers, we use a different tool (Github, Azure DevOps, we’ve seen it all), but the concept remains the same: Everything goes into the tool. Acceptance criteria, status, comments, test results, new requirements, etc. For a distributed team, none of this must be stored in physical artifacts, like a whiteboard scrum board. For teams that are only partially remote, this is a constant temptation and must be resisted or you turn your remote team members into 2nd-class citizens and the whole structure quickly breaks down.

  • Project communication is in Slack

    Our development teams each have a dedicated Slack channel that is the central clearinghouse communication. This allows team members to stay apprised of what is going on in the project. In-person discussions still happen; even then, try to summarize in Slack: “Mary and I were just talking about the toolbar design and we think it might make sense to …”

  • Ad hoc video calls and screen sharing

    When that Slack discussion surfaces something that we need to look at more closely, we jump on a quick 1-1 Zoom call to share screens. We engage in some more dedicated time on an issue. Having that call one click away is the equivalent of “I’ll drop by your desk”. Quick and efficient.

  • DevOps

    The way that DevOps manifests in the development process is mostly in terms of development practice and automation. Automation helps a lot for distributed teams, but the biggest help is the consistency of practice. This is your chance to double down on your distributed version control methodology. It’s your chance to ensure all developers are on board with trunk-based development, git-flow, or what your team has chosen. Get those automated checks and tests set up for pull requests!

Hopefully sharing what we do at Mindset and our recent changes plant a few seeds about how you can adapt your teams to this new environment. If you’d like to talk more about this, or if you want to take advantage of a virtual design thinking session to simultaneously build team cohesion and tackle a thorny problem in your SAP implementation, be in touch!


If you’re interested in DevOps, we invite you to register for our virtual DevOps day on April 24th.  Register HERE.  This is a chance for those pursuing DevOps strategies for their SAP development organizations to come together, learn, and discuss together.


If you are interested in viewing similar articles, visit our blog, here

View our LinkedIn, here

Back To Top