Mindset & attitude [+]

Mindset & attitude [–]

Okay, so where's my agile development cookbook? Where's Agile for Dummies?

A cynical answer might be, "Agile isn't for dummies." A more direct answer is: Not here. This isn't a "how-to" section. Agile development isn't just another stepwise process you can overlay on top of yesterday's stepwise process. It's an approach to IT work that's a little different from the industry status quo. When people try to apply agile methods while maintaining a traditional frame of reference, they usually stumble. This section suggests some books to help you get into the right frame of mind.

Okay, so what's the "right" frame of mind? And make it short; I don't have all day. I've got a Death March to attend to.

In a nutshell, the agile frame of mind calls for us to be open to new ideas, fresh perspectives, and unfamiliar methods and tools. We need to be able to call on our experience and knowledge to help us solve problems, while not allowing that experience to constrain our thinking. That's what the book Zen Mind, Beginner's Mind is all about. Author Sunryu Suzuki was fond of saying, "In the beginner's mind there are many possibilities; in the expert's there are few." To be successful with agile development you need to have a beginner's mind.

But just having a beginner's mind isn't enough. You also need to have some idea of what to think about with that mind. What's important and what isn't? Many people say success in software development projects is largely a question of identifying and managing risk. Yet, conventional notions of risk assessment may not be all that great. After all, if the IT industry were delivering at a high success rate, we wouldn't be considering alternative approaches at all. We'd just keep on doing what's been working so well. Is there a more realistic way to think about risk? The authors of The Unbounded Mind thought so, and that's why their book is listed in this section.

Agile development is basically about doing whatever is most likely to work well in any given situation. Rather than defining a stepwise process to be followed by rote, agile methods are adaptive. One of the catch-phrases you often hear is "inspect and adapt." That doesn't only mean to adapt to changing requirements. It also means to adapt to nuances of organizational culture and structure, development methodology, ability of teams to apply particular agile development techniques, and other factors. Under such complex and variable conditions, is there a "method" you can use to determine what will or will not work? Well, there's nothing quite so mechanical as a "method" for that, but there are a couple of things that can help you cut through all the complexity without having to spend several lifetimes mastering many different professional disciplines.

One of those helpful things is summed up by the taoist concept of te, a word that may be translated crudely as "virtue." What it really means is that it's more effective to achieve goals by going along with the natural characteristics of things than it is to try and go against the grain and force things to happen according to some abstract plan that was concocted without reference to the natural characteristics of things. Well, I don't explain it very well. But Alan Watts does, in his book, Tao: The Watercourse Way.

Funny thing, that book ties in nicely with The Unbounded Mind, although I seriously doubt any of the authors had such a connection in mind. Chernobyl, Bhopal, and Three Mile Island aren't just place names, they're tags we associate with some very bad memories. In all three cases, there was plenty of warning that things were headed for disaster, but people didn't react to the warnings in the way "the process" dictated. Why not? Because planners didn't take into account the natural characteristics of things, and of people. They tried to force things and people to work according to their model, and they pretended it would actually happen that way.

All that philosophical stuff is fine, but how can we tell what the natural characteristics of things really are? How can we separate the important from the unimportant when we're dealing with highly complex systems like human organizations, markets, and information technology? Won't we get bogged down in the details if we don't have some sort of detailed cookbook process to follow?

Not necessarily. Our modern society tends to treat human beings as if they were perfectly rational beings who consciously analyze every problem in terms of language and/or mathematics before taking any action. In reality, we're wee, sleekit, cow'rin tim'rous beasties whose ancestors' brains evolved in an environment where they were not at the top of the food chain. They didn't have time to reason through every situation consciously: "Hmm, looks like that might be a sabre-toothed cat bearing down on me. Let me reason through my options carefully before taking action." We wouldn't be here today if they had functioned that way. They instantly and subconsciously parsed the input from their senses and homed in on the most important data. Then they trusted their gut. According to Malcolm Gladwell, our brains can still function that way, and what's more we can teach ourselves to do it. That's why his book, Blink is listed here. You can trust your gut, but first you have to train your gut to be trustworthy.

