Your organization has created a DevOps group, embarked on a journey to implement Agile methodology, and has been working towards continuous delivery. But have you really examined what that all means? Have you thought about the fact that you will be making one of the most difficult changes that can be made in an organization — a cultural change?

This year the pair will appear together for the first time on a conference stage at Interop ITX 2018 to talk about The Impassable Last Mile of Continuous Delivery. But while it may be the first time they have appeared together on a conference stage to talk about DevOps, it won’t be the first time they’ve presented their knowledge and expertise in front of an audience, they told InformationWeek in an interview.

“We’ve done them for our friends,” Patrick told me. “We’ve done them, geeking out with friends…Mandy and I will get into conversations about automation, virtualization, software-defined infrastructure.”

Each partner brings a different set of skills, experience, and knowledge to these conversations. Patrick likes to build things and learn new languages, according to Mandy.

“I like to make sure we do things in a scalable, reliable way,” she said. If these sound like complementary skill sets, they are, but that doesn’t mean that everything was always so smooth.

The pair met when they were coworkers in 2000. Mandy served as the lead QA engineer and Patrick was a sales engineer who had built a demo environment that was great at highlighting the features of the product.

Management told Mandy to keep the demo environment stable, make sure it ran on the latest code base, but they said she should not let Patrick make any changes. Management told Mandy that all changes needed to go through her.

But then the management created a back channel to Patrick. They told Patrick not to listen to Mandy. They told him to go ahead and make any changes he needed to make to the code in order to show the coolest new things to the customer. “Just do it!” they said, according to Mandy and Patrick.

“So they created this dynamic that exists in so many companies where they want one person to keep reins on process and make sure the results are predictable, and then they want the other person to be dynamic and charismatic and creative and can throw something together really quickly. But then the risk is higher,” Mandy said. And you run the risk of some negative interactions with your coworkers.

It took a long time before Mandy and Patrick Hubbard talked about their experiences at that job and figured out how management had pitted each of them against each other.

“We didn’t understand the dynamic until years later,” Patrick said. “We have already professionally argued about technology as passionately as any two people can at work. So relatively in our relationship it’s pretty harmonious when we talk about tech.”

Their strengths as collaborators remain the same. Patrick is the builder or maker, he said. But he’s learned quite a bit more about what happens to his code when it moves to the operations side of the house.

“Cowboy development creates an enormous technical debt for the business that will have to get solved,” Patrick said. It’s important to also think about the way things will have to be maintained in the unsexy years after Dev walks away and then Ops has to run the thing for months and years afterwards. That is one of the greatest things you can do as an architect or a developer or someone who works on strategy. Step back and think about quality.”

You can reap the benefits of the Hubbards’ long DevOps collaboration during their session at Interop ITX on Thursday, May 3, in Las Vegas. Mandy and Patrick Hubbard promise to offer best practices to help organizations navigate the cultural changes needed to reach your organization’s goals and create a cohesive team environment during The Impassable Last Mile of Continuous Delivery Session.

Why Agile? The Problem with Waterfall

The traditional “waterfall” approach to software development follows a strict linear sequence: plan, design, build, test, and deliver. That model works well for manufacturing physical products such as cars or buildings, where requirements rarely change mid-build. Software development is different. Business environments shift quickly — hardware evolves, customer demands change, and competitors move fast. Spending months or years following a fixed plan only to discover a flawed assumption from phase one is an expensive risk.

Agile addresses this by replacing the long planning-and-build cycle with short, iterative loops. Teams work in close collaboration with customers, deliver usable increments early, and adjust direction based on real-world feedback — all without sacrificing quality.

How Agile Works: Core Principles

Agile is not a single process — it is a philosophy grounded in the Agile Manifesto (2001), which prioritises individuals and interactions, working software, customer collaboration, and responding to change. In practice, that philosophy translates into a set of working patterns:

• Faster, smaller increments. Instead of delivering one large release after many months, Agile teams aim to deploy a first usable increment within a few weeks and build from there.
• Daily communication. Team members collaborate continuously — typically through short daily stand-up meetings — so that problems surface and are resolved quickly rather than festering until a formal review.
• Regular feedback loops. Progress is measured after every increment, not just at the end of the project. Teams track velocity (the amount of work completed per cycle) to plan future iterations realistically.
• Self-organizing teams. Rather than following a top-down set of instructions, Agile teams understand the goal and determine their own path to reach it. This autonomy drives both accountability and creativity.
• Continuous improvement. After each iteration, teams reflect on what went well and what did not, then adjust their process. The guiding principle is Keep It Simple (KIS) — avoid unnecessary complexity.

