Core Principles

As mentioned in the overview, Agile is a philosophy or approach to software development that consists of a collection of principles.  Scrum is one of several frameworks based on the Agile approach.

While many frameworks promote and adhere to Agile principles, Scrum is arguably the most commonly used in industry.

Why Agile? Why Scrum?

Agile may be viewed as a reaction to the traditional “waterfall” approach of software development—an approach that seems logical, intuitive, and responsible, but has proven to frustrate and fail.

“Logical, Intuitive, Responsible” Approaches That End in Failure:

  • Plan carefully and with great detail to avoid an oversight
  • Plan as far into the future as you can
  • Set deadlines for your detailed requirements, and “inspire” (i.e., “push”) your team to meet them

Waterfall approaches to development fail for all the reasons that Agile approaches (can) succeed.  They are essentially the…

Agile principles in reverse:

  1. Processes & Tools Over Individuals & Interactions
  2. Comprehensive Documentation Over Working Software
  3. Contract Negotiation Over Customer Collaboration
  4. Following a Plan Over Responding to Change

As you’ll see in the next section Agile & Scrum: a brief history,  Agile addressed many of the issues developers faced in firms employing a traditional waterfall approach to development—an approach that has brought with it development failures of shocking proportions, while Agile approaches have famously reversed some of the worst of these failures.  Scrum provides a clear framework on which to apply Agile principles.

The “core principles” below illustrate the overlap in Agile & Scrum founding literature and provide general themes a development team can return to for clarity:

Agile/Scrum “Core Principles”

Empower Your Team

  • Self-organization—workers are self-organized and share ownership; and therefore more innovative (SP2)
  • Individuals and Interactions Over Processes and Tools (AV1)
  • Supported, trusted people are more motivated, remain loyal, and deliver better quality (AP5)
  • Self-organizing teams with decision-making power, team members take ownership, team members communicate regularly and share ideas (AP11)

Encourage Collaboration & Visualize Communication

  • Collaboration—(awareness, articulation, and appropriation)—a shared value-creation process (SP3)
  • Customer Collaboration Over Contract Negotiation (AV3)
  • Regular, iterative collaboration between stakeholders and developers (AP4)
  • Opt for face-to-face (vs remote) interactions whenever possible (AP6)
  • Be Visual – disseminate information in visual formats that are easy to see, interpret, and understand at-a-glance. Use Post-it notes on large planning walls to develop and prioritize user stories and then input those into a project management tool.  Or plan directly in the tool. (APro5)

Additional Notes:

Communicate more, but less each time – meet in person briefly (nearly) every day

Prioritize Aggressively & Timebox Everything

  • Value-based Prioritization—deliver maximum business value early and throughout the project (SP4)
  • Time-boxing—time is a limiting constraint, used to manage planning and execution (SP5)
  • Measure progress in terms of functional software delivered to the customer (AP7)
  • Simplicity-keep the product simple- just enough to get the job done; do not overdevelop (avoid software bloat) (AP10)
  • Time Box all processes from the start and give meetings defined agendas & lengths (APro2)
  • Prioritize Minimum Marketable Features (MMFs), which on their own would constitute a completely usable piece of software (APro3)
  • Measurable – break down features into “user stories.” then estimate their complexity and measure the project velocity, for more precise forecasting of resource requirements and timelines going forward (APro6)
  • Empirical Process Control—(transparency, inspection, and adaptation): decisions are made based on observation and experimentation rather than on detailed upfront planning (SP1)
  • Use time intervals (“sprints”) instead of deadlines
  • If a deadline is a non-negotiable, simplify your requirements as it approaches to optimize success
  • Don’t over-build or over-plan

Iterate Often, Welcome Feedback, & Expect Changes

  • Iterative Development—manage changes and build products that satisfy customer needs. delineates the Product Owner’s and organization’s responsibilities related to iterative development (SP6)
  • Responding to Change Over Following a Plan (AV4)
  • Expect requirements to change during the development process (AP2)
  • Emphasize technical design enough to maintain and improve the product as it adapts to the market and adds new features (AP9)
  • Team members reflect regularly on how to become more effective (AP12)
  • Iterate Incrementally, starting with highest value, then with feedback on what to keep, add, change & remove (APro1)
  • Continuous User Feedback – require continuous verbal collaboration between all team roles and feedback from stakeholders and document properly in collaboration tools (APro4)
  • Be Open To Change—Expect and be open to change throughout development. Changes can be addressed only in the next development cycle (sprint) (APro4)

Additional Notes:

Have big goals but build-sized plans

Fail quickly, on a small scale

Expect your vision to change with time and feedback, and accelerate this as much as you can

Make the smallest meaningful increments – complete the smallest amount of progress that will allow you to re-assess and decide whether you’re on the right track

Test as you go; not at the endGet frequent, honest feedback from your team … and act on it 

Get frequent, honest feedback from your stakeholders, and act on it

Release Continuously, Sustainably & In Usable Chunks

  • Continuous software delivery to keep customers engaged and positive, with less chance of dissatisfaction (AP1)
  • Working Software Over Comprehensive Documentation (AV2)
  • Deliver working software regularly (vs all at once at the end with no input from stakeholders or users, or components that have technical value but no stand-alone functionality for the end user) (AP3)
  • Build at a speed that is repeatable and maintainable, ideally delivering working software with each iteration (AP8)

Main principles of Scrum

As published by Scrum Study:

  • Empirical Process Control—This principle emphasizes the core philosophy of Scrum based on the three main ideas of transparency, inspection, and adaptation.
  • Self-organization—This principle focuses on today’s workers, who deliver significantly greater value when self-organized and this results in better team buy-in and shared ownership; and an innovative and creative environment which is more conducive for growth.
  • Collaboration—This principle focuses on the three core dimensions related to collaborative work: awareness, articulation, and appropriation. It also advocates project management as a shared value-creation process with teams working and interacting together to deliver the greatest value.
  • Value-based Prioritization—This principle highlights the focus of Scrum to deliver maximum business value, from early in the project and continuing throughout.
  • Time-boxing—This principle describes how time is considered a limiting constraint in Scrum, and used to help effectively manage project planning and execution. Time-boxed elements in Scrum include Sprints, Daily Standup Meetings, Sprint Planning Meetings, and Sprint Review Meetings.
  • Iterative Development—This principle defines iterative development and emphasizes how to better manage changes and build products that satisfy customer needs. It also delineates the Product Owner’s and organization’s responsibilities related to iterative development.

The 4 Agile Values

As published by Agile Alliance

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

The 12 Agile Principles

As published by AgileAlliance

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity–the art of maximizing the amount of work not done–is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Next Sub-Section: A Brief History »