Both a great introduction to agile development and a reminder of how to focus on what value is and how to get it.
Who the book is for
I really enjoyed the style of this book. There aren’t a lot of words on a page and each page has pictures. That might not make me sound the sharpest tool in the box, and maybe I’m not, but for someone who reads a couple of minutes here and there on a commute it helps a lot.
I’ve been working in agile environments for a few years now and I still found this book useful. It’s simple layout and message of “keep it simple” is a really nice reminder that if things are complicated, you are probably doing them wrong.
In the intro, Uncle Bob describes this book as a must for CTOs, directors of software and team leaders. While I think that is true, I think it would be better for a wider audience to read this book. It would be amazing if this book was read by the recipients of software. Agile development has a lot of benefits, but those benefits are hard to achieve if all parties aren’t bought in to the process.
What is a feature?
A lot of the book is centered around the importance of features.
We should plan by features, we should build by features, we should even grow our teams around features. Working towards features does have a lot of advantages. Planning is easier with smaller chunks, it is easier to pivot the project and while I think estimates are rarely helpful, it is easier to estimate smaller pieces of work.
However, I wonder if feature is the best term for what we should be breaking the work down in to? Would something more in keeping with the agile ideas of always being in a releasable state and getting value from releases like “deliverable” be more appropriate. Sometimes I find that the term “feature” is too easily interchangeable with “project”.
Once the term feature gets swapped with project, it makes realising agile benefits such as being able to work on the most valuable thing at the time difficult. As people often like the feeling of completeness that comes with finishing a project.
Bug free
In order to keep delivering value and enable flexibility the code has to be kept bug free.
One way Jeffries says to achieve this is to continually design the system as it grows. While I have always refactored code as I develop as part of the TDD cycle, this made me think that sometimes I need to take the brave choice to refactor the design of the system. From a business’s perspective this may not seem like the popular choice as speed is often seen as crucial, but keeping the system clean and flexible is important in the long term.
Another example of going slow to go fast is ensuring the system has good test coverage. Unit tests are an essential part of development, but acceptance tests can be massively helpful in enabling rapid releases of small features. By knowing that new code hasn’t broken existing features this can help to reduce manual testing and increase confidence in the system.
Up front planning
I find planning a very interesting topic in agile development.
Large detailed plans seem to make people feel comfortable and think that they are reducing risk. However, this rarely seems to be the case. Goals and measures of value are important and so is knowing the current direction to those goals. But a detailed long term plan is rarely going to be helpful, unless you can see the future. However it can also be damaging to the success of a project. It may stop you feeling like you have the flexibility to change direction.
Whip the ponies harder
There is an interesting chapter in the book dealing with the dangers of just putting more pressure on the team to get more out of them. This is extremely unlikely to work very well. Due to the extra pressure, mistakes will be made, best practices will slip and defects will be introduced in to the system. As previously mentioned, overall this will make the project take longer.
Jeffries goes on to say that analysing and removing any sources of delay for the team is likely to have a much larger impact. The same goes for helping the team to improve. This could be through training or helping them analyse how they are working for example.
I would have to say I whole heartedly agree with this point. Maybe I’ve just been very lucky in my career to have only met hard working developers but I have never worked with someone who I thought “if they worked harder this would go a lot faster”. Training and working to help resolve the team’s issues has always been a much better way to help increase the flow of work.
A very helpful book
I really enjoyed this book. It’s reminded me to take a step back everynow and again, slow down and think “am I doing this the best way?” when it comes to agile development.
It’s so easy to say “yes I know how you should work in an agile manner”, but it’s also very easy to get bogged down in processes and “agile” methods.
The Nature of Software Development has made me think more about why we work in a an agile way in the first place, that must be a good thing.