Is MMA the future of development methodology?
In February 2001, at The Lodge at Snowbird ski resort in Utah, a small group of people met to ski, relax, and discuss the matters of the day.
From this meeting emerged the Agile Manifesto as a more flexible alternative to heavyweight, rigid software development methodology now ubiquitously known as “Waterfall” although often these were in fact various methods used including “Spiral” processes with the key difference being the involvement of the Customer.
This Agile approached was quickly embraced by the startup world and have been big corp over the head with it ever since.
The four principles of Agile
- Individuals and Interactions Over Processes and Tools.
- Working Software Over Comprehensive Documentation.
- Customer Collaboration Over Contract Negotiation.
- Responding to Change Over Following a Plan.
Then came the codification
Agile was quickly codified into development methodologies such as Extreme Programmin, Scrum, Lean and Feature-Driven Development each with specific processes.
And then Agile was taken up by the consultancy world and Big Corp…
Very quickly Agile, already by definition, more a set of principles rather than a process came to mean so much and so little that Agile became an almost meaningless marketing term and a sales angle billing item.
And many Agile projects were Agile in all but name.
This corruption, codification and water downing of the original principles of the Agile Manifesto has lead to growing concerns from the original founders and certain elements across the wider development community who now having the data to assess the real success of Agile in the startup up an enterprise categories and the strength of its modern claims.
One of the biggest disadvantages of Agile that has come to light is that Agile is principally a quantity yardstick with less emphasis on code quality. In the light of major security breaches this has increasingly become a major concern.
Then as big corp and consultancy land adopted Agile as their preferred sales mantra, it’s become more apparent that Agile may not be suited to all projects (which was always known) nor all organisations.
And so from Agile emerged new more “complete” development and methodologies such as DevOps and Continuous Delivery, two related but distinct more approaches which merge production with operational management and automated deployment.
Even with these new evolutions Big Corp often does not benefit due to their software delivery processes or general structure preventing absorption of the key benefits from these new approaches into a positive effect on business outcomes.
This has lead in recent years to many of the original founders of the Agile Manifesto renouncing Agile in its modern incarnation and advocating a return to the original “Agility” principles.
But as Agile powers on into the corporate sector, the blurring of the terms Agile, Lean, Fail Fast would any return to pure “Agility” be sufficiently distinguishable to the lay manager still catching up or even implementing Agile to absorb and would it be unavoidable that it would also suffer the same water down and marketing term fate?
Was Waterfall all that bad?
What if Waterfall, or rather a traditional development approach, is not all that bad? In 2014 research by a software analysis firm call Cast using data from 1,3k applications, from 212 organisation and over 700 million lines of code concluded that a healthy mix of agile and waterfall produced the best results.
According to Cast’s results, going for an agile or waterfall only approach results in software that is “more susceptible to security, reliability, performance, and cost issues.”
Cast’s report concluded that apps developed using a mix of agile and waterfall working methods generally feature fewer code quality weaknesses than those created with a singular approach.
Even before the recent major chip level security breaches, such weaknesses lead to a higher risk of security breaches and outages would normally be a major concern had they not been until recently partly covered by the umbrella “Fail Fast” and “Move quick and break things” mantra of modern thinking and dev sales dogma.
Why this return to pure Agility might noty happen anytime soon…
So right now, unless you manage a Nuclear power station, as an internal project, development or product or lead you’re not going to sell in a project using the Waterfall totem pole any time soon.
You’re going to use the term Agile and state that you will be finishing and failing fast. And that’s the same for pitching consultancies or even software houses. Agile, along with the terms DevOps and Continuous Delivery for a more technical client, are simply the terminology the management team and budget holders will understand and want to be associated with. Even if they don’t fully believe in them. Because Agile sells.
Could a more flexible “mixed method” approach work better than Agile?
Right now it’s very hard if not near on impossible for a project lead or product owner to break from a scrum runs or “Agile” way of working in full flow.
Project leads just don’t tell management the teams getting roles reallocated and they are switching to waterfall for code quality or internal process optimisation reasons after all the pre-sales and sign off process has been in the name of Agile.
It just does not happen.
But it should.
Or at least the option to mix your methodology based on the changing requirements and phases of the project, or as a result of the lessons from each delivery.
Here’s what we’ve been building to..
What is MMA?
MMA is the pre-defined cross team agreement to “mix” development methodology and apply them as subject to the phase or status of the project to delivery a product faster and to a better quality than if any single method had been used.
How MMA would work
Under a codified “MMA” approach, the project lead can change development methodology as appropriate at any stage in a project as pre-agreed or in response to a change in circumstance and for their project methodology “mix” to be accepted and anticipated by both the development and overseeing management or client team.
Just like in real mixed martial arts where fighters of varying core martial arts competences evolve and adapt as they learn which discipline works best through the various fighting phases, so too would MMA methodology apply the most efficient method and processes to the evolution and status of the development project.
- The four principles of Agile
- Then came the codification
- And many Agile projects were Agile in all but name.
- Was Waterfall all that bad?
- Why this return to pure Agility might noty happen anytime soon...
- Could a more flexible “mixed method” approach work better than Agile?
- What is MMA?
- How MMA would work
- Principles of MMA
Principles of MMA
Lets now try to button down the core principles of this mixed methodology approach “MMA” to software development;
Pre kick off, the Project Lead proposes a “Mixture” of their expected development methodologies they intend to utilise to deliver the project as an approximate percentage and in a phased time line.
“Project Bout” Audience
The management and delivery team can challenge the Mixture for the purpose of understanding the benefit to each phase of the project and preparing the team for any expected or adaptive switch in methodology.
The Referee / Check in
During the project the core team, i.e. those who have most insights into the real deliveries and efficiency of the development cycles, can consult the Project Lead about switching methodologies due to an expected change in phasing, an unexpected problem or change in requirements or because the current methodology, for whatever reason, is not delivering the expected productivity or momentum.
At any point in the project with necessary notification the Project Lead can change the phase of the project and switch methodology and responsibilities. This could also allow more senior and experienced team members to fulfil their contribution potential which can often be obscured by scrum style working.
At the point of each key delivery or “bout end” the development team should assess which methodologies were most successful and which methodologies simply did not work within the inherent constraints of the organisation and project and how that could that be changed in the future, much like how actual MMA fighters are constantly reassessing the success of their moves and counter strikes through the standing, grappling and ground phases of their fights.
photo credit: MAZA FIGHT JAPAN
MMA Development Methodology in Summary
This codified use of a “Mixed Methodology Approach” under a pre defined and understood environment, at the very least, brings to the surface the concept that all methodologies have their strengths and weaknesses in certain situations and blindingly adhering to the latest iteration is not much better than refusing to learn and implement new methods.
In practise, could MMA work in a real “bout” with all the upheaval in roles, processes and possibly software played out before a client audience? Well, if you could handle that and deliver better than using just one methodology and process then that would makes you a true MMA fighter.
And MMA masters statistically beat single discipline experts due to the ability to apply the best discipline to any given phase of the fight.
And that would be pretty cool.