Common Agile Frameworks

“Agile” is an umbrella term. Several concrete frameworks implement its principles. The most widely adopted include:

• Scrum — sprint-based delivery with defined roles and ceremonies
• eXtreme Programming (XP) — engineering-focused practices such as pair programming and test-driven development
• Feature Driven Development (FDD) — model-driven, short-iteration development organised around features
• Dynamic Systems Development Method (DSDM) — a governance-heavy framework popular in enterprise settings
• Adaptive Software Development (ASD) — emphasises continuous learning and adaptation
• Crystal — a family of methods scaled by team size and project criticality
• Lean Software Development (LSD) — applies lean manufacturing thinking (eliminate waste, amplify learning) to software

Most teams choose one primary framework and supplement it with practices from others. Scrum and XP are the most commonly paired combination.

Scrum

Scrum structures work into short, fixed-length cycles called sprints (typically two to four weeks). The key roles and artefacts are:

• Product Owner — maintains a prioritised list of work items called the product backlog.
• Scrum Team — selects a subset of backlog items (the sprint backlog) to complete during the sprint.
• ScrumMaster — removes impediments and keeps the team focused on the sprint goal.
• Daily Scrum — a short (typically 15-minute) stand-up meeting for the team to synchronise and surface blockers.
• Sprint Review — at the sprint’s end, the team demonstrates completed work to stakeholders and collects feedback before starting the next sprint.

Example: A product owner meets with a customer to capture requirements, which form the product backlog. The team selects the highest-priority items for a two-week sprint. During the sprint, they hold a daily stand-up to co-ordinate work and flag blockers. At the end, they ship the increment, review the remaining backlog, and kick off the next sprint. This cycle repeats until the product is complete.

eXtreme Programming (XP)

XP is an engineering-discipline framework often combined with Scrum. Its focus is on technical excellence and close customer involvement to maximise satisfaction. Core XP practices include:

• User stories — customers describe desired features in plain language; these stories drive the release plan.
• Short iterations — software is delivered every one to two weeks.
• Pair programming — two developers work together at one workstation, one writing code while the other reviews in real time.
• Test-driven development (TDD) — unit tests are written before the production code they will verify.
• Continuous integration — code is integrated and tested frequently to catch problems early.
• Frequent customer feedback — the customer reviews each iteration and adds or refines user stories accordingly.

Example: A developer collects user stories from the customer to build a release plan. Iterations are delivered every two weeks. Developers work in pairs, hold brief daily meetings, and the customer reviews each release and provides new or updated stories. The cycle continues until the software meets the customer’s needs.

Benefits of Agile Methodology

Agile’s advantages are a direct result of its iterative, collaborative nature:

• Faster time to value. Short iterations mean working software reaches users sooner, reducing the time between investment and return.
• Higher customer satisfaction. Customers see and influence the product throughout development rather than receiving a surprise at the end. Adjustments are cheap because they happen early.
• More engaged teams. Self-organizing teams with real decision-making authority tend to be more motivated and productive than teams executing a prescribed plan.
• Reduced rework. Continuous customer involvement keeps development aligned with actual requirements, shrinking the gap between what is built and what is wanted.
• Better risk management. Problems are discovered at the end of a two-week sprint, not at the end of a two-year project, limiting the cost of correction.

Agile Best Practices

Regardless of the specific framework chosen, the following practices consistently improve Agile team outcomes:

• Maintain a prioritised product backlog. The product owner continuously ranks work items by business value so the team always works on what matters most.
• Keep release cycles short. Aim to deliver a shippable increment every two to four weeks. Longer cycles erode the feedback loop that makes Agile effective.
• Use pair programming. Two developers collaborating in real time catch defects earlier and produce code that is easier to maintain — research cited in XP literature suggests quality improves even when raw productivity is similar to solo work.
• Refactor regularly. Revisit existing code to improve its structure and clarity without changing its behaviour. This prevents technical debt from accumulating.
• Adopt test-driven development (TDD). Write the failing unit test before writing the implementation. TDD keeps code correct, surfaces design issues early, and gives developers a concrete goal for each piece of work.
• Hold retrospectives. After each sprint, reflect on what worked, what did not, and what to change next time. Continuous process improvement is as important as continuous product delivery.
• Limit work in progress (WIP). Particularly in Kanban-influenced Agile environments, capping the number of tasks in progress at any one time reduces context-switching and improves flow.

