Switch Communications is a San Francisco based company whose mission is to provide cloud-based business communications systems for the fastest growing, most innovative companies in the world.
Switch.co recently found that their project management software wasn’t fully supporting their software development process. The most glaring pain point was bug reporting, and they needed a single source of truth for their documentation. “People didn’t know how to report bugs, and we needed a better process for follow‑up,” says Hugo Romano, Product Manager at Switch.co.
Tasked with implementing a new solution, Hugo surveyed his development team, and Jira Software was unanimously recommended. He knew Jira Software would be used as a bug tracking tool, but it ended up being used for much more.
Hear about what features Switch.co uses in Jira Software and how those features help them practice “lightweight agile.” Also, learn about the next steps on their agile journey.
Why other tools weren’t making the cut
Previously, Switch.co used Asana to track and plan work, but they felt the need to supplement Asana with a mixture of other tools (Gmail, Google Docs, and Smart Sheets just to name a few). As a result, visibility and organization were major pain points.
To get an idea, here’s how their software development process worked: product development categorized insights from data, user research, industry trends, and feedback loops at the beginning of the quarter into large projects. These projects were entered into Asana, but the development team maintained a separate, more focused, list of development tasks in Smart Sheets or Google Sheets (depending on the team), “because there was no way to easily surface all of our tasks in Asana.”
For example, a project in Asana would be called “Switch.co – Next” with sections divided by the stage in development like speccing, in design, ready for engineering rolled up into that project — a pretty standard waterfall development workflow.
And if there were critical issues (aka bugs) they would be tracked in Asana and always roll up into the ongoing release project (e.g. “Switch.co – Release”). Combining the list of critical issues, projects, and tasks resulted in a list that sometimes reached 250+ items long; as Hugo put it, “a big long list with no structure.”
How bug tracking turned into agile development
When Switch.co moved to Jira Software, Hugo said that “when it comes to process and buzzwords” his team “wasn’t a fan of the word agile” — they just wanted to focus on what was important: setting up a software development process with workflows that worked the way their teams wanted to work. But after using Jira Software, Hugo coined the term “lightweight agile” to describe how his team works today.
Their planning is simple: teams work off of quarterly planning sessions to plan product roadmap milestones. These milestones, which Hugo also calls OKRs (objectives and key results), are then broken down into stories and put into a Jira Software project backlog. Each OKR has a given timeframe, which is recorded in Smart Sheets via a Gantt chart view, and weekly check-ins act as sprint planning meetings where product managers (PMs) adjust the timeframes for OKRs and plan the upcoming sprint.
The quarterly planning sessions and sprint planning meetings are both great agile practices. They provide feedback on how development is doing and how the team is feeling about the development — an important tenet of agile development is continuous improvement for the product which is a result of how the team works together.
Jira Software features that foster agile development
Their work and tracking process is similarly straightforward. Day to day as a PM, Hugo spends most of his time editing individual tasks’ descriptions, having discussions in the tasks’ comment sections, and moving tasks in between statuses to ensure that his team’s board is up-to-date. This might seem pretty standard for a software team member, but without particular Jira Software features, none of it would be possible.
With workflow statuses, for the first time, the entire Switch.co development team can see their work in the form of boards. They’re able to use those boards to build clear and flexible views — they hadn’t found a way for Asana to easily do this.
Notifications are another essential feature. They’re primarily used to inform team members of when a task status changes. Because they’re now notified when a new task is added to their queue, Hugo credits notifications as the reason he was able to eliminate separate weekly meetings with design or quality assurance (QA) teams to discuss new tasks. Also, with all of the information provided on an issue, team members rarely find themselves toggling between other tools, like Google Docs, to find additional information.
The team also uses Jira Software’s release hub to generate release notes and see when features and bug fixes went live. Once a PM has a copy of the release notes generated from release hub, they send them out to the team with some analysis: it’s their form of a retrospective.
Even though each of these features solves specific pain points, overall, they help Switch.co to clearly see their work, help prioritize, communicate, and look back to remove sources of unnecessary complexity. This in itself is agile development.
Next steps in their lightweight agile journey
Hugo hesitates to use the word agile without prefacing it with “lightweight,” but Switch.co practices core agile principles and they have clear next steps that revolve around estimation and team formation.
The next thing Hugo wants to tackle is estimation “to become better at providing timeframes to the team and management.” This will help his team work towards using velocity as a measure of success.
Likewise, instead of committing to large chunks of work at the beginning of the quarter and promising to deliver a particular OKR for that quarter, they should use estimates to determine timelines and not the other way around. This estimation can be done in the quarterly planning sessions after the team has a better idea of team velocity.
Because estimation and planning isn’t 100% streamlined, Hugo’s responsibility crosses over into the territory of a development manager/project manager. His team would benefit from a development manager and/or team lead, and aim for as little turnover as possible to help them create a predictable velocity. This will help with estimation adoption as teams work to continuously improve sprint after sprint.
Finally, to reach ultimate agile nirvana, the design and QA teams should be part of Switch.co’s software development process. Currently, once the designers’ work is done, it’s handed off to development, who then hands their work off to QA. By bringing design and QA into the development process, features, bugs, and projects in general can be tackled in a shorter timeline. This is definitely part of the long-term game of agile development, but should be thought of on a daily basis. How can QA work more closely with developers? How can developers work more closely with designers? You can only know by going through discovery processes of trial and error.
This story is not unique to Switch Communications
Becoming agile doesn’t happen overnight. The important lesson is that working cross-functionally in a productive and iterative way is what makes a team agile. Switch.co is a great example of a company who knew what they wanted to improve and why, finding a tool that could help them, and then looking how to infuse agile development into their process one step at a time.