a. Start at the end, with telemetry. Capture the right data, from the right places, to properly analyze and assess
the performance and usage of your applications. Make sure you can measure performance.
b. Automate your testing. With DevOps’ focus on regular, working releases, testing will allow your teams to
c. Keep working upstream, eliminating handoffs and adding to the team where possible. How can the process be
further simplified, without sacrificing quality.
a. When you introduce changes, be prepared for stress and even backlash. Keep moving. In the end, your teams
will find that this new structure gives them more say, not less, in the design and development of apps.
b. Let the new team figure out how to work together. There’s no one-size-fits-all approach. Give them time to
figure it out and they’ll come to different accommodations and arrangements. Tolerate some unproductive
weeks, and plan ahead accordingly.
c. Let the team select its own tools. If they want to use a different code repository, let them.
a. Keep your team together. This new team has become highly effective. They’re going to get to work, and they
are going to kill it because they know how to produce an adopted application. You will be tempted, but don’t
break the team up if possible.
b. Instead, to spread this approach through the organization, use this team as a virus. Build a team, or a shared
team, around them and have them work together for a month or two. Once the second team has experienced
and absorbed how the original team functions, peel it off to work on its own.
c. If you’re going to share people, make sure they work on a finite number of teams. And make sure they see
themselves as being on teams vs. being in a single functional group. Doing so will help eliminate the waste and
bottlenecks that often occur within the typical shared services model.
To deploy apps more quickly—apps that will be adopted—you need DevOps is about speeding up by increasing collaboration across
to eliminate handoffs both upstream and downstream of your teams, collaboration that is difficult to manage under linear
DevOps team. What’s wrong with a handoff, anyway? Each handoff Waterfall approaches. Truly harnessing its potential—an d applying
between individuals or teams, whether from a product manager its principles across a greater cross-section of your organization—
to the development team or developers to quality engineering, will allow you to realize faster releases that are more closely
reduces the likelihood that you’ll be able to deliver a great app. aligned to your users’ needs.
Each handoff includes unwritten ideas and priorities. Are your
unspoken assumptions the same as those of the next person down Most organizations struggle with the last step when implementing
the line? Are your working processes the same? It’s an opportunity DevOps—getting used to regular deployments into live and getting
for tacit knowledge to be lost, for work to pile up, for accountability real user feedback. This is crucial, especially getting that first MVP
to be pushed off to the next person. With handoffs, it’s easy to think out there. It’s not about testing buggy software with users, the
that the testing team exists to catch any mistakes you make as a releases should be sound. It’s about testing the business idea and
developer. In short, it’s much like a game of “telephone,” in which evolving it and its features with the user feedback influencing the
the message is lost little by little as it is passed down the line. direction. This is a difficult change in the way of working for the
Eliminating handoffs reduces or eliminates these challenges. whole business and mobile apps provide an ideal place to start.
The more the people writing requirements see the app as it is
being built and tested, the easier it is to course correct. The more
developers see the app being tested, the easier it is to incorporate
feedback into the next version.