Popular Agile Methodology Tools

A wide range of tools supports Agile planning, tracking, and engineering practices. The following are commonly used across the industry:

• Jira (Atlassian). One of the most widely adopted project management platforms for Agile teams. Supports Scrum boards, Kanban boards, sprint planning, backlog management, and customizable workflows. Integrates with a large ecosystem of DevOps tools.
• Azure DevOps (Microsoft). Provides end-to-end tooling including boards, repositories, pipelines, and test plans — suitable for teams working in Microsoft ecosystems.
• Trello (Atlassian). A lightweight, visual board tool well-suited to smaller teams or simpler Kanban-style workflows.
• Linear. A modern issue-tracking tool popular with product and engineering teams that prioritises speed and a clean interface.
• Pivotal Tracker. A tool oriented towards story-based development and velocity tracking, commonly used in software product companies.
• ActiveCollab. A project management platform aimed at small to mid-sized teams, combining task management with time tracking and collaboration features.
• Miro / FigJam. Digital whiteboard tools used for remote sprint planning, retrospectives, and user story mapping sessions.
• GitHub Projects. Native project board functionality inside GitHub, useful for teams that want to keep code and project tracking in one place.

When selecting a tool, prioritise fit with your team’s size, existing toolchain integrations, and the specific Agile framework you are following. No tool compensates for weak Agile practices, but the right tool can significantly reduce administrative overhead.

Getting Started with Agile

If your team is new to Agile, starting with Scrum is usually the most practical path. Its clearly defined roles, ceremonies, and artefacts provide enough structure for teams transitioning from waterfall without overwhelming them. From there, incorporate XP engineering practices — particularly TDD and continuous integration — to strengthen code quality. As the team matures, experiment with retrospective-driven process improvements and consider scaling frameworks such as SAFe, LeSS, or Nexus if you need to coordinate multiple teams.

Agile is ultimately a mindset before it is a process. The ceremonies and artefacts are scaffolding. The real goal is a team that communicates openly, learns from every iteration, and delivers genuine value to customers on a cadence they can rely on.

The Drawbacks of Waterfall-Style Mobile Deployment

Many enterprises still approach mobile app delivery the same way they approach large-scale enterprise software: long requirement-gathering phases, extended development cycles, and equally long testing periods before a single release reaches users. In a waterfall model, each phase can stretch to several months, meaning a full release cycle may take the better part of a year.

This creates several compounding problems for mobile teams specifically:

• Requirements drift: Over a multi-month cycle, business needs change and original requirements become stale before they are ever implemented.
• Large, risky releases: Bundling six or more months of changes into a single deployment dramatically increases the risk of failures that are hard to trace and costly to roll back.
• Delayed feedback: Real user feedback arrives so late in the cycle that fundamental UX problems are discovered only after significant investment has been made.
• Governance overhead: To manage the risk of large releases, teams layer on complex approval and governance processes that slow delivery further without proportionally improving quality.

Mobile apps do not need to be perfect on day one — they need to be useful, intuitive, and continuously improving. A waterfall model optimises for completeness at the expense of speed and adaptability, which is the opposite of what mobile development requires.

How DevOps Addresses Mobile-Specific Challenges

DevOps brings together the cultural practices, processes, and tooling needed to release software frequently and reliably. For mobile development, this matters in a few concrete ways.

Handling Platform Fragmentation

Android and iOS each have distinct build pipelines, signing requirements, distribution mechanisms, and OS update schedules. A DevOps pipeline must be designed to handle platform-specific steps — code signing, provisioning profiles, app store submission — alongside shared steps such as unit testing and static analysis. Continuous integration (CI) servers can be configured to run platform-specific build jobs in parallel, catching regressions on both platforms with every commit.

Continuous Integration and Continuous Delivery

CI ensures that every change to the source code is automatically built and tested. For mobile apps this typically means:

• Running unit and integration tests on each pull request.
• Executing UI automation tests on a device farm or emulator matrix to catch rendering and interaction regressions across screen sizes and OS versions.
• Producing a signed build artifact that can be distributed to testers via an internal distribution service before any change reaches a public app store.

Continuous delivery (CD) extends this by automating the promotion of builds through staging environments and, where appropriate, directly to production through phased or canary rollouts.

