What is Agile?

I guess I should start from the start since not many people outside of the software profession are familiar with what Agile is.  In this post I'm going to give an overview and I'll delve more into ideas covered in following posts.

What is Agile?  
Agile is a working process for doing work as a team.  The methodology has been used primarily in creating software.  It promotes ownership of work as a team (versus hierarchical command and control), transparency of information across all roles, and collaboration.
It's hard to summarize Agile in one sentence but those are the core concepts.
There are a few "flavors" of Agile (slightly different ways of approaching the tenants noted above) but the most popular by far is Scrum.
It's the de facto method of well functioning software teams nowadays and books and blogs galore have been written about it.

I'll try to give a quick overview of Agile here in this post but it's going to be the "10 cent tour" version.  For more information, here's a link to Wikipedia about Agile Scrum but, of course, a quick Google search will provide you much more information.
http://en.wikipedia.org/wiki/Scrum_(software_development)

Let's start with the mechanics of Agile Scrum.  The "how" before addressing the "why".

Agile Scrum works off the fundamental concept of "Sprints" (I'm capitalizing Agile terms for emphasis).  Sprints are just a arbitrary length of time for the team to do work.  They are normally 2, 3, or 4 weeks in length.  The term Sprint is used to emphasize that work is not just one long continuous, seemingly unending "marathon" of work.  A Sprint has a pre-determined, finite amount of tasks that the team strives to complete by the end of the Sprint.

Each Sprint has five "ceremonies", or meetings, that the team conducts to make Agile Scrum work.

• Backlog Grooming
• Sprint Planning
• Stand Ups
• Demo
• Retrospective

Backlog Grooming
Each Agile team has a Product Backlog.  This is just a list of work prioritized by value provided.  Each piece of work is called a User Story.
The purpose of the Backlog Grooming ceremony is to give Story Points to the User Stories in the Product Backlog.  Story Points are a number that gives a rough estimate of effort.  They are not hours or any other unit of time.  They are just a relative size to other User Stories.  The most successful method I've experienced is to use Fibonacci numbers (1,2,3, 5, 8, 13, etc.).  I've also heard of using t-shirt sizes (S, M, L, XL, etc.).

Sprint Planning
This is done at the beginning of each Sprint.  Essentially, the team takes User Stories off of the Product Backlog, from the top (i.e. highest value) working down, until they have enough work to fill up the time in the Sprint for all team members.
At the beginning of the meeting, each team member's Capacity is determined which is the number of hours they have to put towards work in the Sprint (taking out time for time off, holidays, etc.)
As User Stories are pulled from the Product Backlog into the Sprint, they are tasked out.  Tasking is taking a User Story, which has no hours to it, and turning it into Tasks, which do have hours.  The User Story is the "what to do" and the Tasks are the "how are we going to do it".
As each User Story is broken into Tasks with hours, those hours are deduced from the entire team's Capacity. This means that the teams knows coming out of the meeting that they have neither over-committed nor under-committed.

Stands Ups
This is a short daily meeting whereby each team member states what Task/s they completed the previous day and what Tasks they are committing to completing the current day.  It helps ensure everyone stays on track and that if someone gets stalled on a Task that the team is able to identify this and help that person complete the Task.
Identification of when a team member gets stalled is also an important reason that no Task be longer than a work day but I'll get into that in a later post.

Demo
The Demo happens at the end of the sprint.  It's where the team demonstrates to all stakeholders, and really anyone interested, what they did that Sprint.  In business terms it's the businesses opportunity to see what business value the team produced.  For the team, it's the chance to "show off" and build pride in their hard work.

Retrospective
This also happens at the end of the sprint, usually after the Demo.  The entire teams gets together and discusses what went well and what went wrong with the Sprint.  Ideally, the team comes out of the meeting with some action steps to improve how their team functions.

Well, that's the mile high overview of Agile Scrum.  Notice at no point is their mention of software.  That's because, although Agile Scrum is most commonly used in software, it is really just a methodology for people to work to together to accomplish things.

I've experienced incredible value in my professional career from being in Agile Scrum teams and I'm a very strong believer in what it can do to make teams more productive, happier, and professionally fulfilled.  This is what sparked my thoughts about bringing Agile Scrum practices to my home life.  But that is a story for another blog post...