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.