So, the trick is to be open minded, flexible, go with the flow, and trust your gut. That's it? Doesn't sound so hard. What's all the fuss about?

The fuss is about what you do, exactly, once you've trusted your gut and you're ready to go with the flow and all that jazz. You still have to be able to apply rigorous thinking to complex problems. With your subconscious mind trained to react appropriately to complex situations, you need your conscious mind trained to apply rigorous systems thinking to complex problems. (I said we weren't perfectly rational, not that we weren't rational at all.) Most people agree the classic work on that subject is Weinberg's An Introduction to General Systems Thinking. The book belongs here, in the "mindset" section, because it will help you develop a practical approach to rigorous thinking that fits very nicely with agile-style work. This agile stuff isn't just loosey-goosey fooling around, you know. There's real work to do! You need the appropriate intellectual tools to do that work (not just the methodological and software development tools).

Because of the emphasis on people over process in agile work, it's important that agile practitioners have strong critical thinking skills. Alec Fisher's book, Critical Thinking is an especially good choice in an area that is saturated with books, magazine articles, websites, and self-help materials. It's meant to help you develop general critical thinking skills that you can apply to any problem.

One of the most important things you're going to apply your systems thinking skills to is technical architecture. A random smattering of one-off applications, each one built in a completely unique way, isn't going to keep a company competitive. Using agile development methods, the brunt of this work falls directly on the development team rather than on a separate technical architecture team. That's why The Art of Systems Architecting is listed here. It's not a "how-to" book about systems architecture. It's about the fundamentals of systems architecture — paradigms, heuristics, models, frameworks, design progression, and how these apply to various classes of systems. That's good, because it helps you understand the underlying reasons why you would want to architect certain things in certain ways. That knowledge will help you avoid problems that might arise from applying published architectural templates by rote. Another way of saying it is that it will help you adopt an agile mentality about systems architecture while ensuring you have a sound basis for architectural and design decisions. Still want models and examples and reference architectures? Look in the section on architecture for references at that level of abstraction.

Hey, wait a minute. Why do I need to internalize all these fundamental concepts and think through the basics on my own? Haven't people already done all that thinking? Can't I just copy and paste their results? My brain hurts!

Sounds like you could do that, all right. Thing is, it's been tried before, and it's never really worked very well. Those who truly understand the fundamentals always seem to be able to achieve better results than those who try to copy what they think they see others doing, and apply it inappropriately in the wrong circumstances. And don't let anyone tell you that's "re-use." It isn't. It's just copying.

This is hardly a new question. Miyamoto Musashi recognized the same problem way back in 1634. A lot of people were calling themselves masters of the martial way of life and were running dojos, when in reality all they had mastered was a bit of sword technique. Well, okay, a substantial bit of sword technique. But that's beside the point. (Get it? Point? <sigh> Never mind.) Musashi believed a person had to understand the fundamentals of the martial way of life from bottom to top in order to be a true master. Toward the end of his life he wrote The Book of Five Rings to explain all this, and the modern English translation annotated by Hidy Ochiai is included here to help you grasp the reasons why it's advisable to learn fundamentals very thorougly instead of just mimicking things others have done at a superficial level. The title is A Way to Victory.

Organizational culture & management style [+]

Organizational culture & management style [–]

Whew! I thought we'd never get past all that philosophical stuff. Now show me some management "how-to" books and I'll start being agile right away!

Well, there's a bit more to cover before we get to the "how-to" level.

Why the delay? Isn't agile about rapid delivery? Rapidly deliver some book recommendations, already! I wanna get started!

No doubt you do. Thing is, management methods have to be compatible with management philosophy and organizational culture. Otherwise, projects won't flow in the way people expect. If you try to implement agile methods "to the max" in a traditional organization, it won't work because people will continue to think and behave in the old ways. If you try to implement traditional methods in an agile organization, it won't work because people will become frustrated and demotivated by the administrative overhead and lack of trust. You've got to sync up the management approach with the organizational culture. Then, maybe you can drive change incrementally over time. But to do that, you have to understand what's happening and why it happens the way it does.

