The Talent Cloud Feature Pipeline: As a team, we used a five-step reinforcing feedback loop to develop and iterate on features for the platform:
To build a modern digital product, you need support from people with many different skill sets, which in government are classified as belonging to different occupational groups. At the same time, you don’t have the time to find external people and onboard them to the specific context of your product. Too much depends on the details of what you are building for external experts, who are not intimately familiar with the product, to be able to contribute significantly. (Not to be confused with engaging users, which is a constant outreach and engagement effort.) This means that to build a high quality, timely product, that expertise needs to be on your team.
In practice, our team is constantly bouncing ideas and work around between policy, project operation, design, development and client services. Designers regularly check-in with the policy team to ensure what they are proposing will work from a policy perspective. Project operations need to regularly check in with the developers to get details on new features being released. Our product development cycle is a constant loop that travels through multiple occupational groups. This is a daily collaboration, requiring dedicated resources from different occupational groups working together in a continuous feedback cycle of creation and iteration.
This multidisciplinary collaboration between team members is at the heart of what we do and we are constantly benefiting from it. To keep things moving at a pace that is fast enough for a product to maintain its relevance in a rapidly changing world, we think this is the only way to work (at least for these types of service-based products involving design, development and user testing.) In essence, the team’s structure allows for both the product owner (decisions on what needs building) and the product team (doing the actual building) to operate on the same team, improving flow for fast, insightful product iteration.
Although the Government of Canada has issued a bulletin to the heads of HR confirming that there is no policy barrier to multidisciplinary teams, in practice it remains difficult to put these types of teams together, especially for smaller units. This is particularly true in cases where a highly efficient team model would call for cross-classification supervision. In a tradition government hierarchical structure, this would rarely be needed. But this structure is commonplace in multifunctional agile teams in the private sector because of the nature of the work, which requires designers, developers, anthropologists, and client services working together to deliver a product. When governments want to build like this, using agile methods, it means that teams like this will be increasingly required. With some careful classification work and the flexible use of temporary “term” arrangements, Talent Cloud was able to set this up, but it’s not guaranteed that other teams will be able to do the same.
Saying that a team uses “agile” in government has become a bit controversial because there are so many different versions of what teams and leaders mean by the term. While its sudden popularity is evident (bordering on ubiquitous), few agree on a concrete definition or a minimum bar for being able to legitimately claim use of the practice. Nevertheless, we’re sharing some of the “agile” concepts we use in our 2-week sprint cycle.
(For a real view of this, check out our code and content on GitHub.)
As is common in agile builds, we use story points to talk about how difficult or complex something is for the development team. Before we decide to work on a specific task, the developers estimate how many story points it will take to complete; it doesn’t really matter if a story point usually takes an hour of a developer’s time to complete, or a full day. What’s important is that the story point becomes a useful way to communicate to the rest of the team how complex (and potentially time consuming) something will be to implement.
For example, we looked at a feature that interrupts someone who is completing a job application if the deadline for submitting it has passed. Without that interruption, you might waste some time completing an application, but when you hit the submit button, you would get an error message indicating the submission deadline was passed. It’s a desirable feature, though only a tiny fraction of users would ever benefit from it. The devs estimated this as 8 story points. In a good sprint, we can only complete about three tasks of that complexity. And given that so few users would benefit from this work, the team was able to make the call that it wasn’t worth building. Instead the dev time was spent on building higher value features that would impact more users. But if the “cost” of this had been one or two story points, we might have chosen differently.
For our distributed team, the daily stand-up has become central to how we work. Each day at 11:00 the development team and designers join a zoom call and briefly describe:
We’ve managed to keep these stand-ups under 15 minutes in length, even with 9+ people. If discussions start breaking out, we can usually ask people to stay on the call after stand-up to finish their chat and move on. Stand up is great for making sure everyone is working the right things. With the designers there as well, it helps increase interaction between them and the developers, which is something we have been trying to improve.
With many people working from home, stand-up can sometimes be the only direct interaction you have with other humans in the work day. The format of stand-up is straight forward, each person briefly says what they worked on since the last stand-up, what they plan to work on until the next one and what blockers (if any) are preventing them from making progress. This also helps increase human interactions more by allowing the team to point out when two people should discuss their work. There’s always a balance to strike between keeping everyone involved and having enough focus time on our own.
At the end of each 2-week sprint, the development team leads a demo session where they show what they’ve completed. Because we’re not really building for a client though, we don’t stress too much about what we’re committing too at the beginning of a sprint. Instead, the developers work hard to advance things as much as possible. If something is not complete, it can be saved for the next sprint review. Except in special circumstances there’s no rush with developers doing overtime to complete tasks.
To even things out a little, so it wasn’t always the developers presenting their work, and so the developers were better kept in the loop for what the rest of the team was doing, we started doing a “policy team” sprint review on alternating weeks with the developer sprint review. (For reference, the “policy team” is the research, policy and client interaction side of Talent Cloud, which uses a Trello board to track work, and tends to have different timelines and pressures than the dev team.) We’re still iterating on the exact format of policy team sprint review, but the goal is to give everyone a sense of what tricky things the policy team has had to deal with recently and remind everyone of that we’re building towards a longer term vision. Typically, we try to pick one or two artifacts that the team has completed, or made significant progress towards and have the person that worked on them present it to everyone else. Examples are design prototypes, presentations (decks), research, reports or some other tricky theory work like our tenth version of the skills framework at the heart of the recruitment model.
The Talent Cloud team has been a distributed team since 2017 with members in cities across Canada including Halifax, Toronto, Montreal and Edmonton. This also means that team members in the Ottawa main office have always been able to work from home at their discretion, including our Indigenous Community Liaison, who works half time from her community farther north.
In March 2020, when offices shut down and governments around the world struggled to adapt to the new reality under COVID-19, this really just meant that our team took their computers home on a Friday and worked from home afterwards. Everyone was able to continue their work uninterrupted (with the possible exception of kids-not-at-school causing mayhem in the background).
It’s interesting, but distributed teams actually get easier the fewer people who are together in one place. With only one or two people out of the office, it’s easy to keep office-centric practices as the default while those in the regions just work around and fit in however they can (which is a habit our team spent a lot of time consciously trying to break out of.) But when half or more of the team are remote, you really just don’t have a choice.
Digital tools become extra important when working on a distributed team. For our developers this has been GitHub to collaborate on code and plan development sprints. Our designers have been making use of Adobe Creative Cloud to build and share designs, while everyone has been collaborating on documents using Google Drive.
Most important though, is a good messaging app because it becomes the main method of communication and culture hub for the team as a whole. Sharing photos, links and random thoughts becomes the replacement to watercooler conversations. Emoji become the replacement to seeing smiles on your colleagues faces.
Messaging platforms also allow for improved productivity as team members can “leave” to do focused work and then return to the conversation where the whole history of it is preserved so they can jump right back in. It also helps keep track of what decisions were made and why, especially for key design components where multiple options were considered, particularly when messaging apps are paired with tools like Trello to track taskings and progress.