Monitoring and Observability in Production

Unlike a web application where you control the runtime environment, a mobile app runs on millions of user-owned devices. Real-time crash reporting, performance monitoring, and analytics are therefore critical components of a mobile DevOps pipeline. Instrumentation should be in place before an app ships, not added reactively after problems are reported.

Core Capabilities DevOps Brings to Mobile Teams

• System uptime and reliability: Automated rollback capabilities and feature flags allow teams to disable a broken feature without pulling an entire release.
• Change tracking: Every commit, build, and deployment is recorded, making it straightforward to correlate a production incident with a specific code change.
• Process automation: Build, test, sign, and distribute steps run automatically, eliminating manual hand-offs that introduce delays and errors.
• Faster incident resolution: Centralised logging and alerting mean issues are surfaced to the right team immediately rather than discovered through user complaints.
• Workflow transparency: Shared dashboards and automated status notifications keep product, development, and operations teams aligned without requiring extra meetings.
• Delivery performance metrics: Tracking lead time, deployment frequency, change failure rate, and mean time to recovery (the DORA metrics) gives teams objective data for continuous improvement.
• Faster time to market: Smaller, more frequent releases reduce the overhead of each individual deployment and shorten the feedback loop with users.
• Consistent user experience: Automated testing and graduated rollouts reduce the likelihood that a broken release reaches your entire user base simultaneously.

DevOps vs. Agile: Understanding the Distinction

Agile and DevOps are complementary but distinct practices, and confusing them leads to incomplete adoption of both.

Agile is primarily a software development methodology. It organises work into short iterations (sprints), emphasises close collaboration within the development team and with stakeholders, and uses ceremonies such as daily standups, sprint planning, and retrospectives to maintain alignment and continuous improvement within the development phase.

DevOps extends that collaborative culture across the entire software delivery lifecycle — from development through testing, deployment, and operations. Where agile focuses on how software is built, DevOps focuses on how it is built and reliably delivered to production. DevOps adds the tooling, automation, and operational practices needed to make frequent agile releases actually reach users safely and quickly.

In practice, high-performing mobile teams use agile ceremonies to plan and execute development work while applying DevOps tooling and culture to automate the delivery pipeline and maintain production systems. Neither replaces the other.

Building a DevOps Pipeline for Mobile: Key Tooling Categories

A mature mobile DevOps pipeline typically spans the following categories. Specific tool choices will depend on your platform, team size, and existing infrastructure.

Source Control and Code Review

A well-structured branching strategy (such as trunk-based development or GitFlow) combined with mandatory pull request reviews enforces quality gates before code enters the main branch. This is the foundation on which everything else is built.

Continuous Integration

CI servers (self-hosted or cloud-based) automatically build and test the application on every push. For iOS builds, macOS build agents are required; Android builds can run on Linux agents. Many teams use services purpose-built for mobile CI to handle platform-specific requirements such as code signing.

Automated Testing

A layered test strategy covering unit tests, integration tests, and end-to-end UI tests is essential. Device farms allow UI tests to run against a matrix of real or emulated devices, providing confidence that the app behaves correctly across the platforms you support.

Artifact Management and Distribution

Build artifacts should be versioned and stored in a binary repository. Internal distribution services allow testers and stakeholders to install specific builds without going through a public app store, accelerating the feedback loop.

Crash Reporting and Performance Monitoring

Production observability tools provide real-time crash reports, ANR (Application Not Responding) rates, network performance data, and custom event tracking. This data closes the feedback loop between users and the engineering team.

Feature Flags

Feature flag systems decouple deployment from feature release. A new feature can be shipped to production in a disabled state, then gradually enabled for a percentage of users. This enables canary releases, A/B testing, and instant rollback without a new app store submission.

Practical Principles for Getting Started

1. Start with CI before CD. Get every commit automatically built and tested before attempting to automate deployments. A reliable CI pipeline is the prerequisite for everything else.
2. Automate testing incrementally. Begin with unit tests for business logic, then add integration and UI tests over time. Do not defer all testing to the end of the release cycle.
3. Instrument before you ship. Add crash reporting and basic analytics from the very first release so you have a baseline to measure improvements against.
4. Release smaller, more often. Smaller releases are easier to test, easier to roll back, and easier to reason about when something goes wrong.
5. Measure delivery performance. Track metrics such as build success rate, test pass rate, deployment frequency, and mean time to recovery so the team can see the impact of process improvements.
6. Treat the pipeline as code. Store build configuration, test scripts, and deployment scripts in version control alongside the application code. This makes the pipeline reproducible and reviewable.

