Pick Your Poison: Waterfall, Agile, or Cowboy?
Have development mythologies forgotten the business?
Join the DZone community and get the full member experience.Join For Free
If you watch much TV or read much fiction, you are likely familiar with some typical character archetypes. First, there is the kid who does everything by the book and does well in school. Second, is the character that builds a business by testing the limits and getting the job done while still coloring in the lines. Third, the wild child character throws all of the pieces of a problem in the air to see how and where they will land.
When it comes to project management, there are three main types, just like the characters mentioned earlier. Waterfall is the cautious and rule-abiding kid. Agile is the businessman testing the speed limits to get a product out quickly. Finally, cowboy is the rule-breaker who just wants to get the job done without overthinking the rules they may be breaking.
Each software development approach delivers features and new functionality differently. Waterfall uses well-planned, long-running 12-18 months cycles with lots of contact with technology consumers to understand, document, plan, and build. Agile sought to shrink timelines and deliver functional improvements in weeks instead of all at once a year later like waterfall. Agile is a journey to improve over time. However, some developer critics claim it is just a mini waterfall when not implemented well. The third approach is cowboy. Developers drive cowboy without any formal agile journey or strategy. They want to push code out the door fast and get it in the users' hands. They don't feel the need for all of that process, documentation, and ceremony.
Waterfall: Cautious, Reliable, Slow Churning
If you're reading this, you might have your PMP certification. Even if you don't, you likely have some experience with a waterfall project. Whether you have been on the backend of a project or as someone who spearheaded the effort, waterfall project management used to be the standard for large enterprises. Let's look at some pros and cons.
Perhaps the most significant upside to Waterfall coding is that it is meticulous. Every T crossed and every detail documented before the project gets underway. Therefore, the likelihood of making mistakes or mishaps is very slim. Traditionally waterfall methodology was easy to budget and forecast staffing, it was all in the plan.
When you're neck and neck with the competition, a 12-month turnaround time on a big project just isn't going to cut it. Think back to when Bank of America released its "Save the Change" program. Rounding up people's charge totals and putting that extra change into their savings account was revolutionary. It created such buzz that other banks wanted to develop their own version of that program to compete. It would be hard to tell business, happy to do that, come back in 12 months. Unfortunately, with waterfall methodology, the turnaround is so long that the original project scope is no longer innovative as it once was. It's not that the teams produced bad requirements. It is more likely that the market and the world innovated and progressed faster than the teams can serially deliver new functionality.
Agile: The Little by Little
When organizations realized that as great and reliable as waterfall project management is, the turnaround time was simply too long. The IT world changes too fast, and shorter schedules are needed. Companies want to release digital products much quicker than waterfall allows. This is how the agile manifesto was born. Put simply; agile projects deliver functionality in smaller increments releasing features over time. Each set of stories build on top of each other until the project achieves its final goal. Let's look at some pros and cons of agile coding.
The most glaring benefit to agile projects is speed, at least compared to waterfall projects. Delivering software features and stories in smaller increments helps reduce the likelihood of your solution being too late and missing an opportunity to serve a potentially lucrative trend. Today, requirements change rapidly as technology advances, customers expect more, and competitors create new pressure. The most significant advantage of agile projects is that you don't waste time planning for software that may change. Of course, scope creep happens and usually causes project delays, but agile projects can reprioritize, update, or remove a feature or story and not lose months of documentation. Agility is a big advantage to otherwise lengthy documentation and development cycles.
Like with any "quick solution," agile coding has its downfalls. The main disadvantage with agile projects is the process itself. Many software development organizations push back and are tired of overly structured processes. Since you are releasing small increments of software faster, each iteration relies on your DevOps processes more than in waterfall. Organizations still depending on manual processes, requirements gathering, deployment, testing, and security scans will find that manual processes are bottlenecks. More software releases mean development organizations need automation to become efficient.
Agile projects can be executed well and have many advantages. Requirements and business use cases are closer to development, therefore, reducing delivery iterations. Business users must approve and sign off on stories so the right features are delivered at the right time. But in many cases, all of the methodology changes and new tooling ends up over-focused on development processes vs. really focusing on the end users' feature requests.
Cowboy: Rule-Bending Toss Up
Much as the name implies, cowboy coding is the equivalent of the wild west circa the mid 19th century. If you're looking for a way to release digital products at lightning speed and have no concerns about bugs, malware vulnerabilities, or compliance issues, and just focusing on what the customer needs, cowboy coding is right for you.
Like agile coding, cowboy coding promises to deliver your digital projects quickly and efficiently by cutting corners and throwing the process out the wagon window. I have spoken to many developers, and they say, "yes, we are agile. We get stuff done." Now the "done" is relative. Did the code meet quality standards? Does it pass a security audit? Did anyone review the feature with the end user for approval? One of the first things to get thrown out is user feedback and signoff. Does this count as done? And of course, did anyone bother to document it? Is it done if no one wrote it down? Okay, so these are all the Cons to Cowboy. There are no Pros to the cowboy approach. The focus on user and feedback is deprioritized, and the fact that development delivered an update becomes the goal.
Which is best? There could be tons of debate. Some will state they don't need to follow a formal development process because they get code to their customers. Some would argue that the process and documentation are the most important. The debates will continue long after people read this blog.
The essential item lost in the process is the application consumer or the business analyst who is providing the requirements for the feature and stories. Instead of getting into the religious battle of methodologies, I suggest software development organizations focus on the end deliverables. A paradigm shift needs to occur, and we need to use the power of technology to make building software solutions faster and better. I don't mean low code because, by name, it is still code and still needs to be maintained.
We need to allow the business to author software to do what they want when they want it. Analysts should be able to implement business rules without requiring an entire development project and be forced to wait unnecessarily. We need to move more towards model-driven development and provide business users abilities to participate actively vs. only provide documentation of what they want.
For business users to be able to build or modify their own workflows, IT groups need to provide secure access to data via easy-to-use tools and platforms. And these platforms need to be easy to use. As we democratize technology, businesses need to move fast. They cannot wait to train people to become technologists. They need technology that already understands people so companies can transform TODAY.
People understand a conversation. It is the simplest way for people to communicate with each other. It is also the simplest way to get information from a system. For example, a customer service agent may ask, "Does your order need to be expedited?" An executive may ask, "Are we on track to meet our deliverables?". People should be able to interact with technology the same way they interact with each other, via a conversation.
Given the right circumstances, your people can ask your systems for information just like they would coworkers. It's a simple idea. Asking for information from systems in a conversation removes any training requirements as you democratize technology in whichever development method you choose. Therefore, the real choice is whether to make your people think like technologists or make the technology think like people. Moving to a model-driven approach using intelligent automation allows requirements to reside in the actual business logic vs. waiting for changes on a backlog. The best way to get velocity and meet changing business needs is to provide intuitive tools and remove technical barriers regardless of the development methodology.
Opinions expressed by DZone contributors are their own.