Over the last several weeks and months, many of us in the SAP development community have transitioned to remote work at a scale that 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’d like to share some of our process, some of the changes we are making, and some of the practices we already had in place that may help your team.
Mindset’s end-to-end development process begins with Design Thinking, transitions into agile development, and then moves 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 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 a person 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, but 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 a calendar jockey. If the time isn’t needed, everyone can get back to their individual work.
- The project record, agile board, etc, are in Jira – At 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, it is absolutely imperative that none of this is 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 on the project. In-person discussions still happen, but 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 and engage in some more dedicated time on an issue. Having that call one click away is the equivalent to “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 consistency of practice. This is your chance to double-down on your distributed version control methodology, and make sure all developers are on board with trunk-based development, git-flow, or whatever you have chosen as a team. Get those automated checks and tests set up for pull requests!
Hopefully sharing what we do at Mindset and the kinds of changes we have made has planted a few seeds about how you can adapt your own 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 also invite you to register for and attend 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.