Agile is a powerful approach to creating, developing and releasing new ideas, all while continuously improving team output.

In other words: running successful and valuable projects that delight clients and team members.

In other words: sustainably and happily increasing profits.

When applied properly, agile provides a set of principles for maintaining our focus on top priorities, adjusting to new information and requirements, and learning from road-bumps, all while maintaining a happy productive team.

Sadly and without knowing, many teams are running less effective agile knock-offs. These teams suffer greatly, struggling to explain the gap between projections and performance.

Today we’ll start from the ground up, to make sure that our readers are equipped to build (or  rebuild) on solid foundations.

To start…

What is Agile?

• Agile is not a system, nor a framework, nor a set of routines.
• Agile is a philosophy, a way of thinking, a state of mind.

To start, let’s look at the...

Agile Manifesto

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• 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.

(source: https://agilemanifesto.org/)

That's it! Simple right? If you're feeling unsatisfied like there should be more to it, a quick trip to Wikipedia yields an expanded version:

• Tools and processes are important, but it is more important to have competent people working together effectively.
• Good documentation is useful in helping people to understand how the software is built and how to use it, but the main point of development is to create software, not documentation.
• A contract is important but is no substitute for working closely with customers to discover what they need.
• A project plan is important, but it must not be too rigid to accommodate changes in technology or the environment, stakeholders' priorities, and people's understanding of the problem and its solution

So how do we put this into action?

This is where the added specificity of the 12 Agile principles come into play.

Today, we'll focus only on #1:

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

How do we set up frameworks for continuous delivery? One of the more popular answers is to structure our work into sprints.

It's worth noting that while we have been discussing Agile philosophy, the sprinting practice outlined below is derived from Scrum, a popular software project management framework.

What are Sprints?

Sprints act as a forcing function for iterative growth. Work planned needs to be:

• realistic
• simple
• relatively well thought out
• well tested

...or you will suffer. And trust us, you will suffer.

Luckily, with the aid of a well planned retrospective, you can turn that suffering into growth, progress, and enjoyment.

(credit: most of what follows is curated from www.atlassian.com/agile/, on of our favorite agile blogs. It’s a blog that is overflowing with useful information, so we’ve done our best to curate relevant highlights below,  individual ref's by are provided section, when relevant)

Sprint Benefits

Credit: (https://www.atlassian.com/agile/scrum/sprints)

• to apply focus to bring ideas to life.
• deliver a tangible increment of work
• avoid working on too many items at once
• break down big, complex projects into bite-sized pieces

Sprint Definition

Credit: (https://www.atlassian.com/agile/scrum/sprints)

• A sprint is a short, time-boxed period when a scrum team works to complete a set amount of work.
• Sprints are at the very heart of scrum and agile methodologies, and getting sprints right will help your agile team ship better software with fewer headaches.
• scrum and agile are often thought to be the same thing. They’re not. Agile is a set of principles and scrum is a framework for getting s#it done.
• In depth / optional reading: The Scrum Guide

The Scrum Sprint Cycle and Rituals

Agile Planning Basics

Planning our work is critical to success. One of the nuances of agile planning is the acceptance that our plans will need to be updated as we navigate the project and uncover new unknowns.

For that reason we break the work into small, user-value based modules that can be more easily rearranged.

We call these modules...

Stories

Credit: (https://www.atlassian.com/agile/project-management/user-stories)

• A user story is an informal, general explanation of a [...] feature written from the perspective of the end user. Its purpose is to articulate how a [...] feature will provide value to the customer.
• a user story puts end users at the center of the conversation
• A user story is the smallest unit of work. It’s an end goal, not a feature, expressed from the software user’s perspective.
• “As a [persona], I [want to], [so that].”
• "users" don't have to be external end users in the traditional sense, they can also be internal customers or colleagues
• Make sure that you have clearly defined when a task is DONE.

Estimation

Credit: (https://www.atlassian.com/agile/project-management/estimation)

• Each team member brings a different perspective on the product and the work required to deliver a user story.
• Leaving part of the broader product team out of the estimation process creates lower quality estimates, lowers morale because key contributors don't feel included, and compromises the quality of the software.
• Each story is estimated, typically in points. You CAAAAN also use hours. For more on that, read here
• The biggest key point here is to track estimated vs. delivered so that we can learn to estimate more accurately, setting our teams up for success.

Planning Tips

Credit: (https://www.atlassian.com/agile/scrum/sprints)

• Make sure the team sets and understands the sprint goal and how success will be measured.
• Don’t pull in too many stories
• Budget time for QA and non-feature work
• Don’t take on a large amount of unknown or high-risk work. Break down stories that are large or have high uncertainty. A good rule here is: Stories estimated at more than 2 days (or ~25% of an individual's sprint capacity) should be broken down.
• If you hear concerns from the team, whether it’s about velocity (delivery of estimated work), low-certainty work, or work they think is bigger than what they estimated, don’t ignore it. Address the issue, and recalibrate when necessary.

Daily Check-ins

The typical format is:

• 15 minute time-box
• Yesterday I did: X
• Today I plan to do: Y
• I am blocked by: Z

(If stand-ups are at the end of the day and not in the morning, then it would be Today I did / Tomorrow I plan to do.)

Many people see these as a way to create accountability. We recommend that you see these simply as a guaranteed time to meet with your team.

Reviews

Credit: (https://www.atlassian.com/agile/scrum/sprint-reviews)

• A sprint review is about demonstrating the hard work of the entire team. Team members gather around a desk for informal demos and describe the work they’ve done for that iteration. It’s a time to ask questions, try new features, and give feedback.

Questions to ask in Reviews

• Are stories well-defined by the product owner, designer, and the engineering team before implementation?
• Does everyone understand and live the team’s engineering values and culture?
• Are there clear definitions and requirements around how work will be reviewed, testing, and released to encourage sustainable, agile development?
• After the team completes a story, are there many bugs that surface? In other words, does ‘done’ really mean ‘done?’

Retrospectives

Retros are one of the biggest pieces of the continuous learning cycle. There are many versions of the questions to be asked during a team (or individual) retro session, here are our current favorites:

• What has gone well?
• What could have gone better?
• What have we learned?
• What will we adjust?

Stay tuned as our next post will cover the approach to conducting meaningful retros that lead to compounding improvements in team performance and happiness.

‍