It's Monday morning, and GSoft’s software development teams are shuffling into the office with their heads already full of ideas. The people behind Officevibe, ShareGate and GLab rub shoulders daily, so you’d think that by now they might have nailed down the magic recipe for making world-class technologies. But it’s not that easy. While GSoft's product experts agree on some core best practices for software development, they don’t see eye-to-eye on which practices are most important. And that’s despite the fact that they all spend their days asking themselves the same question: “How can we work more efficiently?” We sat down with some of GSoft’s experts to find out which software development approaches make the most sense to them.
Agility at all costs? No way.
The Manifesto for Agile Software Development advocates a handful of practices that gaining ground in the business world. For instance, person-to-person interactions are now more highly valued and face-to-face communication is encouraged. Customer collaboration is taking priority over contract negotiation and teams are responding to change instead of sticking to established plans.
“It’s really important to constantly reassess what we’re doing and make sure we’re creating value by meeting a real customer need and remaining aligned with our vision," said Adam Dubé, Product Manager at ShareGate. Agile principles guide Adam’s day-to-day approach more than agile practices.
Working in agile mode doesn’t necessarily lead to project success.
Meanwhile, Audrée Lapierre, Design Manager for Officevibe, takes agile principles with a grain of salt. “Everyone gets excited about agility and speed, but this can give teams a very short-term vision.” Instead, she makes a point of regularly stepping back to reflect on short- and long-term issues. Continually zooming in and out, from micro to macro, helps her see how her work is impacting the product. And working in agile mode doesn’t necessarily lead to project success. Communication continues to be one of the main reasons agile teams fail, especially when they have to work with external teams that don’t use agile methods. “It gets tricky when different disciplines need to collaborate,” says Dubé.
To overcome these challenges, ShareGate's product teams have implemented a software development lifecycle used primarily for a project’s ideation stages and creative aspects. Paradoxically, having a product development cycle can seem pretty rigid when viewed from an agile perspective.
“I actually hate calling it a procedure. I prefer to think of it a set of guidelines for the development process. We sat down as a team to identify what the key steps are, why they’re useful and what conditions have to be in place in order for them to be successful. We even created a list of deliverables for each of them,” he explains. The goal is to get the various disciplines on the same page so that they can bring value to customers as quickly as possible while still meeting GSoft’s quality standards.
The pace determines the method, not vice-versa
“There are lots of different practices out there, so you need to know which is most likely to work for your given context," says Adam Dubé, Product Manager at ShareGate. And the context is substantially different at ShareGate, Officevibe and GLab, even though these teams meet regularly to form communities of practice. For example, since GLab’s core mission is to launch products in under three months, it has a fundamentally different work pace than Officevibe, which has just launched a new version of its work team engagement platform.
Although it can be easier to just start developing a product and prioritize features instinctively, this isn’t the right approach.
At GLab, the challenge is to combine speed with attention to user behaviour and UX issues. According to the members of GSoft's innovation lab, doing in-depth user research can be difficult and time-consuming. Although it can be easier to just start developing a product and prioritize features instinctively, this isn’t the right approach. When speed is the name of the game, as it is at GLab, the team draws inspiration from two popular approaches: Jobs to be Done and Lean Canvas.
Jobs to be Done methodology involves trying to understand the circumstances that drive certain user behaviours, rather than attributing these behaviours to personas with specific characteristics. By understanding the emotions and social settings that affect users, rather than simply making causal links between profile types, teams can create experiences that offer more value to a wider range of users. In other words, instead of looking at technological functionality, product developers have to analyze the intrinsic reasons that prompt users to make certain decisions. This leads to value creation over the longer term. Meanwhile, Lean Canvas uses a nine-box table developed by Ash Maurya to quickly summarize the core principles of a business model. However, Guillaume Chalifoux, Director, Innovative Products and Commercialization of the GLab’s, makes the point that even though it only takes 30 minutes to fill out a Lean Canvas, it only becomes valuable when you take the time to go over its contents.
All eyes on the user
If there’s one thing that all the teams agree on, it’s that the user should be their main focus. As a result, research is becoming increasingly important in product development projects. For example, Guillaume Chalifoux believes that user journey mapping is essential. This process allows a researcher to illustrate what’s already known about the user and share this information with the entire team so that they can build a solution that meets the user’s needs.
“In the past, I’ve certainly seen projects kicked off even though no in-depth interviews or prior observation sessions were conducted for them,” says Matthew Gardner, UX designer at GLab. His point is that user path mapping is only useful if it reflects the results of qualitative or quantitative analyses carried out with users. User tests are performed directly on the wireframes during the product platform iteration to test user navigation patterns and their understanding of messages. “Since these tests are carried out on specific user groups, it’s important to know which audience you’re targeting.”
Giving users exactly what they ask for is a trap that should be avoided because it can quash innovation.
Meanwhile, Audrée Lapierre cautions that relying too heavily on user tests can be dangerous. “Giving users exactly what they ask for is a trap that should be avoided because it can quash innovation. We need to be confident about our design and our ability to find solutions that aren’t immediately obvious.” It’s the designer’s responsibility to defend her vision and use user tests judiciously, not as a to-do list.
Finally, researchers and UX designers aren’t the only ones who should be involved the user research. “We asked the Officevibe team, including our developers, if anyone was interested in helping with information gathering and data analysis. The participants were surprised at how much useful information they got from talking to users directly and hearing about their issues in their own words. It gave them a more nuanced understanding of user behaviours and provided them with insights that they never would have gotten just by reading research results. They ended up feeling much more confident about their decisions,” explains Marie-France St-Pierre, who heads Officevibe's User Research department. “If you want to create products that make a difference, it helps to be curious about what makes people tick,” she concludes.