Johanna Rothman gives the rundown on what exactly is agile. Remember, 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.
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.
The summary of the article mentions: “Remember, agile is not just an approach. It is a system and a cultural change to your organization.“
There is a third aspect of Agile, agility. Agility as a mindset and way of solving problems also needs to permeate the organization, not just a different organization or hierarchy. That is, while concentrating on the process don't ignore the larger piece of agility (AGILITY), “being agile”, not just “doing agile” as proscribed by this or that group.
The reason this may be overlooked it is a lot harder to explain how to "be agile" and there are definitely large gains to be had by "doing agile", but then go much beyond that to true agility.
Since several of the ideas for agile were taken from manufacturing, I'll give a manufacturing example of teaching agility.
Give a worker new to a line or machine in imperfect process (on purpose) then ask them to improve it. The practice they get improving it will then allow them to continue improving it beyond where it was before it was intentionally downgraded (to teach this lesson in agility and improvement).
I realize this is more about a process and not a new product or use for a product, but one needs to start with simple lessons.
The kind of unleashing of creative minds that eventually results can then come up with new sources of revenue and game-changing innovations to existing software products.
An example from software development: There was a "traditional" software team--I'm sure they thought they were being agile--that was trying to integrate a HeartCentric ECG device with an electronic patient chart (EHR), so numbers would not have to be keyed in, but would just be saved there "automagically".
Our Team came into the picture after they had been working for months on their integration and we did it with four people in two months. When we finished, the other team still had not successfully concluded their integration.
Our next integration only took a month. (I believe it was Welch Allyn, but I'd have to see my notes as it was quite a while ago.)
Hope this gives you some idea of the two faces of agility: doing agile and being agile.
Richard, thank you for your comment. When I teach or consult, I do tell people about the mindset. I find they have either no frame of reference or an insufficient frame. So, we practice on projects, so they can see how a team can collaborate and discover their agile mindset.
Once they practice, they start developing the agile mindset. For me, it's a chicken-and-egg problem. You need the mindset to be agile. I find that people need practice doing agile before they can get the mindset.
An interesting problem!