Scrum Introduction

  • Because of their extreme uncertainties, it is not always possible to gather all the projects requirements upfront.
  • A project management method is needed flexible enough to deal with many change requests that appear during the project and keep the project team productive.
  • There are a number of systems designed to provide these two properties and one of them are called Agile Frameworks and include Scrum, Kanban, FDD and XP.

Agile Manifesto

In 2001, while on a skiing vacation, a group of software developers published a manifesto that has since been considered the heart of all Agile methods.
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  1. Individuals and interactions Over processes and tools
  2. Working software Over comprehensive documentation
  3. Customer collaboration Over contract negotiation
  4. 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.

Scrum vs Waterfall

Both Scrum vs and waterfall methodologies have their strengths, so it all depends on the type of project and its environment. Both approaches have effective planning followed by execution, monitoring and controlling.
In a nutshell:

  1. It is better to use Scrum if there are lots of unknowns, where the projects are more complex, difficult to define detailed requirements upfront and therefore to define estimates at the beginning of the project.
  2. It is better to use the traditional approaches when there are few unknowns, project is less complex, easy to define exact requirements upfront and therefore easy to estimate and plan the project from the very beginning.

Scrum Scope, Requirements, Activities, Estimation, Process, Measure of success and Results definition:

  1. Scope is not clearly defined and Product will gradually appear during the project
  2. Requirements change frequently and customer learns more about what they want as the project goes on
  3. Activities cannot be well defined upfront
  4. Estimating and planning is difficult
  5. Process is iterative with numerous cycles and each cycle depends on the previous one
  6. Success is mostly measured by customer satisfaction
  7. Incremental results have value and can be used by users

Waterfall Scope, Requirements, Activities, Estimation, Process, Measure of success and Results definition:

  1. Scope is clearly defined upfront with clear product description available upfront and similar projects were done before
  2. Requirements are well defined up front with few change requirements expected during the project
  3. Activities can be well defined upfront
  4. Estimating is possible and reliable
  5. Process is more long term and Project might be split into phases
  6. Success is mostly measured by achieving the project goals ( time, cost, scope…)
  7. Users cannot start using the products until the project is complete

Fictions about Scrum

Some of the most popular myths about Scrum include :

  1. Developers are free to do what they want. Fact: developers work in a productive and predefined framework and the Scrum Master makes sure they are following Scrum.
  2. Scrum gets rid of all paper work and allows the team to start developing right away. There are certain planning steps involved in every Scrum project and development can only start when the Sprint Backlog has been defined.
  3. All requirements in the form of stories must be agreed before the Development Team is allowed to start working on the product.  The Development Team can start working as soon as the initial stories of the Product Backlog are ready.
  4. Scrum is very easy to implement even without training. Fact: In order to run their projects well, everyone involved should have a good understanding of Scrum to be able to
  5. Scrum is just a set of simple rules. Fact: Scrum is a set of rules and a framework, plus a compatible work culture and ethic
  6. Scrum does not require you to have a Business Case. Fact: The Product Owner is responsible for ensuring that there is a feasible reason for performing the project and each of the stories should be aligned with that
  7. Scrum allows the Development Team to decide what will be delivered. Fact: A Team only decides on how to deliver; it is up to the Product Owner to determine what will be delivered
  8. Scrum Master is like a project manager. Fact: There is no one similar to a traditional project manager in a Scrum project as the Scrum Master makes sure the Scrum framework is followed
  9. The Product Owner is the project manager. Fact: The Product Owner only creates and maintains the Product Backlog, but does not manage the day to day activities of the Team
  10. The Product Owner is a representative from the customer. Fact: The Product Owner is one of the people from the performing organization and the contact point with the customer.
  11. Scrum tells us everything about managing projects. Fact: Scrum mostly deals with the definition and delivery of the products. Many of the business oriented aspects of the project are done outside Scrum.