Summary

DevOps is well-suited to mobile app development because it directly addresses the pain points that make mobile delivery hard: platform fragmentation, the need for rapid iteration, the risk of large infrequent releases, and the difficulty of maintaining quality at scale. By combining agile development practices with a mature, automated delivery pipeline and production observability, mobile teams can ship more frequently, respond to user feedback faster, and maintain higher quality — without sacrificing engineering rigour for speed.

The goal is not to ship a perfect app on day one. The goal is to build a system that allows continuous, safe improvement over time.

Speeding the delivery of technology is a critical aspect of business today. One of the approaches to increase that speed of delivery that many of us have worked to implement is the use of Agile software development methods such as Scrum XP to deliver business value more rapidly. Transforming an organization from a waterfall centric methodology to agile development is an exciting, but difficult time in an organization.  The changes that are required to the organization are not just mere IT department or technology changes, but require broader organizational change management to successfully advance how technology is defined and delivered to an organization.

This article won’t go into the details described in the original Agile Manifesto written in 2001, as this isn’t about describing what agile is. This article characterizes three of the things that fueled the transformation of this organization on our journey from waterfall to agile.

1. Organizational buy in is essential in the move to Agile.  This requires ongoing and consistent education and communication more than anything for the various stakeholders to truly adopt this change. We did multiple types of training to make sure that we covered all the appropriate parties. Large group training for the teams that will form the scrum teams and will be the backbone of development is a must. Those teams must understand the what’s and why’s of how to successfully deploy scrum in their projects. They will be the ambassadors of success to all other areas of the business, so they need to have broad and deep knowledge of the process and ceremonies in Agile. Training all the other groups that interact with the Scrum teams is a must to ensure everyone is on the same page and have same level of understanding. We had separated sessions for many of the groups including Product Managers, Product Owners, Executive teams, Infrastructure and Operations teams, Architecture, and our business process owners. We tried to ensure that each of those groups had a somewhat custom version of the training, to understand broadly what the basis of Agile is, but more importantly to understand what their role is in our Agile methodology. These training sessions have created the base of knowledge and understanding showing the positive impact that agile can have. The communication campaign creates positive buzz across the organization and a willingness to not only assist in driving this forward, but to champion the cause.

  ​Delivering visible results builds momentum and motivation to keep driving the change 

2. Delivering visible results builds momentum and motivation to keep driving the change. The basis of the move from Waterfall to Agile is delivering incremental business value in very short time frames as compared to a more solution based waterfall approach. As the teams start to scrum and develop using this methodology, one of the key aspects is the concept of delivering usable product in every release. If a team is working in a typical 2 week sprint, this capability is not going to be revolutionizing or earth shattering but it is essential for business partners to see the value that can be produced in such a short time frame. A key element of change management is building trust with our business partners that things are moving in the right direction. These incremental deliveries allow the business to see in near real time what is being delivered, how it is going to work, and the benefit that either they or the external customer will see from it. This is fundamental in creating the right relationships for success of all parties.

3. Viewing functionality as a solution versus a technology slice. As we continue to think about the most efficient ways to create value for the business, bringing some Lean principles into the development cycle changes how we structure teams and create work queues. Historically, a development team would be functionally setup with developers only (Java, C, C++, .Net, whatever the language of the day is). The business analyst would gather requirements get them approved and deliver to the development team for coding. Infrastructure, integrations, databases, and other aspects were considered separate tasks or items to be completed and in some cases, would be totally separate projects. They would be given their requirements and drive forward to deliver the requested functionality. Creating the technology team as a “tiger team” or other cross functional team changes the team dynamics and changes speed and accuracy of the delivery. This forces the team to think of the solution in an end to end manner, better understand dependencies of other technology areas, improve handoffs, and reduce queuing between teams. Meetings are reduced; questions are answered sooner and in some cases figured out during the collaborative design sessions, which all create a more effective working environment for the teams.

The unexciting truth of how to achieve success with an agile methodology is using the same recipe as many other business or technology projects. Communicate to the right players, build the right teams, and deliver on commitments. Doing these things while implementing the right agile ceremonies for your set of circumstances can lead to great things for your organization.