By now, everyone has heard of Agile. But how did this movement begin? What motivated it? And what were software developers doing before Agile? In this episode we're going to walk down memory lane. We'll go back to the late nineteenth century to see the beginnings of the two major management philosophies that continue to influence us today. You'll witness the initial success of incrementalism in the early days of software. You'll see how the Agile mindset got an early foothold, only to lose it in the '70s. You'll watch as the forces of command and control asserted dominance over the whole industry. You'll hear the tales of woe and horror. You'll weep and moan with the victims And then you'll witness the resurgence of incrementalism in the '90s. We'll trace it all the way from the patterns movement to the Agile movement. And you'll see how, eventually, Agile became the undisputed victor. We'll conclude by describing that historic meeting in Snowbird in 2001; where 17 people forged the now famous Agile Manifesto.

This episode is all about planning a software project. Why do we plan? We plan so we can manage. What do we manage? We manage the deviations from the plan. As Eisenhower said, the plan is eventually useless -- the predicted results are not realized. And yet, having a plan, and predicting results is indispensable. It is this fascinating oxymoron of planning and execution that this episode describes and explains. And the solution to the oxymoron? Tom Demarco said it best: You can't control what you can't measure. -- Tom Demarco, Controlling Software Projects In this episode you will learn about measurement and control; and one of our first topics will be the Iron Cross of project management. The iron cross describes the "physical law" that constrains all management efforts. It also supplies the control knobs that managers use to drive the project to the best possible outcome. You will learn that proper management requires data; and that agile is all about producing that data. You will learn how short iterations, bad estimates, and rapid disappointing feedback conspire to help lead a project to a good outcome (if not the predicted outcome). You will learn that the aim of agile development is to destroy hope and provide a cold dose of reality to managers and developers -- because good management is impossible without facing reality. You will learn that iterations (sprints) cannot fail -- because the purpose of iterations is to supply data; not to finish stories. You will learn about Yesterday's weather, the notion that the best predictor of what the team can do is what the team has already done. And, most importantly, you will learn the immense self-discipline that is required, by all parties, when planning and executing a software project. And this is just part one. Wait till you see part two! That's where the rubber really meets the road. Oh, yeah, and in this episode we'll also solve the world's energy problems.

In this episode we are going to dive deeper, deeper, and deeper into the way agile teams plan projects and iterations. You'll see, in action, the project kickoff meeting. You'll watch as Priscilla, the product owner, reviews the user stories for the team. You'll be amazed at the skill and insight of Marty, the project manager, as he deftly guides the agenda. You'll hear Paula, the quality engineer, ensuring that stories are Independent, Negotiable, Valuable, Estimable, and Small. You'll be amazed as Ruby, Danny, and Jerry take the stories apart, estimate them, and negotiate schedule. You'll see it all. You'll see Iteration Zero. You'll see the estimation meeting, the backlog grooming meeting, and the iteration planning meeting. You'll see a standup, design, architecture, pairing. There's just no end to what you will see in this episode. We'll talk about velocity, and how to recognize and diagnose pathologies. We'll talk about scope management, and story points, and iteration length, and... Well... We'll talk about a lot. So, get ready for this one. Get ready for all the nitty gritty details of The Planning Game (Part 2).

The innermost grouping of practices within Ron Jeffries' Agile Circle of Life, are the programming practices. Test Driven Development Refactoring Simple Design Pair Programming We've already spent a lot of time, in previous episodes, talking about the first two of these practices; so in this episode we'll simply review them, and spend more of our time talking about how they fit into the overall Agile discipline. This is important because being an effective agile team depends, critically, on these practices. Being Agile, depends upon being simple. But being simple depends upon being clean. But being clean depends upon being free and able to do the cleaning. If you are afraid to clean, you won't clean, you can't be simple, and you will fail being agile. It's really as simple as that. So we'll talk about simplicity. We'll epand on Kent Beck's four qualities of simple design: Pass all tests Reveal Intent No Duplication Fewest Elements We'll also spend a bit of time talking about YAGNI: You Aren't Going to Need It. In the end, we'll make the point that being simple is very hard and requires a lot of work. Finally, we'll spend a bit of time talking about pair programming. We'll dispel the myths about this controversial practice, and show why any agile team must, out of sheer necessity, practice it properly.

Have you ever wondered what the Metaphor practice of Agile Development is? This is the episode where I'll tell you. We'll also talk about my deep dark past, my first job, my first car, my first donuts in that car, and -- well -- lots, lots more. This is the episode where we examine the middle circle of the Agile Circle of Life: The Team Practices: -Continuous Integration, -Sustainable Pace, -Collective Ownership, and -Metaphor. We'll also spend a bit of time talking about the role of the coach or (um) Scrum Master; and how that role has changed (degraded) over time.

How does agile go wrong? I know, I know, it's not supposed to go wrong is it? I mean, Agile is perfect right? Alas, nothing is perfect in this world; and that even included Agile. So what can go wrong with Agile Software Development? We'll talk about five things: 1: Flaccid Agile: Trying to do agile without technical disciplines. 2: The Invasion of the Project Managers: How Agile got co-opted by well meaning folks; and how that split the Agile community in two. 3: AgileFall: The ever present temptation to do waterfall and say you are doing Agile. 4: Agile Schmagile: The trap of thinking that Agile is nothing but a mindset. 5: Agile in the Large: What? That's a problem? Oh oh. So charge your phasers and raise your shields because this episode is all about how to do agile wrong.

Why do we do Agile development? What are the underlying motives? In this, the final episode of our series on Agile, we will discuss the reasonable expectations of our managers and users. For it is those expectations that are the true motivation for Agile Software Development. And what are those expectations? As you hear them, you'll find that you'll hear them with two different ears. The ear of the customers and users will hear something perfectly reasonable. The ear of the programmer will hear something insane and impossible. Or at least that's the way it will seem. It is Agile Software Development that resolves those issues and allows the reasonable expectations of users and managers to be reasonably achieved by programmers. So, listen carefully. Hear the reasonable expectations. Ignore the reaction of the programmer's mind. And learn how Agile practices make those expectations achievable.