When we multitask, we switch back and forth between one task and another and end up being less productive than if we focus on one task and get into a “flow zone.” In the world of antiquated computer speak, you'd say we're “thrashing.” Today we call it context switching — and it's something we all want to avoid.
Scrum teams and squads in particular must minimize context switching, in order to deliver on the frequent deployment schedule that is a key component of Agile development and DevOps. When organizations meet developer teams where they are at, they give them the tools they need to be successful, productive and happy. Developer teams can then keep pace with releasing software at speeds required to stay ahead of the competition with confidence.
Vendors and software companies that are building these tools aim to streamline this process. From portals to gateways to CI/CD platforms, it’s about making the jobs development teams and individual developers do easier, alleviating complexities and barriers to getting their jobs done.
SDLC and quality tools have gone from being point solutions and highly distributed to more integrated, consolidated and supported by platforms of tools. This centralized and collaborative approach for tools has happened in the past in areas like business intelligence (BI), data management and infrastructure management. We are now seeing this shift in the Agile/DevOps space.
For a long time, engineers — true craftspeople — have worked with specialized tools, specialized event-driven architecture, and specialized open-source collaboration solutions. Today’s engineers are faced with getting work done faster, all while accessing as many as 10 or more different systems with the related 10 or more different passwords. This makes their job harder. When there are complicated hurdles and roadblocks, the task is often missed. It becomes easy to quickly get into the cycle of not doing that particular job.
Streamlining the Developer Toolbox Goes Beyond Efficiency
Today, teams are faced with lots of choices and complexity when it comes to collaboration and productivity tools. However, the faster, easier, and more streamlined their toolbox can be, the better and more productive they are.
How does an organization set their Scrum teams and squads up for success with the most efficient toolbox and systems possible? It first begins with a cultural shift and adoption of a pledge to consolidate tools by teams and the company, while ultimately having your service providers and vendors helping to make good on that promise.
This is particularly important as teams have gone remote over the last two years, many not having the same tools or collaboration platforms. How do you start to share docs and combine applications to ultimately create a product — when those water cooler conversations have vanished?
Here are three must-dos to minimize context switching:
- Take inventory: First, take an inventory of every tool that every scrum team and squad are using. If one team is using one tool and another team is using a similar tool, come together and compare features and uses, and start to harmonize. Lunch and Learn programs are great ways to begin these conversations.
- Consolidate these complex systems: Ultimately, for similar tools being used, retire one and drive enterprise adoption of the other. This streamlines the management of these systems. It allows Scrums and squads to collaborate better, and it allows teams to start building a harmonized level of reliability into your systems.
- Consult with tool vendors: For each tool you’re using, bring in a vendor representative and have the technical solutions engineer and your architect design and plan the future of that system. Work with your vendor to envision a future that meets your strategic plans as well as your daily tactical needs — use the vendor to help you see the future of your infrastructure. With products generally retiring every three to five years, just because you are using that tool today, doesn’t mean you’ll use it over the long-term.
Particularly with remote team members, it’s even more imperative today to do the inventory, do the tool comparisons, find the feature similarities and differences, and start to standardize in order to ultimately collaborate in the creation of great product. Effective and efficient collaborations make happy developers, and it ultimately frees them up to create and build with enthusiasm.
Related Article: Strategies for Implementing Continuous Integration/Continuous Deployment
Tool Standardization Isn't Just About Efficiencies
Standardizing on tools and systems is not just about efficiencies. It’s about delivering quality at speed. It’s about reducing team frustration and barriers to success. It allows engineers to have less context switching, which makes them more productive and happier. Because once engineers context switch, it’s tough to get them to come back. Moving out of the workflow is frustrating, disruptive and unproductive.
So how can teams build products faster, at a higher quality, while better collaborating and delighting customers more, so your tool will get used — no matter what you are building? This standardization philosophy, as a best practice, means doing the hard work that’s required, and in the end, the reward is higher with better teams and better products.
As vendors step back and look at the big picture, it’s all of our responsibility to create truly frictionless experiences for everyone, including employees, partners, customers, shareholders and stakeholders — and that can be accomplished with standardizing on tools to minimize context switching.
Learn how you can join our contributor community.