Tag Archives: agile tech

FWD50 2017: Fail faster and get $hit done in digital government

Ask me what I learned at FWD50 and I’ll tell you this: All the cool kids are embracing digital government. And it’s okay that everyone isn’t doing it the same way—as long as the desired outcomes are kept in view. The real debate is whether or not government can innovate, take the right risks, and fail faster to learn how to achieve long-term success.

Those in the private sector and the venture-capital-funded startup community would tell you that the government is designed to resist innovation and change. Those in government would tell you they’re making progress because they’ve put stakes in the ground. In our FWD50 coverage, we talked up going agile and shaking up the CIO role, but the real fun of digital government comes in when leaps are taken—even if they end in failure. Take a leaf out of government’s book: In order to innovate at scale, you need to embrace a culture of failure and risk. Ontario is a leading example.

Follow the leader: Digital government in Ontario

When it comes to digital government, Ontario’s chief digital officer told FWD50 attendees that most levels of government are speaking from the same playbook—they’re just putting their own spin on it. Hillary Hartley outlined Ontario’s path to digital government with 10 key priorities, including focusing on users and businesses, creating a high-quality user experience, and recruiting talent that can help increase digital literacy and capacity across the public service.

But it’s more than just putting a new coat of paint on existing services and web properties. It goes deeper than that. Why aren’t things working in government, and why aren’t some services being used as much as they should be? Does the service have stumbling blocks that get in the way of usability? Or are citizens simply unaware that the service even exists? When it comes down to it, analytics comes in handy to make small changes that have large impact.

It’s also critical is meeting with stakeholders and policymakers as the province takes iterative sprints. Ontario’s Digital Services Standard puts stakes in the ground it can always come back to, highlighting what it needs to do to stay on the right path. But it’s not stopping there—Ontario’s looking at other innovation hubs to understand what Hartley calls their “methods and madness.” It has a lab at Waterloo’s Communitech, dubbed the “empathy lounge,” that’s dedicated to user experience design for the government’s digital services. But are mandates, an agile approach, and empathy lounges enough for government to truly innovate towards digital transformation?

Don’t overuse “innovation”

If you downed a drink every time someone mentioned innovation at FWD50, you’d be dead. But it was people from the public sector, like Hartley, who pointed out that “innovation” was an overused buzzword.

It’s no surprise that one of the sessions was an on-stage debate asking whether or not government can actually innovate. Private sector speakers called out Quebec’s licensing bureau going digital: Its hours of availability were still nine-to-five per labour union negotiations meant to safeguard full-time jobs. Meanwhile, government employees still aren’t getting properly paid thanks to the troubled Phoenix payroll project, which loomed like a dark cloud over nearly every FWD50 discussion about successful digital government.

So, private sector employees aren’t the government’s biggest fans. On the other hand, its advocates praise the government’s digital savviness, arguing that it innovates every day by doing small things. While the private sector is still searching for unicorns and trying to do things that the government could never do because of its constraints, the government is the “rhino”—it might not be pretty to look at, but it gets $hit done. Take the internet, NASA’s space launches, and safe drug injection sites in Vancouver.

The private sector can acknowledge these bright spots, but tends to see government in only two ways: as lawmakers and as a bureaucracy. Billions have been spent on developing portable electronic health records—but have you seen any of it? It’s safe to say that the government does experiment, we’re just not seeing the delivery.

At the end of the day, is it really about government versus the private sector, or is it about the ability to innovate at scale? Large businesses struggle to change course, too. Startups burn through venture capital money only to fail anyway. The government doesn’t have the budget for 10 different trials of e-health—so it has to make a big bet that might fail.

Given government’s commitment to be more agile as part of its digital transformation efforts, it’s becoming leaner, taking smaller bets and more risks. But does it have a culture that tolerates failure so it can learn to innovate better?

Get used to the word “failure”

The problem isn’t that government fails, it’s that it doesn’t talk about its failures in constructive ways. We’re not comfortable—well, most of us aren’t—saying things suck. But even the federal government CIO Alex Benay knows it’s time to get comfortable saying the word “failure,” or even admitting that a project is crap. In fact, he had a whole session about failure and culture on the last day of FWD50.

