Is Agile Hiding the Fact That Your Vendors Aren't Delivering?

Agile development was meant to emphasise speed, simplicity, and collaboration. The problem is that as the core philosophy has exploded in popularity, the ways people implement it have also evolved - regardless of whether they remain true to the original concept. This can make efficient vendor management and project oversight extremely difficult.

?Many vendors run circles around their business partners. They may claim to honour the tenets of agile, but they're often simply taking advantage of a generally confusing situation.

?Could your vendors be hiding behind the cloak of agile development to avoid delivering the way they should? Here are some signs to look for – and ways to get them back on track.

?

Agile Fundamentals

Agile development is a type of iterative software development. Agile teams tackle individual project goals in small chunks. Each of these mini lifecycles is a structured process that includes its own coding, testing, building, and quality control stages. In other words, different teams make progress concurrently and may tackle similar tasks even though they're not duplicating work.

Somewhat confusingly, there are many different frameworks for agile development. Some of the most popular include Scrum, Kanban, and Lean, and each has its own set of practices and terminology:

?Scrum is probably the best-known framework for agile development. It features short (usually 2-4 week) periods of intense development known as sprints, during which a team works to complete a set of agreed-upon deliverables. At the end of each sprint, the team looks back at what went well and what could be improved.

Kanban is a slimmer, more flexible approach to agile development focused on minimising waste and maximising efficiency. Here, teams don't use sprints, but instead, work on a continuous stream of deliverables that get fed into the development process as they become ready.

The Lean approach to agile development revolves around minimising waste across the entire development cycle. Its roots lie in the Toyota Production System's lean manufacturing principles.

?

The Waterfall Alternative

Agile first hit the scene in the 1990s. At the time, it was somewhat of a reactionary pushback against the then-prevalent philosophy of software development: Waterfall.

?Waterfall development is a linear-sequential lifecycle model, meaning that individual project phases never overlap. Instead, teams must complete one stage before moving on to the next.

?As a quick example, a waterfall dev lifecycle typically starts with a project requirement analysis that informs a subsequent system design phase. After that, devs create the system by building small units which are then integrated and tested as a whole. Finally, the system is deployed and maintained.

?

How Vendors Fall Short of True Agile

It's not uncommon for development teams to modify agile practices. For instance, not every scrum sprint requires the same degree of planning or testing.

?As an adaptive approach to software engineering, agile development practices tend to reflect specific feature requirements in the hopes of accounting for evolving customer needs. Unfortunately, some vendors use this leeway as a justification for doing whatever they want. It doesn't help that many vendor management teams lack the knowledge or capacity to hold them to account.

?Here's an example. Imagine you asked your vendor to join you in planning a project upfront, but they countered with the suggestion that they provide estimates with every 2-week sprint. Whenever you asked them about discrepancies in how the development was going and why it didn't seem agile, they'd offer up the excuse that certain parts of the process were agile, but others were waterfall.

?This isn't that far-fetched: Many vendors seem to want their business clients and partners to adapt to their methods instead of changing how they work in pursuit of a common middle ground. Although this might not be too problematic if you were only working with one vendor, the complexity of project management increases exponentially as you try to wrangle multiple providers.

?Now suppose you had contracted out different parts of a project to independent vendors. If one used sprint-oriented Scrum and the other favored efficiency-centric Kanban, you'd be in for quite a tough time integrating their output. The situation would look even direr if you started working with other vendors who used waterfall or hybrid methods.

?Your vendors should work with you and align their practices to your needs. When they don't, it can become impossible to confirm that they're actually doing what you paid them for. Remember, it's not just about getting a piece of software that works but ensuring the development lifecycle meets your standards – so that the resulting product is optimally usable.

?

How to Stand up For Yourself

Fortunately, you don't have to resort to micromanaging your partners to achieve your preferred agile style. Here are a couple of easy vendor management practices that can help you keep projects on target:

?

Modify Your Umbrella Agreements to Incorporate Agile Contracts

Master agreements offer excellent starting points for agile enforcement. You might think about modifying yours to include legal clauses that specify potential modifications to projects in clear terms along with penalties for non-delivery. By defining target costs, enumerating acceptable incremental delivery progress metrics, and setting caps on time and material variations, you can create agreements that set a firmer tone for what's acceptable.

?

Consider Collaboration Agreements

Using collaboration agreements is another smart way to precisely delineate the bounds of your vendor relationships. These arrangements clarify who owns which responsibilities and assets. They also specify what happens in the event of disputes, making it easier to remedy noncompliance – or cut your losses by terminating a partnership if all else fails.

?

Allow Time to Co-Design Delivery Frameworks

Often, we are so fixated on starting a new project because we are already significantly behind. That’s not an excuse to ignore good governance. It's important to define upfront and early how you will deliver, if you don’t define upfront and early, you will likely be figuring it out as you go. If you don’t, vendors will be experimenting using your money.

?

Put Your Organisation on the Path to True Agile Development

As your projects grow and mature, your vendor oversight strategies must evolve in kind. Agile development isn't just about software. It's also a matter of nurturing an organisational culture that enhances your ability to deliver high-quality results and continually improve.

Achieving genuinely agile vendor workflows may ultimately come down to rethinking your management practices to leverage your existing organisational capacities. Want to make the most of your potential? Reach out to an Agile Management Office expert.

Remember Vendors Should Integrate with You, Not Force You to Accommodate Them.