According to a recent study by IDG, 89% of enterprises have plans to adopt or have already adopted a digital-first business strategy, but only half of those organizations have fully adopted this approach.
It naturally follows that as more and more businesses pivot to a digital-first strategy, team leaders are more pressed than ever to deliver results quickly, adjust to changing business and customer needs, and work harder to keep up with the pace of technological change.
We think this is a major reason digital and marketing leaders are attracted to the principles of Agile software development. But often they face resistance outside their departments when they want to adopt a more Agile way of working. We find that two factors contribute to an organization’s level of discomfort with Agile principles:
- Organizational inertia
The purchasing, legal, IT, and project governance processes many organizations use for digital projects have been grounded in a Waterfall mindset for decades, so they are naturally very slow to change. To compound matters, the stage-gate model some executive boards employ to oversee large projects is also fundamentally Waterfall.
- Trust (internally and with partners)
When we prepare proposals for new prospective clients, we often provide two timelines, Waterfall and a hybrid Agile approach. Prospects are typically very attracted to the speed of Agile but perceive unnecessary risk working with a new partner in an Agile way—which is perfectly understandable. We’ve found that the longer our client relationship and the more trust is gained, the more we work in an Agile way (see Agile Principle No. 5).
The reality is that few organizations can approach software development in a “purely agile” way. Most take a hybrid approach, falling somewhere along the Agile/Waterfall spectrum. We have identified five basic ideas grounded in Agile principles that can help organizations move along the spectrum toward Agile development methodologies. These ideas apply both within the context of the digital agency/client relationship as well as the internal IT/client relationship.
Collaborate early and often (daily, if possible!)
One example where close collaboration proves essential is the creation of user stories and acceptance criteria, which document functional requirements. When the team collectively reads, provides feedback on, and approves user stories as they are written, it ensures that potential misunderstandings are quickly resolved, and everyone understands what will be built. A user story will not move into development until it has been approved for technical feasibility and also by project stakeholders.
Using tools like Jira and Confluence, all members of the project team can have full access to detailed real-time information about progress. Tasks in Jira are based on and linked to, user stories. Additionally, time and materials billing with weekly budget reports provide real-time budget consumption data. And when combined with a practice of continually refining estimates, these reports are highly effective project governance tools.
Skeptics might mistakenly think that Agile work is unstructured and therefore unpredictable. But starting development without all the requirements finalized is not the same as starting with no requirements.
Project stakeholders should collaboratively agree on the MVP, or Minimum Viable Product, that must be delivered for the first public release. (To be clear, minimum viability doesn’t mean half-finished—the MVP must still create a coherent and enjoyable user experience upon release even if there are ambitions to add more functionality over time.)
Being confidently able to communicate the overall ambition, timeline and budget parameters of a project to executive stakeholders goes a long way to dispelling the idea of Agile being unpredictable and risky.
Be Agile and Waterfall at the same time
We have found a hybrid approach can be highly effective. For example, working within the context of an annual budget, Waterfall is used for discovery, design, and technical analysis across a group of projects all running in parallel. This creates a backlog for the engineering team that pivots from one project to the next depending on priorities.
Support your executive sponsor—they can support you
Bucking the system without committed executive endorsement is next to impossible. And it’s up to the project team to use the tools and thinking described above to support their executive sponsor. He or she must be well-prepared to discuss Agile methods with peers and confidently address questions and concerns.
It’s been our experience that when clients embrace Agile development methodology, they can’t imagine working any other way. We do everything we can to facilitate and support our clients on their path to be more Agile. Together we can meet the goals of the organization more quickly, with less bloat, and a higher degree of quality.