Another 2 book reviews

Lean software development: An agile toolkit, by Mary & Tom Poppendieck

Great book! Definitely choc a bloc full of really usefull information. This is a book I'll be returning to many times and each time I will probably learn something new. Alot of the stuff needs hands on experience first to really understand the value of what has been written down but I'm definitely eager to get started right away.

------------------------------

User stories applied: for agile software development, by Mike Cohn

A pleasant, easy read. Nothing very shocking but good to have on paper to grab for reference. there is quite a bit of padding to the book, it could have been a bit thinner without having lost value I feel.

Two book reviews

Test driven development: by example (Kent Beck)

An easy read (also quite thin). Didn't learn too much new but the later sections/appendixes that list refactoring patterns were quite interesting (I hadn't read about them before but I sure recognised some of them!).

Growing object-oriented software, guided by tests (Steve Freeman, Nat Pryce)

Sometimes a tad theoretic, sometimes a tad too practical. The automated testing of the user interface (reading value of label for example) is too extreme for my tastes but it was impressive to see it done. Great book to learn about mocking and mock objects! After all, Steve and Nat helped build jmock. It also expanded my ideas of TDD. I was to focused on unit tests but this book broadened my scope to include tests at every level and not to get too hung up with terminology.

Birthday greeting kata in C# .Net

One of the katas that I have recently had the pleasure of finding and trying out is the birthday greeting kata by Matteo Vaccari. It's a great exercise in what I have termed "refounding" of existing software (see an earlier post). Here is an opportunity to take existing code, refactor, and add unit tests.

Now I'm no java expert and although I had fun playing around with Eclipse, I felt more like a toddler learning to take it's first steps than a kung fu code master (not that I am that either mind you). So I decided to have some fun and port the code to C# .Net. If you're interested you can find it here (Visual Studio 2008 unit testing).

Have fun :-)

Refound your software

I've experienced first hand how making any changes to existing in use software can be a nightmare. Complaints from the business that each new change seems to take longer, cost more, and lead to new bugs are well justified. Why is this? Well scrum has taught me all about technical debt, and how this leads to increasing problems as the life of the software lengthens. So obviously, next time I'll do it better!

But for now, for all those companies with existing software suffering from technical debt, what about them? Well, I like the concept of "refounding" or rennovating them. So don't throw the software away and start over. This is much to risky, costly, and time consuming. Instead, whenever a change needs to be made to the software use the following steps to refound safely:

- create tests (most likely not unit tests) for the code that will be changed and make sure that they run (green).

- refactor the code to improve the structure and allow unit test to be created (enabling mocking is an important one here). Do this is small steps and make sure that after each step all tests as still green.

- then make the desired changes that triggered all this (be it a bug fix or a new feature etc). Of course, use test driven development here, and again make sure all tests stay green during the process.

This way, the software is improved slowly step by step, but only in the areas a change was desired anyway. So the entire software is not refounded, only the parts driven by business value. Most likely, 80% of all the changes will focus on 20% of the code. So refounding is a low risk, driven by business values approach to improving existing software. I think this will go a long way to lengthening the life span of existing software.

Agile books

My first agile/scrum book was "Succeeding with agile" by Mike Cohn. At the time, I was looking for an introduction to Scrum. This book was not it. The book is all about how to introduce scrum into your organization, so it assumes you know what scrum is and preferably have had some experience with it. That being said, I learnt everything I needed to know about scrum as I read it. In addition, as a bonus, I immediately also learnt the troubles one is likely to encounter in the "real" world with scrum: organizations that say "great, but not for us" or managers that are scared for their job, etc. So in short, it actually worked out for me.

Today I received my 2nd book: "Test driven development: by example", by Kent Beck. I'm very eagre to get started as test driven development is one of the key XP elements that works so well together with scrum, but one that few organizations (I have seen) are doing.

I have also ordered the following books to complete my agile library (for now, but I'm open to other suggestions!):

Lean software development: An agile toolkit, by Mary & Tom Poppendieck

Extreme programming explained: Embrace change, by Kent Beck and Cynthia Andres

User stories applied: for agile software development, by Mike Cohn

Test driven development workshop

The company I'm currently working for is interested in starting up with Scrum but finding it difficult to make headway. As a start, they've decided to start familiarizing themselves with some of the agile and scrum elements. For example, they asked me to prepare a Test Driven Development (TDD) workshop for them so that they could gain a better understanding of what the benefits are.

Not being an experienced TDDer either, I googled the great StingCalculator Kata by Roy Osherove and prepared this. I found this to be a great kata for TDD because:
1) it allows for incremental building of tests and functionality (triangulation)
2) it quickly demonstrates the value of refactoring and reuse of code
3) you can easily hit red when going for the Obvious Implementation (fast) and so it forces you to go back to Fake It and Traingulation (slow).

I also made a short introduction to TDD and this Kata.

Scrum but not software

During the scrum master course, Jeff mentioned that he was working with a venture capitalist firm that was using scrum internally. This triggered me because as a developer, I'm familiar with scrum for building software. But here was a company using scrum that was definitely not building software. Of course, I really shouldn't have been that surprised. Most of the principles underlying scrum seem to have come from how Toyota builds cars.

Intrigued, I read the paper by Jeff on this company: "Take no prisoners". From this I learnt that even project driven companies, with multiple project managers each working on their own project, can still benefit from implementing scrum. It's a bumpy road and things are much less clear than they are for a software company, but the principles stay the same.

The difficulties for the company discussed in the paper seem to center around getting "done" and "ready" defined. And to do this, they have had to reorganize the way they work. Obviously a commited team over there. Other problems center around creating overlapping expertise within the scrum teams. Initially, everyone has their own projects, so there is little or no overlap. But in time this seems to have grown and improved, allowing for greater efficiency.

The good news is that this company is seeing productivity double+ (and with less working hours). So maybe there's hope yet for all you over worked managers out there!