Don't be silly. Different project management processes just amount to different ways of pumping the same old data into spreadsheets and Gantt charts. All that other junk is just academic, or a way for consultants to charge high fees to sling buzzwords around.

Hmm. I can see you've got some reading to do. Let's get to the books, then. The very first principle of agile development is that we value individuals and interactions more than processes and tools.

So what? What does that have to do with management?

It has to do with the way a manager interacts with teams and with others in the organization. It has to do with whether people work collaboratively, how much personal accountability they accept for the results of their work, whether they're trusted to exercise sound professional judgment without constant supervision, whether it's politically safe for them to make mistakes, take risks, and speak truth. It has to do with the way a manager tracks progress. Does he/she measure the delivery of results, or the completion of tasks? It has to do with whether managers take a Theory X or Theory Y approach to leadership. It has to do, too, with issues such as employee retention, productivity, software quality, and other matters that are indirectly affected by organizational culture and management style.

As far as agile management in particular is concerned, it requires a certain organizational culture and a certain management style to be successful. If your goal is to build an agile organization, you need to understand what that means so you can move your organization in the right direction. You won't get there just by snapping your fingers and saying, "agile-cadabra!"

So say you...but I've heard differently from agile proponents.

Their enthusiasm is understandable, but the reality is that it's hard to instill agile values in a traditional organization, and it's hard for traditionally-minded, trained, and experienced project managers to make the transition. They can't do it just by memorizing a list of new buzzwords while continuing to work in the same way as they always have done.

Nonsense! I can motivate my people by reminding them of the hardships of unemployment. I can make them collaborate by handcuffing them together. I can make them accountable by...

...blaming them for any problems or failures?

Now you're putting words in my mouth.

Of course I am. I'm writing both sides of the dialogue. More to the point, though, I'm putting words to attitudes exactly where they fit. And that's precisely the subject area the books in this section address. What sort of organizational culture is necessary for agile methods to work well? What sort of management style is appropriate for agile processes, for agile teams? Without understanding that, you can't really apply specific agile management processes like Scrum or specific agile development methodologies like XP with much chance of success. It isn't a matter of following a cookbook procedure.

Well, okay then. Lead on.

The people-over-process thing is key. Most of the rest of it falls into place once you've got a people-over-process culture. This idea wasn't created out of whole cloth by the authors of the Agile Manifesto. DeMarco & Lister's Peopleware predates the Snowbird meeting by at least a couple of years. Considered a classic, the book describes how management should treat valued employees to encourage high morale and self-motivation. Aren't such employees easier to manage? Why would a manager not want it to be so? The book isn't about agile management as such, but it describes a mindset about management that is prerequisite to success with agile methods. In fact, there's only one point in the book that I haven't seen as part and parcel of well-functioning agile teams: The idea that each employee has a private office with a window. Everything else in the book is as agile as it gets.

Have you heard of self-organizing, self-directing, or self-managing work teams? Do you know how to manage such teams effectively?

That's a trick question. It's axiomatic that self-managing is synonymous with unmanaged.

Wow. You really do have some reading to do! Fortunately, Kimball Fisher has some practical advice for you in his book, Leading Self-Directed Work Teams. The reason self-managed teams often turn out to be unmanaged teams is not that there's anything wrong with the concept. Problems occur when people aren't prepared to take responsibility for managing themselves. Maybe they don't quite understand what's expected of them. Maybe they just don't know the mechanics of it. Maybe they're working in a political environment that pays lip service to enablement, but when they act as enabled professionals they get slapped down. Read this one for some pointers on how to make the power of staff enablement work for you. Your job as a manager will be easier. Surely that sounds good to you!

Well, it sounds good, but I'm skeptical.

Good! That's another agile principle, you know: "Question everything."

