Well, here we are in this “new age” of project management, where if you’re not talking Agile, you’re not talking. After all, it’s the methodology by which all your project woes from years past go away, right? RIGHT???
What if Agile is not really what it seems to be? What it seems to me is that it’s been oversold. Literally oversold by the marketing folks. And oftentimes poorly applied or executed. Scrum-dee-dum-dum.
Let’s take a brief look at how we got here (Sprint 1), then discuss pros and cons (Sprint 2), and finally consider the rising popularity of the hybrid approach (Sprint 3).
The Agile Manifesto
Back in 2001, when turkeys roamed the Earth, a group of software renegades (only 17 or so) gathered at a ski resort in Snowbird, Utah, to discuss better ways of executing software development, in terms of how it’s imagined, created, and delivered. (In that regard, I’m surprised they called it “Agile”, and not one of the Snowbird trail or lift names like Gadzoom, Think Young, Regulator Johnson, or Pucker Bush, for you Western skiers out there.) Legend has it that these smart people didn’t agree on much, but what they DID agree on became the Agile Manifesto. Note that the Agile Manifesto is geared to software development and was created by software developers, which is very important and relevant to what its future has become — more on this later.
The Agile Manifesto has as its core tenets the following “this-over-that” edicts:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Translated, it dictates that whenever possible, you should put people over process, focus on making working software and not documents about it, shake hands with your customers and work with them rather than fighting over T’s and C’s, and be open to change because it will inevitably happen. Following from this, there are also 12 principles that further outline the process. (See www.agilealliance.org for all the details. If you want to see how convoluted it can get, click on ‘Subway Map to Agile Practices.’)
The odd part of this is that by virtue of this declaration, the creators of Agile took what was predominantly a non-interactive task, performed by some of the most introverted people on Planet Earth, and transformed it to force interaction and collaboration. This, in hindsight, may be their greatest accomplishment and a primary factor as to why Agile works much of the time, at least for software.
The Benefits of Agile
Agile enables organizations to better cope with the (software?) change that’s inevitable during the course of a project. The reason for that is that there isn’t as much of an upfront effort to lock the process and the details down in stone. Using daily scrums within short two-week sprints, small teams can stay communicative and ensure gradual progress toward a small set of defined goals, hopefully leading to the larger end goal. Hey, who has the pack of Post-its?!
Agile got us out of the traditional linear approach to executing projects, which seems okay, because the projects never ever went entirely linearly anyway. The Waterfall projects always fell into some sort of unforeseen ‘gotchas’ that sent the projects sideways, and you could only cross your fingers that these happened earlier in the projects rather than later, when a misstep not only could result in major costly rework or an unusable system, but could cost some managerial jobs as well, or even the phase-out of whole departments. In a utopian world (and I think it’s where teams of unicorns are the programmers and planners), this would never happen. Enter Agile.
The Harvard Business Review, in a 2016 article entitled, Embracing Agile, states: “By taking people out of their functional silos and putting them in self-managed and customer-focused multidisciplinary teams, the agile approach is not only accelerating profitable growth but also helping to create a new generation of skilled general managers.”
It’s supposedly the embodiment of the ‘Work Smarter, Not Harder’ mentality. But is it?
Off the Rails
We could go now into a discussion of all kinds of variants of Agile, and a plethora of success stories in which people deride the Waterfall method. But I’ll spare you. The point I’m about to make is that there tends to be an assumption that Agile means nimble, and nimble means fast, and fast means as-fast-as-possible, and THAT too often translates into non-ideal, human-related issues such as lack of sufficient planning, omission of key details, and poor execution. Couple that with inertia of development in which the Agile method prevents the very rework that would be necessary to compensate for initial missteps, and you aren’t necessarily in a better place.
So, let’s look at some of those details. Building a physical, or even a purely digital, system isn’t only about SOFTWARE development for the sake of generating lines of code, it’s about functionality and whether the overall design is sufficient, the interactions are appropriate, the engineering is sound, the product doesn’t fall apart or crash every minute, and importantly meets ALL the requirements that were thrust upon the project team. This is the essence of why rules and methods for software development don’t necessarily always translate well into overall project methodology, or especially into other arenas in which Agile likes to be applied these days.
Failure To Plan Is Planning To Fail
The old adage ‘Failure to plan is planning to fail’ seems to be appropriate here. With Agile, there’s less thought up front, by definition. This is what sets it vastly apart from Waterfall methods. As a result, there’s less plan-out of functions, features, architecture, etc. This almost always gets the Agile team in trouble at some point, but hey, they’ll just Agile around it! (Like your favorite NFL running back.)
Software, by its very nature, is highly changeable at any point in time. That is, until you’ve written enough of it that it would cost a boatload of Kuwaiti Dinar to throw the bulk of it into the weeds and rewrite it the right way. Architectures matter. The initial architecture chosen must be adaptable and flexible enough to be able to incrementally add each and every feature at any point in its Agile development process. Sadly, this is most often not the case, because it CAN’T be, unless your team is so astute and keenly aware that they foresee everything (remember that this was a problem with the Waterfall method…).
Architectures matter. The initial architecture chosen must be adaptable and flexible enough to be able to incrementally add each and every feature at any point in its Agile development process.
The incentive and mandate of the Agile Manifesto is to deliver working code as soon as possible. The first architecture you pick, given that there wasn’t much time spent in planning, is not likely to accommodate ALL of the aspects of ALL of the features. This results in patchwork of code, often by multiple different coders, that has latent bugs, is difficult to get or keep working, or in the worst case, absolutely prevents one or more features from being implemented later in the program, due to that feature’s negative impact on the pre-existing architecture, or the architecture’s inability to accommodate the new features.
The notion that you can just keep incrementally writing/re-writing/patching successfully only holds true in the best of cases. The team can paint itself into a corner. The appropriate solution in that case is to escape by stepping on the paint, then repaint (re-do the work). However, due to cost and time constraints, sometimes the paint is allowed to dry, and that corner is just not repainted (you’re stuck with it).
Moreover, the desire and pressure to complete a set of tasks within a prescribed sprint time often results in a project team taking shortcuts that knowingly will result in problems in the future, but the common notion is to handle those problems in future sprints. Unfortunately, many of the problems that have historically plagued Waterfall projects in the past — quality issues, poor demos to customers, missed deadlines — are often magnified by an Agile project.
Tortoise Versus Hare
We all know who won this race. Yet the deluded folks put their money on the tortoise. Sure, the tortoise will win a significant percentage of the time, depending on circumstances. However, the moral of the story is that you should put your money on the hare. The hare will win a greater percentage of the time, over the long haul.
There are apparent things that make Agile very attractive, and these are also why it’s successful much of the time. The productivity of the project team appears to go immediately through the roof, and when they handle a big issue early in the project, well, it’s beers for everybody. However, if we were to look at time-to-completion on projects, as well as feature sets, quality, and customer satisfaction, it wouldn’t be shocking to see Waterfall (properly executed) give Agile a run for its money. When the Agile team gets wrapped around its own axle, it turns into the Tortoise.
Application of Agile to Alternate Industries
As stated earlier, Agile Methodology and the Agile Manifesto were created and targeted to one specific industry — Software Development. Unfortunately for some, the success of the Agile methods for software have spawned a huge, wide-ranging number of efforts to apply the methodology to other non-software-related industries, in terms of how organizations plan and execute. Some of the results are common sense and a benefit, but some are disastrous. Seems to be a mixed bag. Exacerbating this are armies of software firms monetizing the imparted Agile desires by making tools to help your organization “Be Agile.” Caveat emptor.
To be clear, making your bureaucracy more agile is a good thing, and that includes the following:
- Smaller teams
- More frequent project feedback
- Cross-functional collaboration
- More contact with customer
- More value delivered for less work expended
- Improved employee morale
This is the essence of Agile, but like most complex things, the devil is in the details. Many new organizations crop up, and say to themselves, ‘I don’t have to plan, I’ll just be agile!’. For those organizations that aren’t good at ‘pre-think’ and documentation anyway, Agile methods seem to alleviate some of the burden of that. Brings to mind another saying… “Watch what you wish for, ’cause you just might get it.”
Agile in a Contracting or Consulting Environment
Use of Agile methodologies in contracting or consulting relationships can be a snake pit, especially in fixed-price scenarios. One positive incentive might be the perceived speediness of incremental or interim deliveries, to the delight of a client. However, if traditional project management principles are not handled appropriately — mainly management of risk, known unknowns, scope/feature creep, and adherence to schedule and cost — the result can be a disaster. Also, the lack of upfront documentation presents a problem for typical downstream functions such as test, contract manufacturing, and training, since aspects of the project can still be changing well into the timeline.
Hybrid Project Management — the Solution to it All?
It’s not surprising, with the hindsight of some colossal failures of Agile methodologies on certain types of projects, that a hybrid approach is gaining popularity. Hybrid Project Management combines the methods of both Agile and Waterfall, and it can be tuned to the size and particulars of the project. Projects are broken down into manageable components by discipline or function. Waterfall is used for the overarching aspects of the project, while Agile is used for the smaller building blocks. By using this combined method, the requirements and forethinking for the project can better be covered, while development of the smaller piece-parts can be sped up. There’s even a Hybrid Project Management Manifesto floating around in web-land, but it’s hard to tell how official or widely accepted it is.
With both Agile and Waterfall having respective advantages and disadvantages, a hybrid approach seems to make the most (common) sense. The biggest variable there is how to apply percentages of each, and tailor the management style to the specific project.
Meanwhile, I’m trying to come up with an alternate name for Hybrid PM. Agilefall? Wagile? Suggestions welcome.