Agile Development

Agile Development banner

What is Agile?

Agile is a development methodology that has it’s roots in earlier efforts to improve software development, “most notably Extreme Programming (XP), Feature Driven Development, DSDM, PRINCE and even Lean Software Development.” (1 Artisan Software Consulting, LLC) In 2001, the Agile Manifesto was born. The manifesto reads:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Agile Manifesto
This is a bold statement and a sharp departure from the traditional “waterfall” development approach that was heavily used in software development at the time. Further reading and analysis of the Manifesto’s principles, reveals an interesting alignment with basic Lean Manufacturing principles such as:

  • Limiting work in process (WIP) to deliver work more frequently
  • Providing people working on the project the environment the support that they need
  • Shortening development time to gain early feedback from customers (stakeholders) to prevent rework
  • People (developers) should be working at a constant pace rather than intense efforts followed by lulls after phases have been completed

There are two main software development approaches in use today: Agile and Waterfall. It is important to note that other frameworks such as Scrum as DevOps that are built on the Agile approach are rapidly becoming more prevalent in today’s software development world.  But in order to understand better as to why Agile (Scrum and DevOps) should be utilized more often in today’s software development world, it is important to understand some of the challenges that accompany a waterfall software development model:

It takes a long time.
In a traditional waterfall development project, work happens in long timelines that span requirements gathering, software development, QA, Release, etc. At any point, requirements can be easily be missed, critical hardware or functionality could be missing, or stakeholder requirements change resulting in significant amounts of rework in the project.

Agile Development Graphic

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.