Agile isn't the only buzzword that gets kicked around these days. SOA's another one. And there's BPM. Funny thing about BPM, most of the time consultants and BPM product vendors tend to take the approach that one can define some pristine, abstract process model and then expect us wee, sleekit, cow'rin, tim'rous beasties to follow it as if we were mindless machines. An exception is Harrison-Broninski's book, Human Interactions. It'll give you some insight into how rigorous business process management can be based on an objective analysis of the way people really interact in the workplace. That's a much firmer basis for defining and improving business processes than the usual. And it reflects an agile mindset about the topic, too, even if the author didn't think of it in those terms.

You talked about managers measuring completion of tasks instead of delivery of features. That's just the sort of nonsense you agile guys are always on about. It's two terms for the same thing.

Actually, there's a big difference. If all you're going to do is track tasks and elapsed time, you don't need a spreadsheet or a Gantt chart. All you need is a calendar. If 60% of the project schedule has elapsed, you're 60% done by definition. You already know you're going to do the first 90% of the project on time, and the next 90% on a Death March, anyway, just because that's the way it always happens. Time- or task-based status tells you nothing about the real progress of a project. But this is old news, you know. Fred Brooks wrote about it over 25 years ago, in The Mythical Man-Month. We, as an industry, have always known we were just making things up as we went along with those Gantt charts and stuff. We just didn't know of a better way to do things until relatively recently. Now we don't have to live that way anymore.

You're still making it all sound a bit simplistic, even without the "agile-cadabra" part. There are lots of reasons why people in an IT organization would resist changes like these. They don't necessarily have to do with a desire to deliver value to customers, either. They may have personal or professional reasons that aren't addressed by a straightforward value proposition.

Right. All too often, people resist change because they fear they have something to lose. They might actually fear losing their jobs. More often, they fear losing status or perceived knowledge or perceived importance, or some other thing that isn't materially connected with IT process improvement or agile methods. Sometimes, maybe, they just don't want to have to learn a new way of doing things. They're comfortable with what they already do, and they can get through the week without getting too stressed out.

The whole thing sort of comes apart at the seams right there, then, doesn't it?

Well, not really. It's a question of understanding what people's true motivators are. Everyone wants to gain something. Everyone fears losing something. In a traditional IT organization, I'd be surprised if anyone is really willing to say what those things are out loud, in front of others who would manipulate company politics to the speaker's disadvantage. Employees are going to try and frame their "concerns" in terms of what they believe management's objectives to be, or in terms that make them look good, personally. What you need is a way to see beyond the concerns people claim to have and to perceive their real desires and fears. That way you can find a lever that will move them.

Let me guess: You're going to suggest a book that explains exactly how to do that, right?

Not quite. I'm going to suggest a book that offers interesting food for thought about the not-so-obvious motivations people have for the things they do. Maybe it will help you cultivate a beginner's mind about the hidden motivations of people in your organization. The book is Freakonomics, by economist Steven Levitt. He asks questions like, If crack dealers make so much money, then why do they still live with their moms? It's like the question, If traditional software development methods consistently fail at a rate over 70%, then why do people defend them?

Process & methodology [+]

Process & methodology [–]

I'm pretty saturated with stuff about philosophy, mindset, culture, hidden motivations, and samurai. When are we gonna get around to some plain old "how-to" books?

Well, I suppose now is as good a time as any. Once you've got the appropriate mindset and you're working in a compatible organizational culture, you can apply specific agile project management processes without worrying too much about failures caused by anything outside your immediate control. And within that process, you can apply a specific agile development methodology in a disciplined way, without worrying too much that the team's culture or the organization's politics will interfere with progress. So, the next question must be, How do you go about applying one of these processes or methodologies? What do they consist of? How do they work?

