Agile 101: A Short Introduction to Agile Development Principles and Practices

If you’re not sure what agile is, you’ve come to the right place.

If you haven’t read the Agile Manifesto, now is a good time to do so.

What Is Agile?
Agile is when a small team of five to seven people works together on a ranked product backlog to deliver a finished, releaseable product.

In this picture, you can see that the company has ideas about what they want to produce. Those ideas get funneled to a responsible person. That person might the customer or product owner. That person creates a ranked product backlog that the cross-functional team takes.

The team, which has all the roles it requires, works off the backlog and creates features, producing shippable product on a regular basis.

Who’s on the Team?
The team must have some developers. It also has whomever else the team needs. That was vague, wasn’t it? I like a team with at least one tester on it, but I’ve certainly seen teams with no testers.

The team has all the roles the team needs.

If the developers are willing to test for each other, then the team doesn’t need any testers. Now, you and I both know that testing your own code is difficult (if not impossible) to do. When I’m in development mode, I can’t test my own code. I skip over the defects. I also manage to skip over many of my colleagues’ defects when I’m in developer mode.

Put me in test mode and I can find defects all day. So, teams can manage with official testers, and it’s difficult.

Does your team need a business analyst? Does it need a database administrator? Does it need a writer? It all depends on your product and how you work now.

If you’re using Scrum, you need a ScrumMaster on your team. If you’re new to agile, you might want a coach so you have help transitioning to a self-sufficient working agile team.

How Does the Team Produce Shippable Product?
I said the team produces shippable product often. But how do they do that? If you’re accustomed to a waterfall approach, where you spend weeks gathering requirements and more weeks doing architecture and design and specs, you might be wondering just how in the world a team could produce shippable product “often.”

When I say often, I mean days—as in, one or two. Yes, I like one-day stories; two-day stories, max. Some people think I’m crazy. I find one-week stories too large. They are too large for me in my business. They are too large for many of my clients. So I don’t recommend them. How do you move from work that takes six to eight weeks at a time to one-day stories?

You do it by asking, “What’s the first thing you do?” Then, change your thinking about how to implement a feature.

Remember, your customers don’t buy your frameworks or architecture. They buy features. In agile, we have a different way to think about requirements, called a user story. Here’s one way to define a user story:

“As a <specific user/role> I want <some feature> so that <some value or benefit>.” You also create acceptance criteria for this story.

Now, you might be thinking, “There’s not enough detail for me to write code or test based on this story template!”

You are correct. A story is enough information, so you have a conversation with a product owner.

You want to be able to fit everything on a three-by-five-inch index card. If it doesn’t fit on a card that size, it’s an epic, and you want to break down the story until it does fit on a card that size.

Then you want to implement by feature, as in this picture.

You can think about the architecture as you implement. You don’t define the architecture until you know enough about the features to define the architecture.

You only implement what you need to do right now. Do I find this frustrating sometimes? Sure I do. Do I ever think, “While I’m here, I may as well do this….” Of course. But if it’s not on the backlog, I don’t do it. Because the thing I’m considering doing is not the most important work right now.

How Does the Team Know It Is Done?
After the team has completed its work for the iteration, the team holds a demo. Think of “show and tell.” The best way to run a demo is for the customer or product owner to run the software. Yes, that can be scary, but if that person defined the requirements, that person should run the software. This keeps that person engaged and returning to the demos each iteration.

After the demo, the team conducts a retrospective, reflecting on how they worked since the last retrospective. What did they learn about working together? What went well? Where did they stumble? What do they want to keep? Where do they want to improve?

Do It Again!
Now, the team does it again. This is the iterative part.

Which Agile Approach Do I Use?
Agile is an encompassing term for any number of iterative and incremental approaches to creating products—iterative because the team revisits the product, and incremental because the team completes features as it works. Some examples are Extreme Programming (XP), Scrum, Crystal, dynamic systems development method (DSDM), kanban, and feature-driven development (FDD).

But agile is not just an approach. It is a system and a cultural change to your organization. Agile creates high visibility and transparency in the projects, which permeates the entire organization. Agile teams work together to make products. That fact challenges everything in the organization: the hierarchy, the titles, and the compensation system.