The Lean Startup, by Eric Ries

I found The Lean Startup to be an easy and fun read. Taking on many of the same topics as the Poppendieck’s Implementing Lean Software Development but from more of a corporate or management perspective, Ries does an excellent job of describing exactly how one would go about setting up a new company with the ability to quickly innovate and become successful. The key is the Build-Measure-Learn feedback loop and reducing the time it takes a group to completely cycle through this process. Ries believes that you shouldn’t build anything without the ability to measure its success; in the agile software world this is very similar to well-defined acceptance criteria. Measuring is not only the normal quality metrics such as test coverage, but (and probably more important) customer acceptance. Having feedback from actual customers that your company is actually building the right thing is invaluable, and if you discover you aren’t going in the right direction, learn from this knowledge and pivot your behaviors.

The sections on choosing the proper metrics and tests to measure a product were by far the best part of the book. Ries calls traditional numbers used to judge products “vanity metrics:” total customers, gross revenue, and the like. Instead, metrics should be “actionable, accessible, and auditable.” Actionable means there must be a clear cause and effect for the data; if the numbers don’t reach a desired threshold it must be obvious what the next steps are. If web site hits suddenly increase, is it because of a better product or a PR campaign? If you can’t answer the question, you have a vanity metric rather than an actionable metric. Accessible means the reports are easily understood and provide a common frame of reference for everyone involved. Is a web site hit a successful login from a unique IP within a 24-hour period, or simply any request to the server? Auditable means the metric data is both black-and-white testable and easily available. If a test shows that a project should be killed, you don’t want the losers to challenge the veracity of the metric.

As with most agile processes, the ability to change is key. “As a movement, the Lean Startup must avoid doctrines and rigid ideology.” Other than the Lean doctrine itself, of course! The discussions here are quite broad; this is a book of ideas much more than a simple template to follow for success. That isn’t meant as a knock on the book, but that The Lean Startup should be only the first of many places a budding entrepreneur should begin a quest for success.

First Sentence:

Building a startup is an exercise in institution building; thus, it necessarily involves management.

Agile Testing, by Lisa Crispin and Janet Gregory

Agile isn’t about speed, it is about quality. While speed is obviously an attractive element of the methodology, if the resulting software is buggy then it doesn’t really matter how quickly it gets released. For many teams, especially young ones, how to work QA into a sprint cycle isn’t clear. This book is an excellent treatise into how testing and agile can work hand in hand.

Unlike waterfall processes, there usually isn’t a separate team responsible for testing in agile. That doesn’t mean that there isn’t a place for traditional QA personnel, though; in fact, a QA skill set is even more important because without a dedicated test team, developers end up doing more of the testing work. With dev executing test cases, the QA folks can apply themselves to exploratory testing, usability testing, and generally non-developer-think testing. The authors state “successful projects are a result of good people allowed to do good work;” this mix of skills and duties is what allows for both speed and quality to be maintained in a project.

What makes this book great, though, is that it covers not only roles and methods of agile testing, but metrics as well. Metrics are always an interesting topic in agile, because each self-organizing team will have different methods, making measurements difficult to standardize. The authors recognize this, and wisely warn against reading too much into the measures, too. “Having the number of unit tests go up every day is a nice bit of feedback... However, it is important to recognize that the number itself means nothing.” In this sense, the implication is that a large number of useless tests doesn’t add value, even if the metric is always increasing.

Easy to read, Gregory and Crispin have authored a very useful reference that should be on the shelf of every agile team.

First Sentence:

“Agile” is a buzzword that will probably fall out of use someday and make this book seem obsolete.

Implementing Lean Software Development, by Mary and Tom Poppendieck

This book examines the lean manufacturing approach pioneered by Toyota and how it can apply to software development. Lean boils down to seven principles: eliminate waste, build quality in, create knowledge, defer commitment, deliver fast, respect people, and optimize the whole. Many of these are familiar to agile proponents, but not all. Of particular interest to me was the last principle, optimize the whole. Developers have a strong tendency to suboptimize a problem, to “perfect” a small block of code without considering the bigger picture. Optimizing the whole means that instead of looking at an individual step you look at the entire value stream. When combined with a stop-the-line mentality that forces teams to solve problems rather than work around them, there is a lot of potential for not only higher throughput but for higher quality.