Maybe the first thing to say is that there's no single "agile process" or "agile methodology." Agile is a general approach. Any number of different processes/methodologies might be elaborated that are consistent with the approach. Several are in widespread use today. And maybe the second thing to say is that even when you've chosen a process or methodology for a project, it's subject to adaptation depending on the realities of the environment, the people, the problem space, and the solution space. That's the thing about agile work; it's not rigid. That's why you need all that philosophical stuff as a foundation. Without it, you'd be surrounded by flexible methodologies that don't offer much in the way of guidance.

In fact, maybe a good place to start is with Dr. Alex Laufer's article on PM Forum, "Learning from Experience." It's not about software development at all; it's about the construction industry. But I think you'll find a lot of familiar things in it. I find it reflects an agile mentality about project management, even though it wasn't written with that in mind. And while you're on that page, continue reading through Hugh Woodward's piece, "The project was three years late, but an incredible success!" It highlights an agile principle: Keep the true goals in mind.

But that kind of stuff doesn't teach me how to apply any specific agile project management process.

True, but remember that a process is only a tool. The best hammer in the world can't build a cabinet without a knowledgeable carpenter to wield it.

Well, isn't that cute?

Shut up and start reading.

Software development [+]

Software development [–]

Hey, this is just general software development material. Where's the agile stuff?

We're talking about agile software development here, not just any old agile thing, like a ballerina or a faun. Basic software development principles are more fundamental than agile practices as such, so these books are listed first.

Two aspects of software engineering in particular are relevant to agile development these days. One is object-oriented programming and the other is design patterns. Armed with a sound knowledge of fundamentals in these areas, you can apply agile development practices like test-driven development and refactoring much more effectively than you could otherwise.

Okay, I guess that makes sense. But what's with that unix faq thing? It's not a book and, based on the title, it's not about software development in general. Besides, Amazon won't throw any pennies your way if we click on it.

True, but what Eric calls the "unix philosophy" amounts to a very practical list of lessons learned in the field in the course of many years of experience by a lot of different software developers. Practically everything he says is relevant to the agile approach to building software. Really, it's relevant to building good software regardless of your approach or methodology. And pennies from Amazon aren't my main motivation for writing this page. I just want to point you to useful references. Of course, I won't turn down a gift certificate if I get enough click-throughs, but that's just a nicety.

Fine, but what about YAGNI? Eric's Rule of Extensibility advises us to design for the future. That's not agile, is it? Ha! Gotcha.

"Design for the future" can mean different things, depending on how you look at it. YAGNI is a warning against over-engineering in the absence of any defined requirements. It doesn't mean that we should fail to consider future changes. We can design for the future by following widely-acknowledged standards and best practices (let's not argue about the word "best" just now), like design patterns, loose coupling, and so forth. That way, whatever may come up in the future will be manageable by whomever happens to pick up the code. In the old days, design for the future was interpreted to mean we should build code that never had to be modified, no matter how the requirements might change. I guess we all know how well that worked out.

Then I don't really need to buy all those other books. I can just read the website about unix philosophy, and I'll be all set.

Well, I wouldn't go quite that far. The Pragmatic Programmer has become a classic. It offers a great deal of very practical advice that will help you become a more effective software developer. Although it isn't explicitly about "agile" methods, it's considered required reading in the agile community. You won't go wrong by having a copy on your bookshelf. The other selections in this section give you important basic information about object-oriented software engineering and design patterns. These are really fundamental skills for success in agile development, since practically all business software development these days is based on object orientation.

Another good thing to do is to look for opportunities in your local area for hands-on practice with these skills. See if you can join a design patterns workshop or a coding dojo or a user group or SIG for programmers. Reading is all well and good, but there's no substitute for hands-on practice with knowledgeable people around to help you.

Agile practices [+]

Agile practices [–]

It's about time we got down to the nitty-gritty.

Yep. Here it is: The nitty-gritty. We're past the philosophical stuff. Now we get to the agile how-to books.

Wait! Before you start, let me just breathe deeply of the pragmatic air in this section. Ahhh!

Ready?

Ready!

Alright, then. The first agile practice to consider is planning.

You mean, agilists actually do that? I thought they just took things as they came.

