Javaddicts

Retrospectives are (or at least should be) an important part of a team’s life, be it an agile one or not. The book “Agile Retrospectives” by Esther Derby (of “Behind Closed Doors” fame) and Diana Larsen aims to get you and your team going with them. In an “agile” team where you’d work in iterations, a retrospective should take place after each one, and ideally after the project’s done. The latter would be the case for teams working with more classical end-to-end development approaches.

The book starts out by describing how to approach a retrospective, assuming you’ve never done one before, taking into account things like timing, group dynamics and structuring. The main part of retrospectives are activities. That doesn’t mean just doing something, but achieving something. An activity is always related to a specific goal, e.g. identifying problems. You wanna keep retrospectives interesting. That’s why this book introduces a lot of possible activities which you can adapt or change more to your liking (or team, for that matter). The next about 90 pages list activities you can do in each stage of a retrospectives.

The stages basically split a retrospective into parts into beginning, end, and the stuff in between, the latter being data-gathering, generating insights and deciding what to do. There are different ways to achieve these goals, and the book describes a lot of them in a sadly not-so-glory detail. The list of activities is exhaustive, but each one doesn’t go into much detail. It’s basically a list of things to say or do, and how to deal with certain situations that might come up.

Though some of them come along with examples from real or invented teams, in my opinion there are too few examples going into insufficient detail. “Behind Closed Doors” lives from the story it was built around. I miss that here.

The rest of the book does a good job explaining in a more suitable detail, but the list of activities might get a little dry, since some of the activities are variations or build on others. I’m aware that it’s supposed to be a reference you can get back to, but even then a little bit more information or examples couldn’t hurt.

“Agile Retrospectives” is a good reference to get back to when you plan a retrospective for your or another team. It’s a manual, which is good and bad at the same time. It contains all the information you need to get going, but it doesn’t tell you how to do it in every nitty-gritty detail. You’ll have to figure out the details yourself. And if that was the authors’ intention in the first place, they did a good job. If you thought about getting started with retrospectives in your team I’d recommend getting the book and reading the all the stuff around the activities, maybe some examples of the latter. When you start planning a retrospective, come back to the book and skim through the activities to find the ones you’d like to include in your retrospective.

One last thing: Why the name “Agile Retrospectives”? Though constant self- and team-improvement is an important part of agile teams, using the Agile brand is unnecessary here. A title like “Effective Retrospectives” would be more fitting, since retrospectives aren’t agile-only, and in the end running effective retrospectives is what the book is all about.

Spring (as in season, not as in framework) is always a good time to get some great new books to read in the sun (if you dare exposing your geek-skin ;). To be prepared the books are slowly piling up on my shelf. It’s sad though that they’re not including the time to read them. The main focus at the moment is AJAX and Rails, so let’s see what’s in stock.

Manning just released two great books: “POJOs in Action” and “Ruby for Rails”. The first one sounds like a no-brainer on first look. If you dig deeper, you’ll see that this book is about a lot more than just POJOs (you could write a short Friday book about these in probably a day). It’s about current lightweight frameworks like Hibernate, Spring, JDO, iBATIS, and, to complete the circle, EJB3 (though I don’t consider EJB3 to be lightweight, but that’s probably a different discussion). EJB3 is mainly included to make the reader see what solution xyz would look and work like with the next generation of JEE. The book is an excellent read and gives a nice overview about all the technologies, and how to design lightweight “enterprise applications” (ah, I love that word) from API to locking and transaction strategy.

“Ruby for Rails” goes into the complete opposite direction. Though its main focus is also lightweight web development, it’s Manning’s contribution to a growing stack of available books on Rails. It covers both Ruby and Rails, and also how they work together, which is probably the biggest plus of this book. If you’re stuck with ideas on how to move on after reading “Agile Web Development with Rails”, this book maybe is for you.

Of course, The Pragmatic Programmers don’t sleep. They’re on the edge of throwing out “Rails Recipes”, a nice collection of small recipes (surprise) about different parts of Rails. It covers a lot of different aspects, and though some consider it more like a collection of entries in the Rails Wiki, it’s still a good composition and easier to use and read than the Wiki. It includes e.g. versioning, of course AJAX, tagging, security, testing, and a lot of generally applicable recipes. Have a look at the TOC for the bigger picture. It’s still a Beta Book, but it reached RC1 a week ago and will probably be released soon.

Next up is “Pragmatic AJAX”, also by The Pragmatic Programmers. Having just left the beta cycle, it stands in firm line with the other popular books on AJAX, like “AJAX in Action” or “Foundations of AJAX”. All three jointly took a seat on my shelf and wait to be read. Looking forward to reading all of them.

Last but not least, and fresh from the press, say hello to “Practices of an Agile Developer”. A book which joins the shelf of books on best practices for the everyday-life of a developer. It’s a close companion to the original “Pragmatic Programmer” and “Ship It!”. Though I’m not so fond of the word “Agile” anymore, the practices in it are still very applicable.