Another interesting idea presented here was set-based design: multiple teams solving the same problems at the same time in different ways. The thought here is you can have several groups all tackle the same issue, each taking a different approach or accepting a different amount of risk. They all work simultaneously, and at the end the best one of the solutions can be taken forward. I’ve never worked at a company that was willing to put this many resources towards a single problem but it is an intriguing concept.

Overall, a good book that any agile enthusiast should read. The writing isn’t as compelling as Tabeka or as interesting as Angus, but still well worth your time. Another winner from the Addison-Wesley Signature Series of books.

First Sentence:

Paris, France, July 1785.

User Stories Applied: For Agile Software Development, by Mike Cohn

Every agile team is different. Team dynamics and synergy are key to a truly self-directed team, so every unique group of individuals will have to discover what works for them and what doesn’t. One thing on which most teams (regardless of how different they appear or behave) will agree, though, is that writing software specifications is hard. English is a notoriously imprecise language, and computers are meticulous to a fault; this combination is what makes requirements so difficult. The use of user stories and agile to combat this hardship is very effective, and Cohn does an excellent job of explaining these concepts.

The main idea behind user stories lies in the idea that a story represents a requirement, it doesn’t document it. The goal of a story is to encourage communication about what a feature is and how it should behave, not a treatise on the behavior that can be thrown over a wall to development. In the traditional software world, management will create a Product Marketing Document to define how they want every last feature to behave. Engineering will respond with a Functional Specification, which is a rewrite of the first document with a slightly different point of view. Development is then expected to go off for a year or so and create the product. Simple, right? Cohn discusses this approach, and sums it up with one of my favorite passages in the book: “Most of the times when I see two groups writing separate versions of essentially the same document I already know they are positioning themselves for the end-of-project blame sessions and for claiming to know the intent of the document. This type of silliness goes away with user stories. Along with the shift to conversations from documentation comes the freedom of knowing that nothing is final.” The phrase “nothing is final” frightens many executives with whom I’ve worked, but when you consider that all significant projects undergo changes during development (have you ever had a released application that exactly matched the original specification?) it really isn’t any different than reality, it just recognizes that change is inevitable and accounts for it.

Even if you are familiar with agile and user stories, this book is a great read. It is filled with examples both positive and negative and does an excellent job explaining not only what user stories are, but what they aren’t as well. These negative explanations in particular are quite valuable, as they compare and contrast many popular requirement gathering techniques such as Use Cases and IEEE 830. Looking at how these other approaches work helps clarify what the scope of user stories are supposed to be. I highly recommend this to agile teams, especially product managers and ScrumMasters.

First Sentence:

Software requirements is a communication problem.

Collaboration Explained, by Jean Tabaka

Collaboration Explained is a great book that works on two levels: both a treatise on a topic and an ongoing reference after the initial study. While there is a lot of good information about popular agile methodologies and fostering collaboration, where it really shines is on the topics of meeting facilitation. My favorite anecdote told of a company that had sign above each meeting room door: “If you have not received a purpose and agenda for this meeting, please turn around and return to your desk.” I sure wish I could work at a place like that!

At the heart of the book is the idea that collaboration is powerful. Tabaka mentions many familiar names that believe in this credo of “People over process” but somehow omits Michael Coté who named his blog with this phrase! She points out that with all the differences in the various popular agile techniques, collaboration is the “daily glue that agile teams apply in order to accomplish their joint undertakings.” As someone that follows general agile techniques but doesn’t subscribe to any particular methodology this rings especially true.

One of the collaborative tools that Tabaka discusses is the “fist of five.” This is a way of quickly gathering a feel for where the group stands on a particular issue with more granularity than a simple pass/fail vote. The idea is that you ask for a showing of the fist of five (I call this the “fiery fist of death” because I like to inject humor wherever I can—and I can never remember the “proper” name!) when you want to get a feeling for where the group stands on a particular decision/solution. Everyone then simultaneously holds up a hand extending fingers indicating their position:

1. Five fingers: this is exactly what we should do and we are geniuses for thinking of it.
2. Four fingers: a solid plan that I’m happy to implement.
3. Three fingers: I can live with and support this decision.
4. Two fingers: I have a problem with where we are and we need to keep discussing.
5. One finger: use any finger you’d like to express your feelings.

Of course, Tabaka doesn’t express the fingers in quite this way but the end result is the same. This is a powerful technique that I’ve found quite useful, especially in groups that like to hear themselves talk. When I think that we are starting to cycle in our discussions calling for the fist goes a long way towards ending deliberation and moving the group forward.

As I said earlier, this is a great book not only for the discussions but as an ongoing resource. Section IV is particularly valuable, containing templates for many different types of meetings commonly encountered during agile development. Any team leader can learn a lot from reading this book, and individual contributors will benefit by getting a better insight into what makes a group truly collaborative.

First Sentence:

With the current interest in adaptive, more reliable software development practices, project teams and their managers are taking a renewed look at the many people aspects that either contribute to or detract from project success.

Agile and Iterative Development, by Craig Larman

This is one of those books that is useful as both an ongoing reference and as an introductory text. It provides not only a walk through of several iterative software development techniques, but targeted resources for further reading at the end of each chapter and a FAQ and bibliography at the close of the book. The topics are presented in a narrative fashion with many illustrative examples, making for both easy reading and high retention; knowing Larman’s history of developing and presenting training courses this is no surprise. Much like Rothman’s Manage It!, one of the great things about this book is that it delves into things needed for success outside the development methodology at hand; for instance, wikis and mind-maps get mentions here even though they aren’t specific to any particular technique. Larman also does a good job of discussing both the positives and negatives of various approaches, where many competing books tend to avoid the trouble areas and stick to the party line. This holistic view of the world is what makes this text rise above its brethren.

Another reason I enjoyed this book is my connection with the author: we used to work together a decade or so ago at ObjectSpace. In fact, I was one of the guys that interviewed Craig before he joined. At the time I was working in C++ and Craig had mentioned that he had a brief acquaintance with the language. He was being considered for creating and teaching OOAD and Smalltalk courses as I recall, but as an excuse for Craig to meet more people in the company we were asked to get together. Craig had flown in from Canada for a day of interviews and the word in the halls was all positive going into our session. After introductions I started in on the standard C++ language questions and we quickly discovered that he was exactly accurate with his self-evaluation of “vague familiarity.” As the session petered to an awkward close, Craig suddenly perked up and reached into his bag, pulling out a small bottle (think hotel liquor sized) of Canadian syrup saying, “I brought this for you!” Turns out he brought syrup for everyone, but the timing of remembering a gift at the end of a clumsy discussion was priceless. Of course he was hired and went on to great things, but that remains one of my favorite interview stories.

First Sentence:

What value will you get from studying this book, an introduction to iterative and agile methods?

Servant Leadership, by Robert K. Greenleaf

This book was written thirty years ago, but is still very relevant today. Not just in its message that true leadership is an inner quality as much as an exercise in power, but in the world that prompted the author to put pen to paper. “We are prone to adventurous and illegal wars. Confidence in the integrity of elected officials is at a low point. The total tax structure is a perversion. The treatment of prisoners is barbaric. The cost of it all is staggering.” Sound familiar?

Servant leadership embraces the idea that leaders should serve others by removing obstacles and staying focused on the organization’s values and integrity rather than any overt decisions. I find this idea appealing as it fits in well with agile software development techniques. An agile leader is responsible for having the big picture and for removing any roadblocks the team encounters, but not responsible for doing any of the work itself. This is very much the focus of the book.

While the themes were both interesting and valuable, the style was off-putting. I got the strong impression that the author was a bit of a hippie; not a hipster, but a tie-dyed hippie. I’m all for the zen aspects, but the anti-establishment ideas were often just silly. The nuttiest was the thought that we should reform our educational system by only teaching those that actually want to be taught. While it is a lovely idea that children will attend school without coercion and once there pursue a course of well-rounded instruction, anyone that believes this will lead to a scholarship intensive society is smoking something. Of course, hippies and smoking aren’t exactly enemies...

First Sentence:

Servant and leader—can these two roles be fused in one real person, in all levels of status or calling?

Manage It! Your Guide to Modern, Pragmatic Project Management, by Johanna Rothman

This book is best summed up on the cover: “There is no One True Way that works for all projects.” That message alone makes this one of the most valuable management texts I’ve read in a while. Most books in this genre detail a single approach to project management and claim superiority over all others. Rothman take a much more pragmatic approach (not too surprising as this is published under The Pragmatic Programmer banner) that is refreshing in its honesty. Instead of being told to drink the kool-aid for any one particular style, we are shown the buffet and told to take what we want.

There are many gems of wisdom here, several of which resonated with me. The variety of topics is wide, ranging from planning to completion, managing up as well as down, hardware projects (albeit briefly) as well as software, and managing multi-site projects and multi-project programs. The topic of testing has a good overview as well, from unit level at one end of the spectrum to system testing at the other. One interesting discussion describes the difference between QA and testing (and today’s reality that most QA groups are really testing groups): QA can and should reach into all aspects of a product—including the development process itself—and has the power to make changes to improve the quality of not just the product but the organization as a whole. I’ve met a few QA managers that fit this description, but by and large I realize my experience has been with mis-titled testers instead; I suspect this section will color my view towards this area of software development for the foreseeable future.

One piece of advice I liked was the recommendation for managers to develop multiple skills while on a project: interpersonal, functional, domain, and non-technical. Instead of simply getting to know the requirements and schedules, work with everyone involved to become a well-rounded manager in both knowledge and skill. Even if the project fails (and Rothman also advocates that knowing when it is time to leave a failing company or project is an important skill) your professional development still advances. Too often it is too easy for me to get caught up in the day-to-day demands of getting a project to completion; remembering to stop and smell the flowers and examine the big picture strikes me as an excellent idea.

This book covers a wealth of topics and yet is less than 350 pages; this means that many terms and approaches aren’t covered in great detail. They are all summarized, though, and a healthy bibliography is in the back so avenues of further research are easily discovered. If you are about to embark on your first management gig or if you are a grizzled veteran, this text should be on your bookshelf.

First Sentence:

The easiest way to start a project wrong is to just start.

Best Kept Secrets of Peer Code Review, by Jason Cohen

Code reviews are things that I believe are very important to a software development team. Not just because they can reduce defects before QA or the customer sees them, but because they help promote awareness of the codebase in general and provide critical mentoring opportunities to the team. The main message of this book is that the earlier you can find a bug the cheaper it is it fix, and code reviews are an underrated way of accomplishing this. While I agree this is true, I actually believe the mentoring aspects of reviews are actually more important—teach a man to fish and all that.

While loaded with interesting analysis, one detail rang a bit untrue to me. Cohen considers all items found in a review to be defects, but this is not always true in reality. For instance, asking that a comment be added doesn’t mean the code in question is unintelligible, but sometimes simply an explanation of why something was done (for instance, an API class is not marked final due to customer request). When mentoring, it is common to explain new techniques at review time as well; changing for(int i=0;i<longarray.length;++i) to for(long x: longarray) is not fixing or preventing a bug, but something that often happens as a result of a Java review. I believe this overly-broad interpretation inflates the numbers shown in the charts and tables a bit, but as it errs in favor of code reviews I find it easily excusable.

The author is the founder of Smart Bear Software, a company that not surprisingly has a product (Code Collaborator) that aims to ease the burden of doing code reviews. This certainly explains the focus on reducing the overall cost of bugs at the expense of mentoring—it is aimed at the people that control budgets, not the developers writing code. The self-published nature is also evident with something I expect an editor would have caught: the charts presented in landscape mode are turned on the wrong axis! He does reference Tufte, though, so I’ll assume there is some reason we have to spin the book counter-clockwise instead of clockwise.

All in all, this is a pretty interesting book. A lot of analysis and case studies went into it and a clear, convincing case in favor of code reviews is made. It skimps a bit on the mentoring aspects, but as those are probably much harder to quantify it is understandable. If you want to see a detailed look at why code reviews are good for a company, this should be your first stop.

First Sentence:

It was only supposed to take an hour.