Notes on the book: “Agile Retrospectives: Making Good Teams Great”

I finished reading Esther Derby’s & Diana Larsen’s book “Agile Retrospectives: Making Good Teams Great” a couple of weeks ago. Although my experiences with retrospectives are very limited and have no experience of leading a retrospective, the topic was interesting and I decided to order the book, which is basically a handbook for leading retrospectives with very specific tips and guidelines for the whole process.

If you’ve never lead a retrospective and you are thinking of organizing one, this book is an excellent place to start. The whole retrospective process is described and explained very thoroughly with hands on tips on every phase of the retrospective. If you’re looking for such handbook, this is your most definitely one to pick to the bookshelf. But be warned, this comes in a form of a “user manual” – very structured text, which might have been juicier to read, if it had more narrative experiences from the real life.

By the way, the authors have given a presentation on the same topic at Google. Check it first out, and if you’re still interested to know more detailed instructions and guidelines for facilitating the process – Go and buy the book. Another good resource for learning more about retrospectives is Linda Rising’s podcast on Software Engineering radio. Her notes and comments are more on a general level, but are by no means less relevant or interesting.

And once again I find thinking this same thing: although the context of software engineering is often highly technical, the problems are solved by individuals acting as a team.  Soft skills in team work are often way too underestimated compared to technical skills. The better the chemistry in the development team, the better the results -  even if the team wasn’t technically that brilliant.

James Shore’s brilliant notes on making an organizational change

James Shore, a developer and an agile coach, has kept a change diary on his experiences from a consulting gig where he tried to change a development team to use agile and XP methods. Did he succeed in his quest or not, does not matter, the most important thing is the documentation of the bumpy road.

The notes are rock solid and making much sense, with numerous tips for people trying to make an organizational change. Well, organizational might be a bit heavy word here, ‘team’ might describe the right magnitude. Anyways, must read for everyone trying to make an impact in his/her organization.

One of the key points in the notes, in Chapter 10:

It took me several years to realize this, but now I believe that the Way to Change is No-Change. No, this isn’t some sort of pseudo-Zen mysticism. (Okay, I admit to dressing the phrase up in a zen outfit, just for fun.)

Selected Martin Fowler presentations

Martin Fowler is some kind of an icon of modern enterprise software development. All those books he has written and also It seems like it is quite hard to find a conference these days, where this loud-mouth isn’t speaking. And it is true, that he has contributed to the business quite a lot: work on patterns, refactoring, agile, DSL, etc.

Some (including myself) might think that this evangelist should step down from the clouds and get his hands dirty on real projects again to see what the real life is in most of the projects. But no one can argue that he wouldn’t be an outstanding at giving public presentations. Actually I think that he’s technical contributions are nothing compared to his savyy presenations skills.

I’ve gathered some of his presentations below. Go ahead, grab some snacks and good drink and enjoy the presentations. Don’t be bothered with some of the hype and over simplification of things. The way he presents issues and takes the audience is something that a very few can do.  One of my personal favourites is the third set (Look mom: No slides at all)

• Tutorial on DSL
• High-flying rant on ESB’s
• Three things Fowler likes in Ruby on Rails
  

Test Driving Swing Applications

I’ve done my fare share of developing Swing apps in my java years. Perhaps 40% of UI development in my 8 years of java experience is done in Swing. Now that’s a quite a big percentage these days, when most of my colleagues have never done any Swing and their UI development is mostly done to web. Since the industry is concentrated to the web, naturally most of the tools (for example testing) are concentrated to web as well.

I believe that integration tests are perhaps the most valuable tests that are written (Acceptance tests excluded, but you create acceptance tests using these tools), so I share my experiences from two very different open source testing tools for Swing. One is called the FEST-Swing, and the other is Marathon.

FEST-Swing

FEST-Swing is a Java API for, which is based on looking up components and making assertions on them. The API is a DSLish ‘fluent API’, which makes writing the tests somewhat pleasant. It can be used with either JUnit or TestNG so it doesn’t lock you in one unit testing framework, and the best part of the project is that it is active (last update was on May 19 2008). For example, I used FEST-Swing for testing my SCJD assignment, and it proved to be a good tool for the purpose – no problems in writing the tests, and it was quite easy to test all the scenarios. I’m not sure how it responds to more complicated UI’s, but I’m ready to give it a try in other projects as well. Very promising indeed.

Marathon

The project was initially started by the ThoughtWorks developers, so I thought there might by something to it and I decided to give it a try. The framework is based on capturing user interactions and recording them as Python scripts. Of course you can edit these recorded scripts later on using any text editor, because the scripts are valid Python, not some proprietary format. I tried this on one quite complicated (lot’s of user interface logic and decision making) project and I ran into problems. The scripts recorded by the recorder all required some manual editing before I could re-run them from the Python file.

Frankenstein

Sidu Ponnappa sent a comment to my “about”-page concerning another open source framework, the Frankenstein. It is hosted at openqa.com, the same site that hosts Selenium. Like Marathon, this is also started in the ThoughtWroks labs. After a quick try Frankenstein is a clearly on a very early stage of it’s development. For example, the documentation is extremely lightweight, with practically no examples.

The framework allows you to record your UI actions, which are then saved to Ruby scripts. After a few try and errors I managed to record some actions and run the saved Ruby scripts after minor changes to the scripts. What I liked about this one was the simplicity of the recorder, and the possibilities that the Ruby driver brings to testing the UI’s..

Determination and willpower

I saw a video of a one-armed American high school kid, Porter Ellet, playing one of my favourite sports basketball. Not only did he manage himself against the others, but he is actually the team’s leader in scoring with only a single arm!

That really requires determination to Get Things Done. And that is a quality what we all software developers should have. To get things done in the best possible technical manner, despite of managerial and technical obstacles. It is easy to just get thing working, but to really finish of with robust, readable and testable code that meets all the possible requirements that the client didn’t event think would exists, is a whole different thing. It requires determination to give that extra push, that separetes the best software from the average.