A well worn phrase in planning is, “If you don’t know where you’re going, you’re probably not going to like where you end up”. What this implies is if you don’t plan accordingly, the outcome is not likely to be favorable.
In software development, we have two common methods for the planning and development of software. Between these two methods, you’ll cover most of the project planning that’s likely to be encountered.
The first method is called the ‘Waterfall process’ and is the most well-known.
The Waterfall Process
With this process, once requirements are worked out, these requirements dictate the Design phase. Designs then feed into the implementation phase (the programming), which in turn leads to the verification stage. This phase is where you assess if everything meets the design (and therefore meets the requirements). Finally, there’s the maintenance phase where you look after the software in order to work out when the requirements changes, thus initiating the Waterfall process again.
For reasons that are very hotly contested in debates, this approach doesn’t work for everyone. Sometimes, it’s because people don’t know what they want, so it falls at the first hurdle. Other times, it fails because people don’t like to be rigidly held accountable for the requirements they come up with. Whatever the reasons, there’s a second methodology to choose from.
The Agile Process
‘The Agile Process’ throws the waterfall methodology out the window. Instead of having big projects, it attempts to break projects into small “increments”. The end game is still the same (turn the requirements into a product), but the way you get there is slightly more “cyclical” in nature.
The way everything is done, to accommodate this shift in planning, changes as well. With Agile, you may not necessarily have a full game-plan, so you have to meet more frequently. More meetings can mean more interruptions and changes, but that’s the price you pay for not knowing what you want, or having a lot of meetings up front like in the Waterfall process.
This leaves the Agile process open to abuse which can lead to problems. The three most common issues outlined here are all well known and actually fuel many jokes in the programmer community because the effects frequently border on the ridiculous…
The first common scenario
Many members of management and other stakeholders in a project often confuse the verb of “being agile” with the name of the “Agile process”. As a result, you’ll often hear about programmers that are half way through the “implementation” phase acting like a kicked hornets’ nest because they just found out that the managers have changed the goal posts at the “planning” or “requirements” phases – and that’s not supposed to be the way this process works.
This “look at me being agile! You need to be agile, too!” approach is usually met with friction when the two groups (management and programmers) then have the concomitant debate about why they didn’t use the waterfall process to avoid whatever the issue du-jour is.
The second common scenario
Stakeholders think that by bypassing the Waterfall’s directive to have them first think about what they really want, then document and design precisely what they want before any programmers apply hands to keyboards, that things can move faster and with less guidance in the agile process, when in fact the opposite is true. Because you’re doing things in small iterations rather than thinking about the bigger picture, most projects hold daily “scrum” meetings precisely because of this.
The third and final common scenario
Stakeholders sometimes don’t produce the expected Requirements and Design documentation that the Waterfall process requires. The common justification for this is that they are “being agile” (there’s that phrase again) about requirements.
However, the Agile Process requires them to attend and/or lead the daily agile scrum meetings (precisely because this isn’t the Waterfall process) during implementation, yet they simultaneously view the entire project plan as something that has already been dictated clearly to the programmers in its entirety, and therefore why should they be there everyday? In other words, they’re stating that they’re “being agile” when the reality is they’re being lazy. This is then compounded when they underpin their viewpoint by falling back on Waterfall process (“I told you everything before”) logic. Obviously, a very lightly planned out project with major holes in it’s design, and arbitrary changes to the end-goals once the development cycle has started, leads to yet more unnecessary friction.
The “Water-scrum-fall” approach
Traditional constraints like not being able to distribute incremental daily builds because of internal bureaucracy or other departments having backlogs on testing, documentation, staging deployments, often leads to the introduction of the hybrid “Water-scrum-fall”. This is where projects are done as “agile” in one team but coordinated company-wide through traditional waterfall processes.
A final to point to note is that many programmers find the Agile process very irritating because usually programmers have the trait to “Find out what we’re building before we build it”. While the Agile process (when done correctly) can still accommodate this, it very rarely does because it’s abused so much. Somehow, the Agile Process that was supposed to solve rigidity issues when a full plan isn’t known ahead of time has evolved into a nightmare of abuse and laziness and the waterfall process that would avoid these issues is totally ignored at the same time.
Have some questions about waterfall or agile development? Contact us for more information! We’d love to help!