Agile (and its surrogates) vs. Waterfall Methodologies

The most prominent methods in developing software are Agile and Waterfall methodologies.

Waterfall methodology

Your project is worked following the Waterfall methodology when the eight project phases  (conception, initiation, analysis, design, construction, testing, implementation, and maintenance) have to be completed before the commencement of the development phase.

Pros

1. You know what to expect at the end of the project, in terms of sizing, costs and timeline.

2. Minimal impact in the event of high turnover thanks to the detailed documentation.

Cos

1. No changes are allowed when a task is completed, even if the initial requirements were faulty.

2. The testing phase is only done at the end, hence bugs are only discovered too late and a new code needs to be written from scratch.

3. The plan would not take into account the evolving clients’ need.

 

Agile Methodology

Agile is a framework for developing and sustaining complex products that follows an incremental rather than a sequential design process approach.

Development work focus on launching a Minimum Valuable Product  – from a end-user point of view – then by enhancing the MVP incrementally by working on flexible modules. The work on these modules is done in weekly or monthly iterations, and at the end of each iteration, project priorities are evaluated and tests are run. These iterations allow for bugs to be discovered, and customer feedback to be incorporated into the design before the next sprint is run.

 

Pros

1. It allows for changes to be made after the initial planning, but prior to the commencement of the spring/iteration period.

2. It allows the user’s feedback to be incorporated in the process by modifying the features in the backlog accordingly.

3. The testing is performed at the end of each iteration ensuring bugs are captured and fixed within the development cycle.

Cons

1. You  don’t know what to expect at the end of the project, in terms of sizing, costs and timeline.

Scrum vs. Kanban

Scrum and Kanban in software development are specific form of an agile software methodology.

Scrum is a framework that leverages team commitment as change agent, whilst kanban is a less structured model for introducing change through incremental improvements.

 

 

 

 

Advertisement

Agile: features estimation

The first step in Agile estimation is the writing of the user stories, that are a short description of the functionality.

The user story is usually structured as: “As a <role>, I want <goal/desire> so that <benefit>“. It defines the main agent (the end user, the business user,…), their need and the benefit on producing that feature. Each story is firstly estimated by Agile team in terms of day of work unit or points.

Estimating is not an easy task, and to keep the process manageable:

  1. Stories estimation should be in the range 1-10 points.
  2. New stories should be estimated in relative terms: We needed 5 points to do XYZ, and we estimate XYZ to do a similar job.
  3. Take into account the implication of the Cone of Uncertainty (wikipedia):
    • Estimates (e.g. on duration, costs or quality) are inherently very vague at the beginning of a project.
    • Estimates and project plans based on estimations need to be redone on a regular basis.
    • Uncertainties can be built into estimates and should be visible in project plans.
    • Assumptions that later prove to be mistakes are major factors in uncertainty.
    • Include bugs fixing in your forecasts.

 

Backlog

Agile Software Development: the Artifacts

Scrum is a framework for developing complex products. It is an interactive, incremental approach to optimize predictability and control risk.

The Scrum Artifacts

Scrum artifacts are tangible by-products produced during the product development. These artifacts consist of the requirements for the overall project, and each individual phase of the project itself.

PRODUCT BACKLOG

The product backlog is an evolving, dynamic and ranked list of requirements that might be needed to made the product. The product owner is responsible for the product backlog, including its content, and ranking.

The product backlog lists all features, functions, requirements, enhancement and fixes that constitute the changes to be made to the product in future releases. In agile terminology, the product backlog item are called user stories.

The user stories are the smallest units of work, and its goal is to delivered customer’s value at the end of the iteration. A good user story should be:

CHARACTERISTICS OF A GOOD QUALITY USER STORY: INVEST
Letter Meaning Description
I Independent The user story should be self-contained, so that there is not a dependency with another story
N Negotiable User stories, up until the start of the iteration, can be rewritten and re-ranked.
V Valuable A user story must deliver value to the end user
E Estimable The story is precise and concise so that the development team can estimate it.
S Small The user story development should conclude at the end of the iteration.
T Testable The user story and/or its related description must provide the necessary information to make test development possible.

EPICS

Epics are feature-level work that encompasses many user stories. Epics are:

  • A Group of related user stories.
  • They use the same wording and format as the user story:
    • Short description;
    • Acceptance criteria;
    • Estimate.
  •  Should not be worked on directly.
  • Can be considered a project.
  • its works can spam more than one release and encompasses more than one product.

The Epic is typically used to monitor and track the development work toward the close proximity of the product release/launch.

THEMES

Themes are feature-level work that encompasses many epics. They are:

  • A Group of related Epics.
  • They use the same wording and format as the Epics:
    • Short description;
    • Acceptance criteria;
    • Estimate.
  •  It’s a tracking tool to monitor the overall direction.
  • It’s considered as a Portfolio.
  • It is also called an Adventure.

The Theme is typically used to discuss with the CEO and board members for tracking the overall strategy direction.