Paula LópezPaula López 
September 3rd, 2020 What is Agile methodology?
In the 1990s, software development faced a bit of a crisis. Referred to as ‘the application development crisis’ or ‘application delivery lag’, the industry realized that it couldn’t move fast enough to meet customer demands and requirements.
The agile movement arises from the publication of the Agile Manifesto (declaration of the values and principles expressed in agile methodology) by industry leaders on February 2001. The software development projects were planned for a long time before writing a single line of code leading to unfortunate results.
Agile methodology is a type of project management process, mainly used for software development, where demands and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their customers.
In other words, it is an iterative software development process that requires a close feedback loop to quickly develop applications. Agile deviates from a document-based approach to a collaborative software development approach.
- The world before Agile and Scrum
The waterfall model was the main process for delivering a software product. It consists on upfront contiguous phases until the product is released.
It has some disadvantages (as well as every method has) like:
- A change in the requirements will have a huge impact in the other phases.
- The defects are not usually found until the test phase.
- Impossible to forecast the average of bugs that the product will have.
All these facts will result on delays for the Go Live date.
The main problems for all methods are: unclear requirements, unrealistic deadlines and inaccurate estimates.
That is why some thought leaders joined forces to create new iterative Agile methods of working (set of methodologies and frameworks) that share a manifesto and a set of principles. (Ex: Scrum, Crystal, Fdd, XP, DSDM)
- Birth of Scrum
Scrum is described by its founders as a framework for developing and sustaining complex products. It is not a process or a technique for building products.
It is used to implement the ideas behind agile software development. Created by Jeff Sutherland and Ken Schwaber (who were also part of the 17 individuals who cemented the Agile Manifesto), it’s comprised of five values: commitment, courage, focus, openness, and respect.
Its goal is to develop, deliver, and sustain complex products through collaboration, accountability, and iterative progress.
Scrum is a self-organizing cross functional team. Groups of people with different areas of expertise who work and make decisions together.
- WATERFALL vs. AGILE
Today, Agile is such a buzzword that even teams outside software development try to incorporate it into their workflow. But Agile is not for everyone.
Agile isn’t the right approach for every software project, either. If you don’t have access to customers, can’t iterate, or if you have a complex organizational structure, it’s very difficult to adhere to Agile principles.
It is more suited for small-to-medium size organizations than it is for corporations. The reason is simple: the fewer people there are, the easier it is to make a decision and respond to change.
Agile is also great for startups, where “fail fast” is the dominant mantra.
- SCRUM
Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
It makes clear the relative efficacy of your product management and work techniques so that you can continuously improve the product, the team, and the working environment.
Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk.
The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules. Each component within the framework serves a specific purpose and is essential to Scrum’s success and usage.
5.1 Scrum Team
- Product Owner
The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team.
The Product Owner is the unique person responsible for managing the Product Backlog.
For the Product Owner to succeed, the entire organization must respect his or her decisions.
- Development Team
The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint.
Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis.
Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint. Fewer than three Development Team members decrease interaction and results in smaller productivity gains and Having more than nine members requires too much coordination.
- Scrum Master
The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.
The Scrum Master is a servant-leader for the Scrum Team.
But how does the Scrum Master help?
5.2 Scrum Events
Prescribed events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum. All events are time-boxed events, such that every event has a maximum duration.
These events are specifically designed to enable critical transparency and inspection. Failure to include any of these events results in reduced transparency and is a lost opportunity to inspect and adapt.
- Sprint
The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created
Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.
During the Sprint no changes are made that would endanger the Sprint Goal and the cope may be clarified and re-negotiated.
Each Sprint may be considered a project with no more than a one-month horizon.
A Sprint would be cancelled if the Sprint Goal becomes obsolete and Only the Product Owner has the authority to cancel the Sprint.
- Sprint planning
Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint and it involves the whole Scrum Team.
Sprint planning answers the following:
What can be done this Sprint? – Forecast the functionality that will be developed during the Sprint, discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal.
The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog.
How will the chosen work get done? – the Development Team decides how it will build this functionality into a “Done” product Increment during the Sprint. The Product Backlog items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog.
- Daily Scrum
The Daily Scrum is a 15-minute time-boxed event for the Development Team and it ill be held every day of the Sprint.
The structure of the meeting is set by the Development Team and can be conducted in different ways if it focuses on progress toward the Sprint Goal.
Daily Scrums improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision-making.
- Sprint Review
A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. The Scrum Team and stakeholders collaborate about what was done in the Sprint.
The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint.
- Sprint Retrospective
Meeting held after the sprint review and in which The Scrum Master ensures that the meeting is positive and productive. Each team member will say what worked and what can be improved.
It is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.
- Scrum Artifacts
Scrum’s artifacts represent work or value to provide transparency and opportunities for inspection and adaptation.
- Product Backlog
The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.
Backlog helps to know what has not been done yet. It is important to continuously add detailed estimates by the product owner and Dev. Team.
Requirements never stop changing, so a Product Backlog is a living artifact. Changes in business requirements, market conditions, or technology may cause changes in the Product Backlog.
- Sprint Backlog
The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment.
The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint. Only the Development Team can change its Sprint Backlog during a Sprint.
- Increment
The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done.”
Scrum relies on transparency.
The Scrum Master must work with the Product Owner, Development Team, and other involved parties to understand if the artifacts are completely transparent.
Definition of “Done”
Members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of “Done” for the Scrum Team and is used to assess when work is complete on the product Increment.
