Digital Transformation Strategy: Process
[Editor's note: this is the second entry in a Digital Transformation series from Deem VP of technology & engineering, Steven Lopez. You can read the final entry here.]
Welcome to the second installment of the Digital Transformation series, where I discuss my three key ingredients to a successful digital transformation strategy framework: people, processes, and technology.
If you recall, digital transformation is the process of using digital technologies to re-create how we do business. More than just adding automation or other technologies to simply complete the usual tasks faster, digital transformation can empower companies to reimagine the entire experience both customers and staff have with the business.
When I consider people, processes, and technology as the three legs of a stool, I think one leg must be sturdier than the others—the people. If the people are a little out of balance, the stool will wobble. I addressed the importance of selecting, managing, and retaining the best talent possible in my first article of the Digital Transformation series, Digital Transformation in Corporate Travel: Why It Starts With People.
The next part of digital transformation strategy is process. Processes are the vital link between the people and the technology.
Agile vs. Waterfall processes
I don’t mean “processes” in a pedestrian, spreadsheet way. When I talk about processes, I mean each step it takes to create great software.
At Deem we’re people forward, so we’re sunsetting our old waterfall methodologies and going fully agile. Agile development relies completely on the strength of our people running the scrum teams and the developers doing the work.
By supporting regular and collaborative troubleshooting, agile development helps teams and individuals effectively prioritize features and work in general. Teams can make quick course corrections based on stakeholder feedback.
To create software at Deem, we use agile. It’s a combination of both iterative and incremental process models and focuses on process adaptability and customer satisfaction by rapid delivery of working software.
Agile breaks product development down into small, incremental builds. So if an “epic” request—a sizable software development request—comes in from our product team, we resize it into smaller chunks.
These smaller chunks of work are known as user stories, because they outline how our users benefit from that specific feature. Each story is customer-centric; it describes the type of user, what they want, and why. Done well, user stories help the scrum master (the team leader) prioritize the highest value deliverable by focusing on small and immediate traveler needs.
Well-executed agile scrum methodology has several benefits for both our internal developers and our end users (our travelers). The agile development process helps us improve the quality of our software and features at each release, and it allows us to adapt quickly to change.
In a nutshell, using agile means we can more efficiently move through all seven stages of development: planning, analysis, design, development, testing, deployment and maintenance of our software.
The agile scrum playbook
Ok, that got a bit technical, so let’s back it up a little. You might be asking “What’s a scrum? What’s an agile scrum?” Given the similarities between the two, it’s easy to understand why they can sometimes be confused, but they are, in fact, two distinct concepts.
Scrum is a subset of agile. “Agile” describes a project management philosophy and “scrum” is a specific methodology for implementing agile development. Think of it this way: agile is the entire playbook and scrums are the individual plays. Often thought of as an agile project management playbook, scrum describes a set of meetings, tools, and roles that structure and manage work for a team.
And scrum is exactly what it sounds like: a framework that helps teams work together. Just like a rugby scrum, players of a team huddle together to talk about the next play. The scrum is a collective pause after a play, encouraging team members to learn through experiences, self-organize while working on a problem, and reflect on their wins and losses to continually improve.
Agile scrum can only work if the right team members are in place: the coaches (product owners and scrum masters) and the team players (the development team).
Drafting the agile dream team
We’ve spent a lot of time perfecting another process at Deem: the hiring process. We work relentlessly to hire and retain the best talent possible. We’re constantly asking ourselves how to better our interviews so we’re going beyond typical resume questions. For our current employees, we work hard to provide constant education and feedback so each team member is thriving, confident, and empowered.
We’re able to run agile development processes so well because our people are agile—they’re innovative, collaborative, responsive, and open to constant change. Our leaders and contributors can all be described the same way: non-hierarchical, cross-functional, inspirational, and autonomous.
Agile leadership typically consists of a product owner and a scrum master. The contributors, of course, make up the development team. All three hum as one engine and if one sputters, the car won’t go.
Simply put: The product owner holds the vision of the final product. The scrum master coaches the development team to the product release through sprints. Sprints are short, time-boxed periods when a scrum team works to complete a set amount of work. One by one, the development team builds the product in this series of sprints led by the scrum master.
Of course, there are vested interests in the products and features. A stakeholder is anyone with an interest in or an influence on the product. These are the people who help the team discover, develop, release, support, and promote our products. Agile development means we involve our key stakeholders early and solicit their feedback often.
Strategy to inspire greatness
The processes we’ve implemented to connect people and technology, you can see, create clarity and intentionality in every stage of product development. But how do leaders and contributors keep moving together toward an ultimate goal? Every organization needs their North Star.
Sean Ellis, author, growth hacker, podcaster, angel investor, and startup advisor, describes a North Star as “that one, single metric that best captures the core value that your product delivers to its customers.” This goal-setting methodology encourages leaders and contributors to think big, but also roots ambition in reality.
The North Star goal is meant to inspire the team to greatness, think big, and leave a legacy.
Establishing a North Star is important to Deem’s overall success, and the concept connects directly to this series’ third and final pillar: technology. I’ll talk more about our North Star in my next digital transformation post and explain specifically how the technology piece of the people, processes, and technology framework helps light the way toward Deem’s North Star.
If you want to be part of an award-winning, people-first company, Deem is hiring.
This blog is part of a digital transformation series by Deem VP engineering and technology, Steven Lopez. Read the other entries by using the links here: