Agile Forest

Over the last few months I have pondered going for PMI’s Agile PM certification. Unsure of how dedicated to this cause I might be, I decided to at least start reading the eleven books on the syllabus and see how I felt after reading one.

The first one was “The Art of Agile Development” by James Shore and Shame Warden 2008. Unlike most of the other books this is one that I have not read and I wondered whether I would get much out of it other than an increase of my own Agile Data Dictionary (otherwise known as the mysterious wheel of terms that mean the same thing but are subtly different).

Because I am a ‘glass is at 50% capacity’ sort of person let me start off with a positive (yes I know that doesn’t make sense, but I just watched House and eww I’m still trying to mentally get over it). If you are a beginner to agile (note the little a) then this is really a good book to start with. It doesn’t cover everything, but it doesn’t say it tries to either. I would recommend this book.

The book is primarily focussed on XP practices. Now keep in mind that XP is at its heart exactly that – practices. This book takes the position that XP has evolved away from just the technical software development practices and is beginning to broaden its focus, albeit in this book it keeps calling all the other stuff practices too. This is where the big ‘A’ comes in. I like to think of Agile as not just either XP vs Scrum vs Crystal vs Kanban; I think Agile is taking what works out of all of them and applying it appropriately.

This book tries to take some of that ‘A’gile thinking and includes topics such as Energized Work, Trust, Slack, etc. This is definitely a good thing as I always found it odd that XP was so incredibly technical practice focussed, but you need to beware that a lot of the content that is being covered actually exists elsewhere in the land of Agile.

From a negative perspective the Practices by Phase table on page 21 made me want to shut the book straight away. It was there to ease the waterfall people but the association of practices to phases are incredibly wrong and most of the practices exist throughout the life of the project. The practices cross reference on pages 26-27 is equally cringe worthy with Scrum apparently the only other model for agile implementation.

Other notable thoughts as I read through:

• Data dictionary #1 Energized work = Sustainable Pace
• Data dictionary #2 Informative workspace = Information Radiators/Big Visual Charts
• Root cause analysis… surely this is more of a generically known term and not an XP practice.
• Trust… as a practice? I guess. It is a value to be upheld. Is upholding a value a practice?
• Data dictionary #3 Sit Together = Co-location. Really the word co-location wasn’t used once?
• Real Customer Involvement… apparently only at Analysis phase. Please can’t we have real customer involvement throughout?
• Ubiquitous language… seriously don’t get me started on this one. Who in their right mind uses a term like ‘Ubiquitous’ to describe what should have been ‘Simple’ or ‘Audience specific’. This goes along with the weird term ‘Etude’ used throughout.
• Data dictionary #4 Demo = Showcase
• Reporting… as a practice? I can see Burn Up and Down as a practice but a generic heading of Reporting is a bit of a stretch. The help box “Only produce reports that are strictly necessary” should have taken up a whole page and that could have covered it better. Nothing in here about a Car Park Diagram, but then again that’s an FDD practice and this is an XP book guising as an Agile book.
• Data dictionary #5 Done done = Definition of done. I am probably more familiar with the former than later anyway.
• 10 minute build… love it! I remember having a problem with this one once so I was really happy to see this.
• Documentation… again not really a practice and dare I really have to go back to the manifesto on this one. Thankfully iPhones have moved on since 2008 and most of us deal with documentation these days as simple snapshots uploaded onto a central project repository.
• Release plan… it was nice to see the information on this subject represented how it was. One of my pet peeves in the idea that at the start of a project all the work is going to be scheduled into a detailed, Gantt chart like release plan. This section didn’t do this and really focussed more on the adaptive planning of the work.
• Data dictionary #6 Planning Game = Estimation and Prioritisation. How I have always hated the term Planning Game. Nothing was mentioned here about MoSCoW or Planning Poker (or anywhere else in the book).
• Risk Management… apparently only gets done in planning (thought the text later says otherwise).
• Data dictionary #6 Performance optimization = ensuring you have the means to cover off the performance non functional requirements. Again, not really a practice.
• Exploratory testing… old school software development stuff, not something that XP should claim fame to (not that the author is notably).
• Practices by Role table is very poor, ignore it; or at least definately ignore the overloaded ‘Coach’ column.
• Maturity Assessment pgs 63-66 might be useful /shrug
• Not a fan of the concept of Step 3 in retrospectives “Mute Mapping” whereby you quietly group like themes together. Why wouldn’t you do it as you are facilitating?
• Not a fan of only fixing one thing and only one thing in retrospectives. Why have this charade of listing everything that isn’t working and needs changing. Now I am not saying fix everything, but surely more than one thing can be fixed! Maybe this is why people have such a rough time following through on actions? Nah, it’s because actions aren’t written as stories and scheduled into the iteration and hence followed up.
• Version control… old school software development stuff, not something that XP should claim. I was impressed however that they did talk about branching and advised against it – Yes! I feel vindicated after many years of saying no to branching.
• Really controversial idea on page 240. Probably my only new concept from the whole book. When at the end of your iteration time box any partially done work should be deleted from the code base. If it is important the story will be carried over, otherwise YAGNI. I like how this would seriously focus the team on finishing work like the time box should be and would help with that little bit of time for slack. Reality will likely kick in and I will never see this idea happen.
• Not much of a focus on operational/BAU/enhancements using Agile. Page 242 is the only one that mentions anything and even then it talks about Daily Iterations or having Batman come in.
• Stories have moved on since this book was written. There isn’t much in the book about Features and nothing on Epics. There isn’t anything about the standard format. It does have the standard comment that stories are for only business work which is a school that I don’t agree with. What are you calling the IT stuff that has to be done guys?!? It was nice to see that regression defects can be handled through stories (another vindication).
• I liked the idea that developers should expand their automated test coverage by spending more time watching how end users use the system.

Well, there you have it. One down, ten to go!