Since its introduction nearly 20 years ago the Agile Methodology has seen a rapid ascension to the top spot on the hierarchy of software development project management models. And to be honest, it’s not hard to see why. Agile is flexible, incorporates user feedback, and progresses iteratively—the perfect recipe for turning out a great product, fast.
It’s also not hard to see why Agile became popular when it did: back in the early ‘00s, software development was the purview of small startups often competing against other small startups for dominance in their niche. Small teams moving quickly was the only way to stay ahead of the competition while also keeping the investors happy.
But things change.
Where once there were dozens of scrappy startups shaking up the tech world, now we have a much smaller number of much larger organizations. These companies have processes in place and no good way to circumvent them when it comes to one department that wants to operate like the old days. Practices that worked fantastically with a team of 12 all in the same office may not work quite as well when you’ve grown to multiple teams of 100 spread through offices on multiple continents.
So has Agile’s time come?
No, we don’t think so. That said, there’s always room for improvement. Especially in a fast-moving industry like software where change is not only inevitable, it’s the norm. Just as companies pivot to meet changing demands, the frameworks and methodologies they use need to remain flexible to compensate. To wit, there’s a growing realization in the software world that Agile is not a one-size-fits-all PM framework, which brings us to our topic for today—how to keep Agile relevant for your project.
|
Jumpstart your Agile software development! Join us for a webinar to get tips from the pros.
|
What Is the Agile Methodology?
From the ‘70s to the ‘90s, a growing number of software companies sprang up and began to implement lightweight, iterative project management solutions to push their products out.
These models were called lightweight to contrast them to the prevailing method of the day, Waterfall, which was considered “heavyweight” project management due to its regimented and highly structured model. Increasingly, Waterfall was being viewed as overly restrictive to the small, flexible development teams and startups in Silicon Valley. The result of heavy methodologies like Waterfall is that projects begin to slow down, and from the time an initial business need crops up to the actual release of a piece of software could easily take multiple years or longer—by which time your needs have changed and much of work will have to be redone.
Enter the Agile Methodology. In 2001, 17 heavy-hitting software luminaries met in Snowbird, Utah to iron out a new way of doing software. This meeting led to the publication of the “Manifesto for Agile Software Development,” a document that laid out the underlying principles of the framework.
In the years since, there have been addenda to broaden the scope of applicability to incorporate other industries already following similar protocols (aerospace and manufacturing, for example, which were already using a version of Lean PM). During this time, the framework also expanded to incorporate most of the pre-existing models then in use under the shared umbrella term, Agile.
Besides Agile, What Other Options Do You Have?
Nowadays, Agile is common enough that it enters into virtually every conversation about how to run a software development project. This makes sense, considering that its principles are often a big help in keeping you flexible and preventing the kinds of disruptions that are common to more heavyweight methods. Of course, it’s no good throwing the baby out with the bathwater: different methodologies also have pros and cons, and some of those pros can be incorporated into frameworks that also incorporate Agile principles.
Waterfall
The granddaddy of all project management methodologies, Waterfall made the jump from engineering to software development in the early days of computers. Most early programmers were engineers themselves, so they simply brought a framework they were familiar with along for the ride.
Consisting of a strong focus on early-stage planning and requirements gathering, Waterfall is a linear and sequential model. Projects flow from one stage to the next, as a Waterfall flows downhill. This model leaves little room for iteration and there’s next to no room for feedback loops; water can’t flow uphill, right? At the same time, it can provide more direction than some of the other models that people consider.
Lean
Showing that unlike water, progress can flow in every direction, Lean came to software from the manufacturing world. Toyota, to be specific. After it was rolled out, it emerged as a strong subculture within Agile circles.
Lean lays out 7 principles for projects (that follow the original manufacturing model quite closely): Eliminate waste, amplify learning, decide as late as possible, deliver as fast as possible, empower the team, build integrity in, and optimize the whole. These steps actually helped Agile gain ground in other areas outside the software world.
Spiral
Not to give away the plot of today’s article, but the Spiral Methodology was an early attempt at blending some of the structure inherent in the Waterfall model with some of the flexibility found in Agile, et al. As the name suggests, the Spiral Methodology shows projects progressing around a spiral model.
This circling around allows for multiple passes through phases like prototyping and testing, while still adhering to a stricter timeline and set of stages. The ability to use iterative prototyping as well as repeatable validation procedures made this an attractive model from the outset.
Rapid application development (RAD)
This model has less emphasis on planning and more on adaptive processes, meaning it was one step further from Waterfall than some of its contemporaries. Today, RAD can refer to two things, either a general methodology where projects move forward quickly with a built-in assumption of multiple rounds of testing before release, or to James Martin’s specific approach, which he laid out in his book by the same name.
RAD has 4 primary stages: Requirements planning, user design, construction, and cutover. What made RAD stand out from the crowd is its early incorporation of user feedback loops during the prototyping stage. This had not appeared in any model previously.
There IS a Better Way Forward
And now we come to the main event—making Agile better work for varied scenarios. There’s no doubt that small, co-located teams can indeed thrive under the Agile framework. Larger international organizations are likely to have stricter financial controls or other SOP that makes it difficult to get projects greenlit without detailed requirements documentation, Gantt charts, etc.
Do you have clear, well-documented requirements? Stakeholders who are prepared to stay on the sidelines? Waterfall, all the way.
What about when you have a vague set of needs, not documented outside of a Slack conversation? Or stakeholders who are taking an active seat at the table? Agile will be your saving grace.
And for the majority of times when your situation looks like a mashup of these two idealized scenarios? What if we told you there was a way to blend the best of all methodologies, giving you the structure of Waterfall AND the freedom to iterate in multiple feedback cycles? Clearly outlined requirements will keep the stakeholders happy while your developers are free to experiment, iterating to their hearts’ content in their quest for the best solution.
This is the world of hybrid methodologies. Think of it as the wild west of software development, where experimentation and cross-pollination are the norms. Where nobody will look at you funny when you take the strict timeline and documentation standards of Waterfall and mix them with the continuous delivery Agile is famous for.
As you’ve seen, strict adherence to any one framework, be it Waterfall or Agile, can leave teams flailing. Milestones aren’t met, delivery is delayed, and when the product is finally ready, it’s not up to the most recent set of requirements. Maybe the solution you long for is finding the right mix of the four concrete stages of a Waterfall project, combined with the fast iteration and room for exploration found in an Agile shop?
A good hybrid software development model should provide you with the following:
- A people-first orientation. Cross-functional teams with no internal hierarchy keep things flexible and ideas flowing.
- Early, and frequent testing periods. Automated testing cycles allow for shorter feedback loops and higher quality standards from the beginning.
- A focus on user experience. Those shorter feedback loops mean users have input from early in the SDLC, and that means better UX integrated from cutover.
- Continuous delivery. Perhaps the single most important aspect of Agile, continuous delivery lowers the risk of disappointment upon cutover and elevates the final product to new levels.
One Such Hybrid Methodology: The Jaglion Model
Of the emerging competitors in the hybrid PM model space comes the Jaglion model. Adhering to the structured lifecycle of Waterfall while simultaneously embracing the flexibility of Agile, Jaglion lies at the heart of all our development projects at Intertec. This model shifts the focus from extensive planning and documentation to the collaborative aspects of development. Tool and platform agnostic, Jaglion can be implemented in a wide variety of environments and can help power a host of projects.
The Lean discovery framework gives projects just the right amount of upfront planning to achieve quick stakeholder buy-in, yet allows for rapid and iterative prototype-based experimentation cycles. Each iteration delivers a potentially consumable model for stakeholders to hold and do their own experimenting with while allowing for a quick return to a new cycle should requirements evolve and the project need to adapt. Round it out with advanced change management protocols that are compatible with common enterprise solutions and you have an all-encompassing PM framework.
Hybridizing PM models gives you the best of both, or all, worlds. Feel free to pick and choose the aspects that work best for you, your team, and your projects. Or select from the plethora of available all-in-one frameworks coming to market. There’s bound to be one that will suit your purposes, allowing you to use the best aspects of Agile to your advantage.
Learn More About Intertec’s Software Engineering and Support Services
Intertec specializes in building and supporting custom software for its diverse clients. Our experienced team of interdisciplinary professionals have experience at all stages of the software development lifecycle. Click here to learn more. Prefer a personal consultation? Go ahead and schedule a meeting with us here!
