Gerald Weinberg shares his observations of the agile movement "where it came from, where it is now, and where it's going" in the book Agile Impressions. In the book he explores the agile basics and principles, discusses how he has seen them being violated, and offers ideas and examples for applying the agile principles.
Agile Impressions is a "work in progress"; it is published on Leanpub, which allows the book to be written incrementally and automatically updated to all past purchasers. Jerry welcomes feedback on the book to evolve his impressions on agile.
InfoQ interviewed Weinberg about the importance of customer participation and involvement, collaboration between business and IT, communication and documentation. InfoQ also asked Weinberg for advice on people coming from university that want to become professional software developers and software developers who want to improve their skills.
InfoQ: Your book is a collection of blog post, articles, and discussions that you have had via email or on web fora. What made you decide to (re)publish this in book format?
Weinberg: Not everybody reads my blogs and articles. I wanted to reach a wider audience who are interested in Agile-related topics.
InfoQ: The manifesto for agile software development emphasizes customer collaboration and involvement. Can you share your view on this?
Weinberg: Just today a colleague sent me this relevant story:
We were finding it difficult to read data according to a new format specification. Turns out the specification was ambiguous in some places, and contradicted data produced, supposedly in accordance with it, in others. When the creator was asked what he would do about this, he said: “Nothing. I’m a programmer. I can do anything I want.”
Yes, programmers can do anything they want, but not if their jobs are providing useful products and services to other people. Unless you're a mind-reader, how else can you know what other people want? Personally, I don't know any mind-readers, though I've encountered many programmers like this one who believe they are. Agile's manifesto provides a cure for this kind of stupid arrogance.
InfoQ: In one of the articles you wrote about the importance of having customers participating. What if they say that they don't have time to do this, or won't be able to participate for another reason?
Weinberg: If you can't find an appropriate customer representative who will participate in your project, don't do the project. Apparently, the supposed customers don't feel they need it, so it's pre-doomed to be a failure.
InfoQ: Satisfying the needs of customers can be hard to do. Teams can feel pressured and promise things that they know they can't deliver. Do you have suggestions how this behavior can be recognized, and how you can deal with it?
Weinberg: We call this behavior "placating." There's a chapter in the book about placating, and how to avoid or prevent it. You start by recognizing that you are, indeed, placating. Any time you feel you "must do" or "must be" in regardless of how you feel or believe, you're in danger of placating. Ultimately, the secret of not placating is to be congruent, which means your outside behavior matches your inside feeling. For example, if you say, "I'll have that finished by tomorrow" because the boss insists on that, but you don't really feel you can finish by tomorrow, then you're incongruent, and placating. Better to say, "Naturally, if you want me to finish by tomorrow, I'll give it my best effort, but at the moment, I don't believe I can accomplish that." Your boss may not like that, but it's the truth. If your boss doesn't like the truth, that's now her problem.
InfoQ: You stated that "Business people and developers must work *well* together daily throughout the project". How can we find out that isn't going *well*? Can you elaborate how "working well together" can look?
Weinberg: There are so many ways of people working well together that it's easier to tell when they're not working well together. The most common symptom I see is what you asked about previously: does each party make themselves readily available to work on the other's issues? If not, they're not even working together, so they're clearly not working well together.
Do they know each other's names? They don't need to be best buddies, but they must treat each other with respect. When they're meeting together, do most questions get answered? The answers don't have to be what the questioner wanted to hear, but are their questions responded to, not ignored? Those are the signs I see most often that two parties are not working well together.
One other kind of sign is not seen by watching them work, but whether or not they will openly discuss how well they're working together. Complaining to outsiders (such as managers or consultants) is a clear indication that they're not working well together.
InfoQ: The Agile manifesto states that it prefers face to face communication. In the book you explained that this shouldn't be the only way to communicate. Can you give some examples of situations where other ways of communicating might be better suited?
Weinberg: Whenever there is an agreement about future behavior, even if it's made face-to-face, it should be followed up by an exchange of written documentation. Whenever dates or money are being discussed, the exact figures need to be detailed in writing. That's also true about requirements for a product—and especially for any changes in the requirements. Whenever precision is important, writing is infinitely superior to hand-gestures or vibrations in the air.
InfoQ: You mentioned in your book that from a maintenance point of view "at a minimum, each piece of code should have its “why” documented". Can you elaborate on this?
Weinberg: Too little Agile writing says much about product maintenance. If you've ever maintained someone else's code (and often your own, too), you realize how important it is to know why something was done, not just how it was done. For instance, you cannot safely remove what seems to be redundant or unnecessary code unless you know why it's there in the first place. Failure to document "why," is undoubtedly the main cause of code decay over time.
InfoQ: Looking back at the history of software development, can you mention some of the highlights and low lights of how the industry has developed over the years?
Weinberg: Sure!
Highlights:
- some really great people, like Grace Hopper and Harlan Mills, and hundreds whose names are not so well known
- the accessibility of inexpensive, easy to use computing power to almost everyone
- the growth of interest in quality, at least by many professionals
- the availability of tools and processes to guide and aid our pursuit of quality
Lowlights:
- spam
- the misuse of inexpensive computing power to convince people that lower quality software is "just the way computers are"
- the proliferation of hundreds or thousands of programming "languages" that really add nothing worthwhile to our industry
- the faddish pursuit of "magic bullets"
InfoQ: What do you expect that the future will bring us in software development?
Weinberg: As Woody Allen and others have said, "I can predict anything but the future." For instance, in 1956, I predicted that FORTRAN wouldn't last. Maybe it won't, but clearly it will outlast me. That should let you know that you don't want predictions from me.
InfoQ: Do you have some advice for people coming from university that want to become professional software developers? And for software developers who already have quite some experience, but want to improve their skills?
Weinberg: I may not be able to predict the future, but I can still remember the past. More than 30 years ago (1984) I published an article entitled "Forget the Facts Letter to my son, John, on the occasion of his graduation with a degree in computer science." I'm rather ashamed to say the letter was full of advice, but rather proud that John (now called Keats) actually followed some of it. Perhaps some of it actually helped him have his marvelous career as a programmer. If/when I find the letter to John Keats, and find it appropriate, I'll add it to the book and republish it so your readers may have a somewhat time-tested answer to your important question.
About the Book Author
Gerald Weinberg is author of more than 100 books, including the best-selling Secrets of Consulting, other non-fiction series, and the ever-popular Women of Power novels. He is a principal in the international consulting firm of Weinberg and Weinberg, among whose clients have been state and national governments; churches; universities; medical centers, and the US Library of Congress. The festschrift, The Gift of Time (Fiona Charles, ed.) honors his work for his 75th birthday. His websites may be found at http://www.geraldmweinberg.com and http://www.thewomenofpower.org.