Let’s not spend too long summarising these, as everyone seemingly has a different interpretation of what it means, depending on which textbook was available when they got involved.
Incremental delivery of features, decorated with elaborate ceremonies and operates on principle rather that pragmatic process. Sensible option when there is no clear sight of the end result and likely budgets are not a concern. Technical design/specifications on inception are usually thin or non-existent which presents a challenge in projects reliant on such literature – like in construction. Project scope can be changed at any time by the sponsor. Testing occurs for each shippable release in sprints of 2-3 weeks, which can be advantageous. Champions of the true agile methodology are less likely to be realists, but more so evangelists. Neither more commendable than the other.
Fixed scope, fixed price and sequential delivery. Build, build, build, test, release. Like any other there are downfalls, such as the end user acceptance period being heavily reliant on the sponsor. Most sponsors cannot rally the man-power to keep to the schedule when accepting a project preceding of 3, 6, 12 months, as testing at the end of such an undertaking can be arduous. At the beginning of a waterfall project, the sponsor has a reasonably definitive and accurate understanding of what to expect at the end.
There are others, such as V-Model, which can be applicable for larger projects.
What happens in reality?
In most cases, there is every desire to be truly agile. Agile is considered to be cutting edge, with agencies, contractors, designers, developers, product owners, scrum masters and just about anyone claiming “we are agile.”
In actuality, most will actually know and understand how it works, maybe even have experienced it working properly. But like most things, there is a time and a place and after giving it a go project by project, in agency based delivery, it usually transpires that it’s not entirely suitable.
It’s not me, it’s you
Agencies all offer agile, but most would say that whilst they have every intention of running agile, the client simply is not agile.
Client Agility Suitability Matrix
A bit like qualifying a lead in sales, or qualifying a supplier in procurement, there can be such processes as part of on boarding which determine just how any engagements should be run.
Usually this is a questionnaire and seeks to test the true availability and flexibility of the other party before any methodologies are discussed. Question such as:
- What is client team weekly availability for attending meetings on supplier site?
- What is the likely turnaround time for client sign off of features following delivery?
- For how many hours per week will there be a dedicated Product Owner on client side?
Completing such a checklist enables a clearer picture on how best to determine a methodology.
Like with most things, each of the methodologies have advantages and disadvantages. Who said we can’t borrow elements from each and product a hybrid solution of our own, tailored to our needs. Provided this is agreed on by all involved, then this should surely be fine?
In the agency software development world, 90% of the time there is a hybrid approach chosen. Even if it isn’t chosen, it ends up that way.
What can this look like?
From agile we take:
- Most ceremonies & practices (i.e. spike)
- The concept of increments (but finite in number)
- The terminology and concept of ubiquity in language
- The notion of fixed permanent teams
- The respect for collaborative decision making
From waterfall we take:
- The reality that is the need for specification/designs
- The reality that is the fixed price
- The reality that is the fixed deadline
- The reality that is that most PMs, Developers and Sponsors are not actually that adaptable!
What do we end up with?
Fully tested components delivered incrementally bi-monthly, to a feature-set derived from a negotiated budget on a realistic schedule within a sensible timeframe dictated by a deadline, produced by a team of size determined by the deadline.
Ceremonies decorate the “sprints” either end and throughout but are significantly reduced. If it’s a project which has fixed scope, having collaborative ceremonies excessive in duration just gives more of a forum for violating the project commitments.
An example project schedule could be:
But crucially, there is a predetermined number of sprints in the project plan.
It’s widely accepted that true agile evangelism can be highly respected, and in the correct environment it has proven results and is applicable. In the world of agency oriented supplier-client relationships, with a saturated contract talent market inviting multiple interpretations of the concept, its principles and execution strategy are significantly devalued.
To combat this, it can be highly effective to offer a hybrid model which is tailored based on a suitability index. Qualifiers can choose their level of engagement and there are predetermined routes to follow in project management when the commitment has been made on all sides.
If the business is not agile, don’t try and pilot agile with a digital marketing project sourced externally – have it run in a manner in which it can succeed with least complication.
Signing a project up to be truly agile, without considering the circumstances, implications and consequences introduces a very real risk of failure.