It’s not enough to just develop policies around the use of technology and how it’s deployed. Another session (quite painfully) illustrated how problems affecting citizens need to be solved. Canadian citizens, immigrants, and vulnerable people often bear the brunt of IT systems that don’t work, leading to unbearably long waits for citizenship or barriers to necessary medical care that keep them from being productive contributors to society.

For digital government to succeed, IT to innovate, and citizens to be taken care of, you need to create resiliency around failure so staff members aren’t afraid to come back into the office when things to go wrong. Benay’s take on it is if your leaders aren’t creating that space, find another job. Go to a leader that creates that space. We all have to be able to get back on the horse, because doing nothing is much worse.

So let’s wrap it up with this: The government needs to get better at breaking work down so it can learn from mistakes and start to do the cool stuff that actually works. Learning to fail is essential in going digital. Like Benay said, policy may be considered sexy, but doing $hit is more fun.

Featured image courtesy of Eva Blue.

Creating a fast, flexible team built for IT agility

Have you ever been confronted by an impatient CEO who wants the business to be more nimble and able to capitalize on emerging opportunities to outpace the competition? This might be an all-too-familiar scenario. With companies big and small becoming increasingly dependent on tech in all areas of their operations, it’s critical for IT to cultivate and practice flexibility in response to rapidly changing business needs. Fortunately, thanks to the IT agility that results from using the agile methodology, there are many smart techniques your team can use to tackle this new reality with energy and resilience.

IT agility—and why it matters

Although the agile framework was originally created for software development, it’s now used to deliver value on a broader scale throughout the business. People even talk about agile marketing and agile human resources. So, how can IT agility benefit your team?

If you’ve ever managed a traditional project, like rolling out a new mobility solution, you’ve probably run into every project manager’s nightmare: encountering a new requirement or seemingly unwelcome change just before launch. Traditional project management processes, like the Waterfall model—which requires you to tackle work in separate phases with requirements fully defined upfront—don’t handle these sudden changes well. But since these out-of-the-blue changes are a regularly recurring feature of IT projects, we need a better solution to respond to them.

An agile approach allows you to stay focused on your main goal while flexibly responding to emerging challenges and opportunities that inevitably show up along the way. By adopting iterative, two-to-four week sprints (work cycles), which allow you to break work into bite-sized chunks, you have an opportunity to review where you are at each incremental point in the project before beginning a new piece of work. You can also choose to accommodate any changing requirements that may surface at each point along the way. This is in line with values promoted in the Agile Manifesto, which tout a “ship early, ship often” approach—putting the customer at the centre and promoting constructive collaboration.

While this approach fosters more flexible project management, it can also pose a challenge when it comes to team dynamics. An agile team doesn’t behave like a regular project team and needs special care to work well.

Assembling an agile team

It’s essential to build an IT team that can quickly react to changes and continually improve itself, all while staying on task in a rapidly changing environment. Sound fun? This begins with forming a cross-functional team that eliminates silos. You may even want to include a non-tech colleague when assembling your team, depending on the circumstances, to ensure steady feedback from your customers or main stakeholders.

You also need to make sure each member of the team is dependable, both in terms of submitting work on time and communicating well within the group. Without good communication, a breakdown in the psychological safety that’s so critical to agile team success will quickly ensue, endangering the project’s progress. Your team needs to be stable, self-healing, and resilient when things don’t go according to plan—ideally without an active, guiding hand from leadership. Your team should also view mistakes or challenges as learning opportunities rather than showstopping obstacles.

As an agile IT team leader, you need to prioritize communication even more than you might when leading a traditional project. This means giving clear overall goals for your project and incremental objectives your team will tackle in each sprint. It also means supporting and encouraging frequent, collaborative communication within the team.

Foster a culture of trust and empowerment in your group. This might include inviting team members to participate in the planning process or providing them with specific roles and positions of authority within the project according to their skills. As they become more experienced, your team members will develop and strengthen the critical thinking and problem-solving abilities that will serve your business well, time after time, project after project.

The agile way

Ultimately, IT agility represents a more current, customer-focused approach to IT service delivery. If you and your team have ever been told you need to be more responsive and less stuck on procedure or policy (like pretty much every IT department on the planet, no doubt), you probably want to take a look at the flexibility an agile approach can offer. You don’t have to abandon due diligence or discipline—far from it—but you may just find that you’re able to navigate and adapt to changes more easily as they come. That’s a capability any IT team would love to have in abundance.