What I’m reading with the most interest right now is “Eric Sink on the Business of Software”. While focused on small ISVs, it’s still a very good book with stories from someone who succeeded with his own company despite making a lot of mistakes (which he’s happy to share). Very entertaining read and also full of good advice.

I’m already working on some of these books, and can say with confidence, that at least “POJOs in Action”, “Ruby for Rails”, “Business of Software”, and “Rails Recipes” are highly recommended.

Those aren’t the only new books, of course, but I reckon it’s enough reading material for the next weeks ;)

The fine folks at 37signals took the time to write down a few pages of they think is good advice for small software companies. Why do they think that? Because they too are a small software shop, and seemed to learn their lessons from their own experiences, which is A Good Thing. We know them for creating great software for our everyday using pleasure, and that know-how normally comes a long way.

The book’s called “Getting Real”, and you can buy it from their website. It’s divided into a few chapters and deals with stuff like running the business, design, coding and best-practices for a team. Though you’ll find a lot of that measly white-space in it, the book has some very valuable and no-fluff advice. Don’t expect a nice story oozing you in, this book will get straight to the point. If something’s been said, it moves on to the next topic. If you worked in the business for some time, you’ll probably be familiar with a lot of it, but it’s a good read anyway, because it’s one more confirmation that you’re probably doing it right. And there’s always something to learn.

It’s an excellent read, because it’s short and painful or painless (depending on whether you’re familiar with it or not), but don’t expect advice on how to introduce a certain way to handle things in your team or company. As Scott Berkun put it: “…this book is more mantra than guidance or instruction.” You probably can adopt these practices right away, if you’re a small shop where there’s probably only little resistance against improvements or new practices. If you’re working in a bigger company it’s most likely harder, if you’re swimming against a stronger current. There the book leaves you alone, and you’ll have to find a way to introduce them by yourself.

Of course, not all is lost on this book. It still offers highly motivating advice. I felt a sudden itch to do something and get some product done and out to the customer, if I’d had any. You can literally feel the motivation these guys must have. I highly recommend reading it, because the authors might have done something right with what they’re writing about. If you look at the success and beauty of their products which always are a pleasure to use, you could think they have a point. And most likely, they have.

The book is only available in PDF format, and you can buy it from their website.

Technorati Tags:
books, review, 37signals, getting real

This is a follow-up to my post Ship It! Sneak Peek, since Ship It! arrived not too long ago and I couldn’t wait to take the rest of it in.

The introduction gives a short overview about the rest of the books and gives some tips on how to read the book corresponding to your role, either developer, team lead or manager.

The rest of the book is divided into four chapters:

• Tools and Infrastructure
• Pragmatic Project Techniques
• Tracer Bullet Development
• Common Problems and How to Fix Them

The first chapter introduces common tools that should work for almost, if not any project. Continuous integration, issue/feature tracking, scripting your build, having a test harness, and the like. You do these things, right? I liked the good and short explanations of the kinds of tests you can write, since it’s easy for the beginner (it was for me) to confuse e.g. smoke tests with unit tests.

The second one explains common techniques for projects. The most important one for me is “Work From The List”. It’s a list containing all features and tasks for the project including an estimate and a priority. Everything you need to get going, and to keep your project running. The rest of the chapter goes into good detail about having a tech lead, communicating on a daily basis, code reviews and code change notifications.

All mentioned techniques might sound familiar to you, if you’re pragmatic as hell. But the book is not just a list of techniques, it’s a about how these techniques work, why they work and why they’ll work for your project. Although most of the stuff is used in my current project at work, I got a lot of new inspiration on what we could do better from the first 2 chapters. I recently had an epiphany when I finally saw The List in front of me on a whiteboard. It was one of these moments that you’ll never forget, because you see that it just works and why it works at the same time.

Every technique explained in these chapters is accompanied by a list of things you can do to introduce it in your project, and a list of signs of doing it right and doing it wrong.

The next chapter describes a development technique called “Tracer Bullet Development”, a quite interesting approach to developing software. First your team agrees on specific layers for your project. Each layer gets a skeleton that just returns fake data. When all layers are stubbed out and talk to each other, each team can start adding code to its specific layer. The pieces slowly come together as all layers come closer to being finished. Well, that’s the short version, but it’s a very interesting approach for new projects.

The book finishes with a collection of common problems and little recipes on how to fix them, including inheriting legacy code, a broken test suite, team problems, and the like. Very good stuff, always comes in handy to solve those problems every project experiences from time to time (or, always, if worse comes to worst).

I was amazed that these five chapters only take about 160 pages and yet tell you all you need to know about successful projects. I’ve experienced a lot of these problems myself, and so did/do you, I’m sure about that. Jared Richardson and William Gwaltney have put together an excellent guide for both developers and managers. A must-read, if you have problems in your team or projects, and a must-read to confirm you’re doing the right thing. As both the authors do I can only recommend to get this book, find a best practice that could improve the way you and your team work and start using it to see if it works for you. If you want to start small, check out the selected excerpts of Ship It!.