Delve into Agile methodologies, compare them with Waterfall, explore planning techniques, and discover tools like SCRUM and Kanban. Gain insights into solving common problems with Agile.

This course is designed to help learners build an understanding of Agile’s process model and its different approaches and techniques.

To understand the advantages of implementing Agile techniques, the course begins with a comparison of Agile methods and the traditional Waterfall model. Then, you’ll get to know about different planning approaches to help users effectively adjust deadlines. Next, there’s a discussion on backlogs and different visual techniques, such as burn-down charts and burn-up charts, that help increase the efficiency of projects.

You will also learn Agile methodologies including SCRUM, eXtreme Programming, DSDM, Smart and Kanban, as well as the differences and similarities between these approaches. Finally, you’ll look at some common problems and learn ways to solve them using Agile methodologies.

Learn Agile Methodologies from Scratch

# Big upfront design

Even when organizations migrate to Agile, they remain in search of the kind of security that suits traditional projects. Development and testing are done in iterations, but analysis and design are done in advance. A classic design is completely written by domain experts and designers before starting iterations. This is called **big upfront design**.

This method is chosen in organizations that want to migrate to Agile but are afraid to let go of the traditional search for certainty. It’s feared that the whole thing will slide if all requirements aren’t elaborated on before the realization begins. This creates a mixed method with pitfalls:

## Complete and thorough


  The illusion remains that all
project requirements can be completely and thoroughly
elaborated this early in a project. Requirements change
20 to 25 percent on average during a project, even in
projects that assume all requirements have been elaborated.

## Progressive insight

   A project with a big up-front design creates long feedback loops. These run from early in the project when the requirements are elaborated until much later when a requirement is realized during an iteration. The insight developed in this period isn’t included in the original requirements.

## Time consuming

   The elaboration of requirements and design costs a lot of time, just like in the old days. Because this is used to distill a project’s security, such as estimates and schedules, all details have to be found. Many projects never even get past the requirements stage, often with high costs.

## Fixed price, fixed date, and fixed scope

   Because it’s assumed that the requirements are complete and thorough in this method, a plan is made in which precisely these requirements can be realized. The scope is fixed, so now the deadline and the budget can also be fixed. No matter how agile the rest of the project will be, it’s likely that this plan can never be satisfied, as becomes clear, for example, through progressive insight or unreal historical figures. A nasty side effect is that now the conclusion is drawn that Agile doesn’t work in our case. This conclusion is probably unjustified.

This can be prevented. The corrective measure isn’t even complicated. Only elaborate the requirements to a level that’s sufficient to use as a base for estimating and planning. Move the vast majority of elaborating requirements to the iterations. This shortens the feedback loop immensely and progressive insight is automatically included.
In reality, all of the above represents a substantial change in an organization’s culture. As a project manager, you need to let go of the traditional model. This also applies to the domain experts and designers who may have always done their work before the developers and testers appeared in the project.

This requires persuasion from the Agile coach. They should leave the team organization and roles intact as much as possible while clarifying that the work isn’t compromised, but is taking place when needed. Domain experts and designers are sensitive to arguments like faster feedback, the inclusion of progressive insight, and working more closely with developers and testers.


# No upfront design 

Too many Agile projects underestimate the importance of analysis and design, due to years of experience on Waterfall projects. Yet even in Agile projects, analysis and design are important. The major differences with Waterfall are the moments when analysis and design take place and the techniques that are used.

On Waterfall projects, the analysis and design are done before build and testing. On Agile projects, this is done during iterations, and then only for those work items that can be realized during that specific iteration. However, it doesn’t hurt to identify the requirements that are the basis for the work items in the backlog of an Agile project early.

This inventory, and determining the work items, are also analyzed. During the first iteration, carry through with this analysis as far as necessary to perform the next step. Determine the requirements and work items, an estimate, and a plan. That’s enough. That’s YAGNI. Avoid spending months and months on analysis and design. Determine what’s needed and avoid detailing.

The idea that no analysis and design is done in Agile is unrealistic.


Get an overview of a design phase in Agile.

Getting Started

Why does the Waterfall Process model not work?

What is Agile?

Short Iterations in Agile

Collaboration in Teams

Collaborating Roles

Agile Requirements

Estimating

Planning

Implementing Agile

Issues in Using Agile

Choosing the Most Appropriate Process Model

Conclusion

Design Phase in Agile

Big upfront design