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.