Sure, agilists do planning. The differences between traditional and agile planning are about timing and scope. The traditional approach has us complete most or all planning up front. The agile approach has us doing just the right amount of planning (or what we believe to be the right amount, at the moment) at just the right times.

That sounds like nonsense.

Far from it. We think about planning in terms of multiple "horizons." We plan ahead as far as we can see, given the scope for which we need to plan. Hand in hand with that idea is that our short-term plans are more detailed than our long-term plans. The longest planning horizon corresponds with the organization's strategic business plan. That might go out, say, two to five years. It's probably not much more detailed than a mission statement. To realize the strategic plan, an organization will create a portfolio of IT projects to support business initiatives. The next planning horizon is at the project level. It specifies the goals of a project, but doesn't go into as much detail as a traditional project plan would do. A project of any significant size will have more than one release.

Let me guess: The next planning horizon is at the release level.

Right.

And the release plan is more detailed than the project plan.

Right again.

But a release plan is still less detailed than a traditional project plan, with its work breakdown structure and all that jazz.

I think you're catching on. Since agile methods are based on iterative development, the next shorter planning horizon is the iteration plan.

And that's where you finally get down to the WBS. Right?

Well, no. We never actually do that. We don't decompose the work into role-specific tasks. We break it down into stories.

Now you're losing me again.

Well, a story could be a user story, that describes some identifiable piece of functionality from the user's point of view, or a technical story, that describes some necessary under-the-covers bit of work. Some people use different terminology, but the concepts are the same.

Ah. So then you break the stories down into tasks and assign them to specialists, like DBAs and UI developers and network engineers. Right?

No, we don't break it down that way. Each story is "played" by a cross-disciplinary team that includes whatever specialists might be needed. But they work together to realize a story, slicing through the technical solution vertically and slicing across disciplinary boundaries horizontally.

So, how do you ever get down to details?

The last and shortest planning horizon: The day.

A single day is a timeframe for planning?

Can be. Can even be shorter. Depends on what's necessary for a given situation.

Sounds totally unworkable. A daily planning meeting would eat up all your time.

Not if the planning meeting were held standing up, and were limited to between 5 and 15 minutes' duration.

That's crazy talk!

Read first, judge later. Specifically, read Agile Estimating and Planning and User Stories Applied. Now let's turn our attention to agile design.

Agile what? I thought agilists let the design "emerge" from the code, or some such drivel.

Hmm. Well, it's true that the design emerges from the code, in a sense, but what you're suggesting is that agilists don't do any design at all. That's not really the case. We just try to do the right amount of design to get the job done, and to avoid treating interim design documents as if they were deliverables at the same level of importance as the working code.

One of the most significant aspects of agile development is the close collaboration between technical and business people. To achieve a high level of meaningful collaboration, you've got to have a common vision of the problem and solution, and a common vocabulary with which to discuss requirements, acceptance criteria, and design ideas. The seminal book here is Eric Evans' Domain-Driven Design. A great follow-up that offers a lot of sound, practical advice is Jimmy Nilsson's Applying Domain-Driven Design and Patterns.

Scott Ambler has been a leader in adapting object modeling practices to agile development methods. Unfortunately, his 2002 book Agile Modeling really wasn't too good, although the concepts were sound. The good news is he followed up with a better book in 2004. It's The Object Primer: Agile Model-Driven Development with UML 2.0. Not exactly a concise title, but a useful book.

I stand corrected. I didn't realize agilists were that disciplined — about anything. I thought they were basically cowboy programmers.

Far from it! Agile development is about as disciplined and rigorous as it gets. Anyway, the next agile practice to consider is pair programming.

Oh, here comes the agile dogma! And just when I was beginning to take it seriously. I've heard of that pair programming garbage. <gesture type="wave" mood="dismissive">It just doubles your labor cost</gesture>.

Actually, controlled studies have shown that it increases labor cost by about 15%. To balance that out, it adds value in other ways. Have a look at Pair Programming Illuminated to learn more about it.

