Notes from a Tool User

Best Agile Books 2007 Development/Code Related

The third and final my Best Agile Books the 2007 Edition series. (Part II was Background Material). There will be even fewer notes than there were in yesterday's. It really has been a long week.

Development/Code Related 

Working Effectively with Legacy Code by Michael Feathers - Do you have legacy code? Does your code include areas that are untested and tightly coupled? Yes? Then you have legacy code. Michael focuses on the problem of teasing apart legacy

Refactoring: Improving the Design of Existing Code by Martin Fowler et al - One of the original Agile related books. It defines the concept of refactoring (personal bugbear - refactorings are small changes that don't affect the behavior of the code), explains how to practice it and catalogs over 70 refactorings. 

Test Driven Development by Kent Beck - The original TDD book. Clean, bug free, simple code. That is the promise of TDD. Its that simple nothing more to say. BTW the examples are in C# so some of the details won't apply to Java/Ruby/Python coders.

Late Breaking news: J.B. Rainsberger introduced me to: Test Driven: TDD and Acceptance TDD for Java Developers by Lasse Koskela. I'm only about 120 pages in, but so far am very impressed. Its even caused me to change a few of my habits - specifically which test I choose to write first.

Another Late Breaking item - Robin Dymond gave this one a very strong recommendation: xUnit Test Patterns: Refactoring Test Code by Gerard Meszaros. I've not read this yet - but Gerard covers Test Smells and Refactoring. In other words how to spot trouble your test code and repair the damage.

Refactoring to Patterns by Joshua Kerievsky. Have mess, want to bring some order to it.

Head First Design Patterns by Elisabeth Freeman (et al). I struggled through the Original GOF Design Patterns book twelve years ago now. Thankfully Elisabeth and co. wrote a funny, irreverent and so you don't have to.

What are your favorite Agile Books? 

Caveat Emptor - if you buy any of the books after clicking on my link I get 4% of the price. In all likelihood that means I might be able to afford a coffee or two.

Coming up posts on: Iteration Length (another lesson learned that I didn't think of in my original post) and Pair Programming vs. Code Reviews a rebuttal.

If you enjoyed this post, subscribe now to get free updates.

Best Agile Books 2007 the Background Material

This is the second part of my Best Agile Books in 2007 Edition. This post will considerably lighter on notes than its predecessor because I'm tired and under the weather.

Background Books

Corporate Culture Survival Guide by Edgar H. Schein - an insightful book that looks at the corporate culture and how it forms. In the second half it examines how to coax change out of an organization. Think of it as Fearless Change: Patterns for Introducing New Ideas for corporations. Added bonus its short and to the point.

Peopleware (2^nd Ed) by Tom Demarco and Timothy Lister  - A pre Agile classic on how development (and other) succeed and fail. They start by demonstrating most project failures are people and not technology related. They go on to help you organize and build better teams. Sadly this book has been in print for twenty years and we're still making the same mistakes. 

"The Wisdom of Teams" by Jon Katzenbach and Douglas Smith - Another pre Agile book Katzenbach and Smith study real teams in many industries providing some real analysis and rigour to the question of what made these teams successful. By the end of the book you will discover that "Nothing can guarantee the creation of high performance teams. The best you can do is put in place the conditions that will help them form." This book was at the core of my series Why Scrum Works. 

Influence, Science and Practice by Robert Cildani - You probably read this in an undergraduate psych course. Consider going back to read it again. This classic work covers how and why people are influenced. This is at play as our teams organize themselves and also as we try to influence others to try our new ideas. Its only one of the few books in recent years that I've read a second time and taken notes from. (The other being Jean's Collaboration Explained).

Do It Tomorrow by Mark Forester - Personal productivity guide. He explains why closed lists (effectively a Sprint Backlog) work so well. He's helped me become far more productive just by forcing me to map out what I will achieve after the daily scrum and then taking on nothing more during the day (except for issues raised by the team). Crises from outside the team will often resolve themselves without your intervention. There is alot of other good ideas to be mined here.

Getting Things Done by David Allen - the other great personal productivity. David's focus is on emptying your brain so that you can focus on what's important and not on the milk you promised you would pick up on the way home from work.

Half Truths and Dangerous Lies by Robert Sutton and Jeffery Pfeffer - A simple read on evidence based management. Many common rules of management are no more than myths passed down from generation to generation. They debunk pay for performance, forced ranking (employees are sorted in three buckets: top 20%, middle 70% and low 10%) and many other best practices. It's great if somewhat depressing read - after all most of us work for employers who subscribe to one or more these myths.

The No Asshole Rule by Robert Sutton - Are you an Asshole in the workplace? Do you know one? Bob will help you discover whether you are one (and self correct), survive them and document the damage they cause. My asshole test score can be found in this post from earlier in the year.

As I look back on this batch of books I can say that these were easily the most fun of the batch to read. I've got one more post on Code coming in and then I will return to The Year of Scrum: Lessons Learned. 

What are your favorite Agile Books?

Caveat Emptor - if you buy any of the books after clicking on my link I get 4% of the price. In all likelihood that means I might be able to afford a coffee or two.

If you enjoyed this post, subscribe now to get free updates.

Best Agile Books the 2007 Edition

Last year in response to some questions at a CSM course I wrote a post: "Top 8 Agile Books: Beyond the Basics". This past week I was help out at a CSM course when the topic came up again. This time I've a much longer list of books.

Top Three – I wouldn't start an Agile project without these

Agile Software Development: A Cooperative Game (2nd Ed) by Alistair Cockburn - Possibly the most interesting book I've ever read about agile software development. It's not about any one methodology, instead Alistair analyzes game play, individual communication, team cooperation: the elements that are the core of all software development. The book also includes sections on Agile outside of Software, a survey of the various methodologies and much more.

Collaboration Explained by Jean Tabaka - A through explanation of what our role as ScrumMasters, Coaches and Facilitators is. It helps agilists understand (and perhaps manage) team dynamics. It’s also the source for my Planning and Retrospective agendas. See: Good Agenda’s make Great Meetings. My comments are in no way biased by the whiskey Jean bought on the first day of the Agile conference this year.

Agile Estimation and Planning by Mike Cohn - Sprint Planning to Release Planning. Estimating in Story Points vs. Ideal Days. One stop reading for planning. Added bonus the book is very easy to read - only five hours and I'd read most of it.

Other Important Agile Books

"Agile Retrospectives: Making Good Teams Great" by Esther Derby and Diana Larsen - some great ideas for taking your Agile Retrospectives to the next level.

"Fearless Change: Patterns for Introducing New Ideas" by Mary Lynn Manns, Linda Rising. Trying to introduce change into your organization (if you're reading this post that's a safe bet)? Finding it hard? Look to Fearless Change for some great ideas - there are no silver bullets but this will at least give a fresh source of ideas and a starting point. Remember organizational change won’t happen overnight.

"User Stories Applied: For Agile Software Development" by Mike Cohn. Think that "An invitation to a conversation" doesn't quite describe User Stories in enough detail. Need to move on from the traditional requirements to an Agile approach and don't know how. This book was written for you.

Other Agile Methodologies

"Lean Software Development" by Mary and Tom Poppendieck - do you want to know how the Toyota Production System can be applied to Software development? Are you fascinated with a process that developed nearly forty years ago continues to help Toyota adapt to change? Need to uncover waste? Start Reading. 

"Crystal Clear" by Alistair Cockburn - it seems everybody and their brother has written a methodology book. So why does Alistair's stand out? Because Alistair is the Agile community's ethnographer/anthropologist. He studies real live development teams to see what succeeded and perhaps more importantly what failed. Crystal Clear is his distillation of those studies. In addition the Crystal family of methodologies is interesting because Alistair designed them to be adaptable on several axes: project size/budget, criticalness (ie plain old website -> life critical system). 

"Extreme Programming Explained: Embrace Change" by Kent Beck - you heard alot about XP - both good and bad, you've heard alot of hyperbole - with people claiming that XP is a license to hack or that it will solve all problems for all projects. Kent actually explains the stuff that matters. 

I've got posts on Background and Code coming up and then I will return year of Scrum: Lessons Learned. Sorry for the recent silence life has been rather busy.

Caveat Emptor - if you buy any of the books after clicking on my link I get 4% of the price. In all likelihood that means I might be able to afford a coffee or two.

If you enjoyed this post, subscribe now to get free updates.

Transparency Builds Trust

I hadn't really thought Transparency as a Lesson until I got to the end of the week and still haven't written about the Product Owner.

It's better to admit the failure - I have no posting ready, than to either ignore the problem or dash off a poor quality post.

Scrum forces transparency on us in the review meeting when we demonstrate working software. What ever we have achieved (or failed to achieve) becomes apparent at the moment. For a Product Owner who is used to hearing back seeing software once every 3-6 months this will be a breath of fresh air. But transparency can be taken further.