For all engineers working at KDAB, "The Clean Coder" is compulsory reading. It is a very interesting read because it is almost a lifestyle guide, rather than the usual dry text on personal time management. It covers all the common tasks faced by software engineers: estimating, refactoring, testing, coding... the lot. As proclaimed by the back cover, "[the book] covers more than technique: it is about attitude." It's a great introduction to software craftsmanship. Impressed with this book, I picked up a copy of "Agile Estimating and Planning" which is in the same series of books from Prentice Hall.
I am a fan of "The Clean Coder" and so grabbed me a copy of "Agile Estimating and Planning" from the same series. pic.twitter.com/AxlfG0Z7Hm
— Paul Adams (@therealpadams) July 22, 2015
The book is separated into 7 parts and 23 chapters. I will not bombard you all with a lengthy review of the whole thing all at once. Instead, I'll drip-feed you my thoughts one part at a time. Starting with the beginning: "Part I: The Problem and the Goal".
Chapter 1: The Purpose of Planning
This chapter should provide nothing new to anyone who has been through "Project Management 101" and is nicely couched in the context of software development. Ultimately we are asked "Why bother with planning at all?" and are presented with the following reasons:
- Reduce risk
- Reduce uncertainty
- Support better decision making
- Establishing trust
- Conveying information
Fred Brooks (in a pre-agile era) famously told us that we needed to throw one plan away, so we should plan to do so:
The corollary to this is that if you plan to throw one away, you will end up throwing away two.This is and has been an impractical suggestion. Plan to build something as quickly as possible and modify it as needed in the future.
Planning is very important. Plans are not. Fred Brooks saw agility coming. Hero.
Paul's Thoughts...
Good introductory chapter. Gentle reminder of a few things the reader should probably already know. Successfully sets the context for what is coming.
Chapter 2: Why Planning Fails
So now we start to get a little more in-depth with agility. Again, nothing too taxing at this point and certainly familiar ground for anyone who is an experienced ScrumMaster or Product Owner. This time we are simply asked "Why does planning fail?" There is, of course, plenty evidence for failed planning: how many people reading this have been involved in projects where scope, quality and/or timelines have been "off"? I know I have. Let's face it, we all have.
In this chapter the primary reasons for failure are cited as:
- Planing activities and not features
- Too much multitasking
- Features not developed by priority
- Not embracing uncertainty
- Estimates as commitments
The second point on this list is my favourite and one that often goes misunderstood... Once upon a time I thought I was Godlike for handling so much work. I was the multitasking master. Education and experience has taught me that multitasking is actually the productivity killer. Do one thing. Get it done. Move on. I actually control my tasks at work with a Kanban chart which has been specifically designed so that I cannot fit too many tasks into the "Work In Progress" state. In short: multitasking causes a lack of focus, increases the number of ramp-up periods/context switches, increases stress and, most importantly, delays the delivery of results, which may impact other people's work. The book contains a genius "why did I not think of that?" diagram to illustrate this.
Paul's Thoughts...
Great reminder of the factors behind planning failures and good description (without too much tedious detail) of why these factors happen in old planning styles.
Chapter 3: An Agile Approach
A good plan violently executed now is better than a perfect plan executed next week. --- General George S. Patton
Chapter 3, opens with an epic quote. Otherwise, the first half of this chapter is a little unnecessary; the history and fundamental concepts of agility are presented. In all honesty, I skipped through a lot of this. There is nothing new in here and it is all content I would expect the reader to have a good grounding in. I assume this was thrown in "just in case" the reader gets this far with no knowledge of agility at all.
Thankfully the second half of the chapter gets us back on point.
In the second half of the chapter we are reminded that planning is actually only as useful as the horizon; if you are trying to reach a target 20 miles away, you're going to need to check your progress and reassess 5 times, because the horizon is roughly 4 miles away. So what are the horizons in software engineering projects?
 |
| Paul == Artist |
Typically it is the three innermost of these that we care about. The inner two are certainly familiar with any Scrum practitioners (daily scrum and sprint planning/retrospective). Release planning is about determining what user stories are going into the next version of the product. If anything, it is about creating a "vision" that the team can buy into. Iteration planning is more in-depth: "What are the tasks we can associate with the user stories? What are the priorities?". Daily planning is hugely important, too: "What am I working on? Who/what am I blocking? Who/what is blocking me? Is progress as expected?"
Paul's Thoughts...
An interesting read for anyone who needs an introduction to agility and how to structure planning in an agile environment. I was left thinking "just cut to the chase!". The next part of the book, and my next post on this topic, is called "Estimating Size". Now we're talking!
Overall Thoughts on Part 1
It is satisfying to be reading a book that I can easily relate to my own experiences of both classical and agile project management. The background information is undoubtedly important for some readers. For me, however, there was just a little too much. Any experienced project manager (especially Scrum Masters/Product Owners) could skim through this and head straight to Part II, I think.
No comments:
Post a Comment