I'd say most agile practitioners would agree that test-driven development (TDD) along with refactoring constitute the core development practices of agile methods. You can find thicker books than Testing Extreme Programming, but probably not better ones on the subject of testing on an agile project.

Lots of people are familiar with the TDD cycle: Red-green-refactor. They know "red" means a test fails, initially because there's no code behind it. They know "green" happens when the test passes, because you've written the code to make it pass. But they're a little hazy about just what to do in the "refactor" phase. You'll remember that I mentioned the importance of having a strong foundation in object-oriented software engineering principles and in design patterns. The reason is that those skills are the basis for effective refactoring. Without them, you won't really understand what to change, why to change it, or how to change it when you get to the refactoring phase of the TDD cycle.

Martin Fowler's book, Refactoring: Improving the Design of Existing Code is the foundational reference on the subject. It elaborates most of the basic refactorings that come up time and time again in software development. A great follow-up on Fowler's thinking is Joshua Kerievsky's book, Refactoring to Patterns. It ties together object-oriented design principles, design patterns, and refactoring and presents more complex, multi-step refactorings that address many common problems that normally arise as a codebase is extended and refined. I recommend these two book very highly, and I urge you to work through all the examples and look for instances of the same situations in the code you see on the job.

Well, that all sounds great, but isn't it a lot of extra work? Seems like adding extra work to a project would only increase costs.

"Extra" work that increases costs? This, from a person who creates work breakdown structures and Gantt charts? Look, it isn't just "extra" work, it's work that results in fewer defects. Fewer defects means the team can concentrate on building value-add features throughout the project, instead of having to turn their attention to bug fixes for the latter iterations of a project. It also means the delivered code is cleaner, and more likely to stand the test of time in production as enhancements and fixes are made.

I might be able to buy into that, if some of the routine stuff could be automated.

What a great segue! It's almost as if I wrote it myself.

<gesture type="eyeroll" mood="ironic">Go figure</gesture>.

Yes, a lot of the routine parts of this work can be automated. Code inspection to assure standards compliance, builds that execute the full test suite, and automated notification of developers when things go wrong. Unfortunately, there aren't many good books out on the subject. That's why I'm going to stick my neck out and recommend a book that isn't available yet. It's Continuous Integration, by Paul Duvall and others. Continuous integration is a fundamental agile practice, but to date there hasn't been a really good reference book on the subject. This one promises to be useful, if the authors' backgrounds and the quality of the series so far are any guide.

I think I'll hold onto my money until I see some reviews.

Fair enough. But let's keep it on the list so we won't overlook the topic altogether.

Okay. But where are the books about all those other agile practices? Dedicated team, team collocation, and all that stuff?

Do you actually need to read an entire book that explains why people who sit together can communicate more easily than people who sit separately? Or why people can concentrate on their work better if they're not distracted with multiple assignments concurrently? How much could one say about those things?

How would I know? I'm new to all this agile stuff. Besides, aren't you trying to peddle books for Amazon here? How can you say, "Don't read a book" when you're peddling books? Are you crazy, or just stupid?

You know, I wouldn't sit still for such abuse if I weren't writing all the lines.

Oh, that's clever. I'm sure everyone is amused. Look, I don't see how all these agile practices hang together in any coherent way. What's a day in the life like?

Well, there's a pretty good blog post about that. It's called "A Day in the Life," and it's by Noel Llopis, who leads a team of developers at High Moon Studios.

But that's a video game company! I work in a corporate IT shop.

We're talking about an approach to software development. It doesn't matter what the software does.

Well, maybe. How about a book recommendation? I can't put Noel's blog on my shelf for reference.

Okay. Here's one: Extreme Programming Adventures in C#.

But we don't use C# in our shop!

You don't use Unix, either. And you don't write games. So what? We're talking about a development methodology here. This book walks you through lots of days in the life of an agile development team. You can get a sense of how it feels, what kinds of things typically happen, and how an agile team deals with it all. You don't have to do the coding exercises.