Agile development originated as a set of principles and values applied to software development. Since coming on the scene in 2001 (see Agile Manifesto), the agile approach has been applied all sorts of organizations. I’ve even heard of one HR department going agile! Scrum is a framework that creates an agile environment. Let’s dig into both to see if agile and Scrum are for your team.

Agile

Agile acknowledges that requirements and situations change rapidly. Welcoming changes in requirements is one of the principles of agile. Here are a few more found in the Agile Manifesto:

-Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

-Business people and developers must work together daily throughout the project. Give them the environment and support they need and trust them to get the job done.

-The best architecture, requirements and designs emerge from self-organizing teams.

-At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Agile Manifesto Principles

As you can tell, the agile approach is different than the traditional phased approach of requirements-design-implementation-test-delivery. Being able to accept and adjust to change is a mindset that is very important to an agile leader and team member. The teams are empowered to make decisions, given guidance by the priorities of the business. And the team members are encouraged to continuously improve by regularly reflecting and suggesting improvements.

Scrum

Scrum is a framework in which you can implement agile concepts. It’s meant to be lightweight and easy to understand. But this does not mean it’s easy to implement well!

Scrum Terminology

Sprint: Work in Scrum happens in intervals called sprints. These are typical 2-4 weeks in duration. Every sprint contains the Scrum events described below.

Development Team: in the case of a software development Scrum team, you’ll have several developers, probably a tester, a Product Owner, and a ScrumMaster on the development team. Guidance varies on the number of people that is perfect for a Scrum team, but 6-ish is a common number.

Product Owner: This is the person who is responsible for the value the Scrum team provides. Many times, this person will provide the functional requirements, so the team knows what they are designing to. The product owner will typically examine the work the team completes and will determine if the work meets the acceptance criteria that was agreed on before work began. In larger organizations, the Product Owner (PO) may work with a product manager to translate business requirements to requirements the team can design and implement to.

ScrumMaster: A ScrumMaster is responsible for evangelizing and teaching the organization about Scrum, clears roadblocks for the Scrum team, and coaches the team to be self-organizing.

Scrum Events

There are a few prescribed events in Scrum. These are:

The daily scrum (aka daily standup). The development team convenes once a day, usually early. Each person takes a turn reviewing their progress since the last standup, what they plan on doing today, and any roadblocks or impediments that are slowing them down or preventing work. The standup is meant to be short – 10 to 15 minutes per day. By communicating daily, dependencies on other team members become apparent immediately and action can be taken or new plans made to accommodate. Other roadblocks and challenges can be addressed by the ScrumMaster.

Sprint planning takes place before the sprint starts. The team meets to determine what work they will be committing to for the upcoming sprint. The idea is to look at the prioritized backlog and commit to completing the highest priority tasks as the team’s capacity allows.

Once a sprint a retrospective is held. The team looks back on the last sprint and reflects on what went well and what didn’t go well.  The team chooses what they want to improve on for the next sprint or for future sprints.

At the completion of a sprint, a sprint review is held. This is a chance for stakeholders to see what progress has been made. The sprint review usually contains a demo of the working software produced in the sprint.

Pros and Cons

One giant pro of an agile approach like Scrum is that changes to the requirements or direction can be handled quickly. The teams keep a backlog of potential work, and the PO works to prioritize that backlog. As the team executes on their sprint plan, the backlog may be re-prioritized by the PO based on changing needs of the business or customer. In this way, when the next sprint planning event rolls around, the work that is now most important can get addressed. The organization is only a sprint away from redirecting the work of the team.

Another benefit I see in Scrum is that the events are on a regular cadence. The team always knows when to expect which events. I find that having a regular cadence lessens anxiety a bit.

A drawback of Scrum is that it thrives when teams stick together for a good length of time. If you have turnover on your Scrum teams, it’s difficult to take advantage of the reflection the teams do each sprint in the retrospective meetings. It’s also difficult for the team to be fully self-organizing, because when team members are new, they don’t know enough of the context to be fully empowered.

Very large projects can work with a Scrum approach, but usually work best if another framework is applied on top of the Scrum framework. There are several of these (google “scaling agile” if you’re interested). These frameworks take into consideration inter-team dependencies and coordinating the work of many teams.

tl;dr

Agile is a set of values and principles that is commonly applied to software development but is applied to other organizations as well. Scrum is a framework that provides an agile environment. Work in Scrum is broken down into sprints, which are 2-4 week intervals. Sprint planning, sprint retrospectives, daily standup meetings, and a sprint review are required events in the Scrum framework.

engineer your life

  • To learn more about Scrum, visit scrumalliance.org or scrum.org.
  • Read the Agile Manifesto and reflect on whether those values and principles could be beneficial to the work you do and the organization you’re a part of.