Didn’t you get the updated document?
In a long drawn out software development project, there are literally dozens (if not more) of revisions along the way for a variety of documents including requirements documents, test plans, code, etc. This results in frustration and A LOT of rework as people invariably miss information and need to review and discuss changes to see how it impacts functionality.
Very regimented
Normally in a waterfall project, one phase doesn’t start until there is signoff on the prior phase. This can present problems if teams being part of a future phase want to start work on something before it is supposed to be started. This translates into wasting resources time and capacity as they could be involved in another project when the first project is ready for them.
But we thought you wanted this?!
Waterfall projects are set up so that the business or stakeholder provide a project team all of their requirements, scope, etc. when the project starts. The team goes off and not much is heard from them as they work on the project. When it comes time to deliver the project, stakeholders may be less than enthusiastic about what they are seeing as it may not even be close to what they were looking for. Next step? Redo all the functionality necessary to deliver what the customer wants.
Now let’s contrast this with an Agile development project.
It’s about collaboration
Agile is about collaboration between teams in order to build something of value. Instead of delivering a finished product at the end of a long development cycle as in Waterfall, Agile works in small “sprints” or predetermined lengths of time (i.e. 2 weeks) to deliver a minimum viable product. This helps to reduce the risk of developing something that the stakeholders don’t want and causes issues to be raised much sooner than in the waterfall approach.
It’s fast and flexible
Agile is built on the foundation that it should be flexible in its approach and utilization. This is ideal when requirements are vague as the team can figure out the requirements and can pull in whomever they need to help them build the functionality. This can be anyone including Business Analysts, Process Owners, SMEs, etc.
The team sets its pace and figures out what is important to work on.
In Agile, the development team works in “sprints” that typically last two weeks and works off a “product backlog” (a list of “requests and asks”) from the Product Owner (who represents stakeholders, internal and even external customers.) The development team determines based on the product backlog, what needs to get built and what other resources they will need to build it.
There’s a feedback loop at the end for the everyone
After the two-week (or however long) sprint, there is always a product demo for the customer. This allows the customer (whomever they may be) to see what the developers built and provide feedback to them. And yes, it can be “this isn’t what we wanted!” This feedback is added to the “product backlog” and is then worked on by the development team. Instead of waiting months to see functionality, the Product Owner and Stakeholders are now seeing functionality after just 2 weeks and are providing feedback on it.
The team figures out what to build, how to build it and solves their own problems
Development teams utilize daily meetings called scrums, but the entire team meets at the end of each sprint. This is referred to as a Sprint Retrospective. It provides all members of the team including Developers, Product Owner and Scrum Master an opportunity to provide feedback on the prior sprint. This can include topics as diverse as asking for additional resources to offering suggestions on how to improve how something is developed.
In the end, the goal of an organisation is to provide the customer value (product or service) quickly and efficiently in order to make money. The Agile methodology represents a structure to help support these objectives through improved software development. In today’s world, where so much of organizations functionality and ultimately profit and operating costs are based on technology, it is prudent to develop useful, functioning software in a timely manner.
If you would like to find out more, visit our F & S Servics page, or contact Keivan Zokaei.
