The Basics of Agile as a Project Management Methodology

Oct 20th, 2021 | Jessica Jensen

Agile project management is not new in the software development scene. Everyone has heard of it, you simply can’t escape the buzzwords in this day and age – going agile, having lean development, running scrum – but what does it mean?

What is Agile Software Development?

Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. Agile methods promote:

  • Frequent inspection and adaptation
  • A leadership philosophy that encourages teamwork
  • Self-organization and accountability
  • Rapid delivery of high-quality software
  • Aligning development with customer needs and company goals

Benefits of Agile Working?

Because of its flexibility, Agile is one of the most popular approaches to project management. It was created for software development and began in 2001 with the Agile manifesto. Working in an agile manner focuses on removing any roadblocks to reaching goals. Several organizations have implemented flexible working in the last couple of years, and agile working is at the heart of this transformation. The core benefits of agile working are:

  • Improved quality of working relationships
  • Increased productivity
  • Reduced costs
  • Talent acquisition & retention

What is Scrum?

Scrum is an agile project management framework that describes a set of meetings, tools, and roles that work in concert to help teams structure and manage their work. The name came from the game of rugby to stress the importance of teams in complex product development. A key principle of Scrum is the dual recognition that customers will change their minds about what they want or need and that there will be unpredictable challenges—for which a predictive or planned approach is not suited, and instead focuses on how to maximize the team’s ability to deliver quickly, to respond to emerging requirements, and to adapt to evolving technologies and changes in market conditions.

Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal. The idea is that the development team will be:

  • Self-Organizing
  • Cross-Functional
  • Accountable
  • Small with 3-9 team members

Within a Scrum team, there are 3 roles:

  1. Product Owner – Creates executable product vision; prioritizes backlog
  2. Scrum Master – Runs daily standups; helps remove impediments (aka blockers); helps establish scrum principles
  3. Developers – Anyone working on the sprint increment

And within the sprint itself, there are 6 “ceremonies” or “events”

  1. Sprint planning – Where the work to be performed in the Sprint is planned. Ran by the Scrum Master.
  2. Sprint – A short, consistent cycle no longer than 4 weeks. The goal is to have an iteration short enough to keep the team focused but long enough to deliver a meaningful increment of work. All Scrum Events take place during a Sprint. Once a Sprint is finished, the next begins.
  3. Daily scrum (or standup) – Lasts no more than fifteen minutes and happens every day at the same time. Everyone on the team attends. Each person says what they did since the last standup, what they’re going to do next, and if they have any impediments (aka blockers) blocking them from finishing their task.
  4. Sprint review (or demo) – Held at the end of the Sprint to allow customers and stakeholders to inspect the Increment, give feedback, and for the Scrum Team to adapt the Product Backlog if needed.
  5. Sprint retrospective – An opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. This event occurs after the Sprint Review and prior to the next Sprint Planning.
  6. Backlog Refinement (or Grooming) – An activity for the whole team led by the Product Owner. The on-going process of adding detail, estimates, and order to the items in the Product Backlog.

And finally, there are 3 artifacts:

  1. Product Backlog – A priority ordered list of everything that is known to be needed in the product, owned by the Product Owner.
  2. Sprint Backlog – The set of Product Backlog Items selected for the Sprint, plus a plan for delivering the Increment and realizing the Sprint Goal.
  3. Product Increment – Items completed during a Sprint. Each Increment should stand alone as a distinct addition of value to the Product. An Increment represents a concrete step towards realizing the Product Goal.

The people, the ceremonies, and the artifacts work in concert to keep a project moving in bite-sized increments towards the project goal. Because the work is broken down into sprints, it also allows the team to pivot should priorities and objectives change.

What works well with agile is that it is flexible and provides a way to quickly get to your minimum viable product* and to fail or succeed quickly with rapid iterations. This will save you time, money, and resources – the first to market is often the “winner” and if you can get your name out there quickly while still iterating on the product, you can determine if the product is worth continued investment. The sprint process also promotes lots of communication, collaboration, and transparency between the development team and the stakeholders which builds trust and eliminates barriers.

However, it is rare to see a company running “pure agile”. Most companies end up with a hybrid model between agile and waterfall – senior leadership may not embrace all the principles of Scrum, and it takes time for broader organizational change. People outside of the sprint team may not understand the process and while folks within the team should push for change where it makes sense, they also need to adapt to the larger culture’s needs in order to ease everyone in. For example, a Senior VP may decide that there is an urgent need and doesn’t care that the team is in the middle of a sprint. The team usually adapts by taking less urgent stories out of the sprint to accommodate the Senior VP’s request – it is obviously not a great career move to say, “Sorry boss, we’ll help you in a few weeks after this sprint is completed.”

Agile is here to stay, and understanding the process and principles will help you in transitioning your teams to come on board. It usually works best if everyone on the scrum team has been through scrum training, so if you are considering moving to scrum, you should identify the core team members and begin training them for their roles. We can help you begin your agile transformation journey. Connect with us!

What are the top reasons to go agile, and what factors should leaders think about when considering the transformation, in your opinion? Please share your thoughts in the comments section below.

*Minimum Viable Product (MVP):

Just enough features to be usable by early customers who can then provide feedback for future product development. A focus on MVP development potentially avoids lengthy and unnecessary work.