One of the hardest parts of software development is the communication of what actually needs to be done. Most of the time the customer or business doesn’t have a clue what they want. They know they have a problem and they know they are in need of something to fix it. This is sometimes easier when they don’t have a clue, because sometimes the customer may think they have the perfect solution but cannot communicate it or it is not technically feasible. These two situations, both when the customer says “I don’t know what I need” and “this is what I need” and everything in between are software development nightmares if a waterfall approach is taken.
Developing a product in a phased approach is like walking around blindfolded, playing Russian Roulette or rolling the dice and hoping what comes out at the end is what is needed. The Waterfall development methodology is great for manufacturing or construction where a planning – design – implementation etc. approach can work well. Software is different, it is a strange beast that is alive and evolving and keeps me up at night thinking about UI design or how to make a function faster…I digress. A software project needs to evolve, have failures and throwaway code.. and this is where agile comes into play perfectly.
With traditional software development the customer or business won’t actually see a working product until the of the implementation phase. Not only do the end user not see it until the end but chances are the programmers may be the only ones that know what it looks like. This amazing youtube video shows how the SDLC typically goes with a phased approach methodology and therefore poor communication.
Agile practices and Scrum don’t prevent imperfections, a buggy product or the wrong product from being delivered. They simply allow issues to arise and be fixed much sooner then they would in waterfall or traditional development. The key here is sprints -which involve creating a “potentially releasable” product every 2-4 weeks, demonstrating this to the product owner and other stakeholders (sprint review), listening and learning (retrospective), re-prioritizing (sprint planning), and repeating.
Agile and Scrum create feedback loops that force communication to happen. Communication is key when it comes to software projects. Chances are at those first few sprint reviews the stakeholders may say something like “…yeah i guess our original thought on how that was going to work… doesn’t really work. We want this instead now. And this too.” Or the development team misunderstood some of the initial requirements. Its very important to understand here that nobody is in the wrong at this point getting these types of issues out of the way every few weeks makes for a much better product in the end. Agile drives communication.