patkua@work

The intersection of technology and leadership

Category: Books (Page 5 of 6)

Book Review: Continuous Delivery

December 3, 2011 / / 5 Comments

I just came off my last holiday where I got through reading two books that I wanted to. One of these was the heavy but insightful tome, that I dragged in my suitcase, Continuous Delivery. Before I begin, I should warn you that I work for ThoughtWorks, and that both Jez and Dave (the authors) are and were my colleagues so take this into account with my review.

What I enjoyed

Continuous Delivery is a very practical book that covers a huge range of topics from cover to cover. I feel that they found a good balance between giving just enough advice (and more importantly why) with plenty more references for those who want to find a topic to delve deeply. I felt it really lays down the ground work for many projects (but not all) that need to see the light of day.

I think it’s also great that they not only outlined the practices and tips, but also outlined the principles. It gives the book much more merit and will make sure it stays relevant as tooling and new techniques are invented. On the flip side, they do give enough advice on tooling, and, at least, current up to date advice on how one might achieve things.

I like that the authors expressed their opinons strongly on some of their tooling such as, if you’re going to use a commercial source control system, how it should be used and why, or what the problems with the build process in maven or the limitations of various toolings are.

The book is peppered with war stories. I think I know some of the examples they cite, or at least, heard about it from other people and I think some of them are really strong stories about some of the ways people approach deployment.

What would make it perfect (for me)

I’m not sure if they framed the context of Continuous Delivery enough in terms of the types of applications it’s appropriate for. I know that there’s a current (constant) movement in the startup community of “just putting out there.” I think that is an alternative approach that works for some amount of time (or at least changes some of the testing/feedback process). I think for throw away apps (this one is always hard to judge), it may not be worth investing in the same degree of how much effort you put into the process. I think probably the closest advice but should have been expanded upon was, “be pragmatic about how much you automate.”

One particular headline (out of the very many) grabbed my attention, “Test targets should not fail the build.” After reading that section I think I understood what they meant, but it should have been relabelled, “Failing test targets should not immediately *halt* the build” -> it should still fail the build at the end.

Finally almost all of the chapters, for me, had lots of great advice and in working reaffirmed many of the conversations and thoughts I’ve had over my career. I did find the final chapter about “Risk Management” a bit thin, feeling like it was added at the end and either deserved much more attention or should have been dropped. It felt like it had a different tone, or was written at a different time and couldn’t quite see how it would fit in.

Having said that, these last bits are only minor points in a huge volume of rich information and is essential reading for anyone who cares about their profession.

Putting this into practice

For most of the clients I work on, the clearest and most difficult part of the organisation will be the (im)maturity of the operations side of the organisations. Most are already not set up for success with completely different parallel hierarchies from development and competing goals that go against constant change. I still see this, “last mile” problem being the hardest (at least for me to solve). I am hopeful about the DevOps movement and hope that the IT parts of an organisation can only take it much more seriously. I’m hoping this book shows how more companies can achieve this.

Book Review: “Get Better Faster: Ultimate Guide to Practicing Retrospectives”

June 20, 2011 / / 0 Comments

I came across this free e-book, “Get Better Faster: Ultimate Guide to Practicing Retrospectives” via twitter (though I can’t seem to find the tweet that led me to it anymore) and thought I should write a review of it, like any other book. I’ll use a variation of the perfection game for this review.

Things I wouldn’t change
Firstly, it’s licensed under Creative Commons so anyone can use it. Yay. Then there’s the fact that it’s an eBook so it makes it quickly accessible to every. I guess it’s a bit more like giant slideware than a typical book, but that makes it easy to digest when reading on a computer – generally not to much text and nice little break out sections to help keep it varied.

The book references a number of interesting related practices such as After Action Review (AAR) developed by the US Army, though note they refer to it by the After Review Cycle that seems to be coined by a single consultancy. I will point out here that I disagree with the disadvantages of AAR that they list to compare them to retrospectives. If you read it, for instance, replace “ARC” with “Improvement” or “Learning” and it still reads the same. My point is that the inherent disadvantages are not an essential quality of the tool itself).

I like the 8 tips for better retrospectives that are widely useful for many teams and environments, mirroring many solutions to those I’ve suggested in my previous serious on, “When Retrospectives Go Wrong“. I like the way they highlight the importance of a facilitator role (which, in my experience, definitely helps make any important meeting more successful) and the provide some tips directly for the facilitator.

Finally they provide some good advice on making recommendations more tangible and, hopefully, more likely to be implemented.

Things that are different
Many people often ask the question why bother running retrospectives, and they have a page on metrics on retrospectives. I don’t necessarily agree with all of the metrics, it does answer some immediate questions managers and executives often have (unfortunately it is often the wrong question, in my experience, to answer).

Things that would make it perfect
It saddens me that, in the book, they make no reference, nor no acknowledge to other books on the topic. There is a small list of articles linked to some web resources, but I find it strange that they made no references to Kerth’s “Project Retrospectives” book, or Derby and Larsen’s “Agile Retrospectives” book. Nor to websites such as http://www.retrospectives.com or http://agileretrospectivewiki.org/

It also pains me the whole eBook is covered in excessive branding (twice on every page!) Fair enough they built it to market themselves, but really!

There is very good advice in the book, such as “set the meeting for one-to-three hours, with one hour often being ideal”. These novice rules/guidelines are important however I feel prevents people from achieving true mastery without explaining why these are the cases. In this example, the question best answered is, “Why is one hour ideal?” The lack of explanations is a problem as people who start to break these rules don’t know where to look next, or what to try, when the context isn’t appropriate.

Drive by Dank Pink

June 6, 2011 / / 2 Comments

I finally picked up a copy of Drive to read. The book looked ominously big, however I found out the two hundred (ish) pages had been printed on fairly thick paper and was pretty engaging to read overall. Pink focuses on a topic close to my heart, describing the way that people find engagement and what drives people. It’s quite relevant to the way that I like to work, and what the company I work for strives to achieve.

Pink covers a lot of interesting material, including many references and backed up by a lot of research. In it, he compares classic management techniques (financial incentives) and details research that describes why they fail to achieve what they need to do. He talks about interesting research that shows that a small financial incentive helps boost short term performance (in work that requires no thinking) at the cost of long term performance and detriment to creativity. For today’s information worker, and the chaordic environments we work in, this should really be raising alarm bells. To me, it’s akin to the systems thinkers that know that measuring and rewarding workers on the wrong incentives causes lots of problems. It also rings anecdotally to what I’ve seen some really talented people who work in these financial institutions driven into strange behaviours due to “bonus schemes” and loops.

Pink reiterates over points such as once we hit a certain wealth, happiness is no longer correlated with wealth. We seek, instead greater things. He gives many examples about how money isn’t a motivator for many people citing the achievements of Wikipedia, open source communities that build software such as Firefox and many more. He talks about once this is achieved, people are driven to solve problems, and be creative. He gives examples where people are driven to complete puzzles and games, not because they are paid to do it, because of some intrinsic drive.

Pink continually describes what gap there is between research and business and provides a way forward describing a number of elements necessary to satisfy this intrinsic drive. He talks about the need for autonomy, the idea of achieving mastery, and developing a true sense of purpose as well as providing a toolkit for people and managers to achieve this. I like to think that the agile values help businesses to focus on creating environments that help satisfy this new style of management. The idea of Software Craftsmanship emphasising lifelong learning and mastery, a common theme in agile teams to be autonomous in task completion and done right with lean thinking, building the right thing for a good purpose.

Above is a wonderful RSAnimate video helping to summarise the book.

Book Review: Quality Software Management: Systems Thinking

May 17, 2011 / / 1 Comment

I’ve been interested in Systems Thinking explicitly for the last two or three years. I haven’t had many good books I could recommend to anyone other than “The Fifth Discipline.” Last year, I inherited a wealth of Jerry Weinberg books from fellow geek, Romilly Cocking and just got around to digesting a very classic book, Quality Software Management: Systems Thinking. Weinberg, whether or not you know it, has had a huge effect on our industry. He has written many books on wide ranging topics, and being a participant/organiser of the Amplify Your Effectiveness (AYE) conference continues to influence many leaders.

Anyway, back to the book.

Hard cover books are always a lot more intimidating than their soft covered brethren. Perhaps it’s the sheer bulky that does it. Fortunately the text is rather large and with only about 280 pages of content, easily consumed on a number of continental flights between the “no-electronic gadgets” zone.

I’ll admit that describing Systems Thinking is hard. Walking through, what Weinberg calls, Diagrams of Effects are intuitive when he explains them step by step, however I find it hard to describe the process and never have been very confident in some of the ones that I have used.

The Mechanics of Systems Thinking Diagrams
One tip that Weinberg talks about is thinking about the things in the boxes as things that you could measure (or you do measure) and their relationship between each other. Giving the item in a circle a name has been a challenge for me, and Weinberg presents a heuristic I feel I can make better use of.

Unlike models I’ve seen from places like Soft Systems Dynamics, Weinberg doesn’t use a plus or a minus, and maybe you’ll find his notations work for you. I can’t say they worked or didn’t exactly work for me. I did appreciate the different take on making the secondary, or implicit loops more explicit by attaching repeating loops to the lines they amplify, rather than to the entity they end up with.

In other Systems Thinking Diagrams, people sometimes note a delayed effect, something I was surprised didn’t really turn up in the book to a great deal. I don’t know whether or not this was intentional or not. A new difference I learned though was putting on another notation for diagramming where managerial decision/input affects the Systems Diagram. The way that Weinberg wrote about using this brought a little bit more of a humane aspect to it.

Repeating the role of Mental Models
In the Fifth Discipline, I didn’t really understand the importance of Mental Models related to the point of the Learning Organisation. After chatting to Mark Needham recently on the way that people interpret different things, and seeing how crucial this was to interpreting and drawing Systems Thinking Diagrams in Weinberg’s books, I better understand why these two things cannot be detached. In fact, it was very timely with the question that XP2011 keynote, Esther Derby kept asking, “In what world would this make sense?” to see things from a different Mental Model.

Weinberg tells a really good story about how these Mental Models effect the observation. He recalls a story talking to a manager who’s managed to work out how to distinguish good programmers from the bad ones. The manager starts talking about how he’s noticed how some programmers talk a lot to end users, or to other programmers. A grinning Weinberg, nodding at the manager’s observation slowly stops as he comes to realise how the manager don’t think of these inquisitive, communicative programmer’s as the better ones, unlike what Weinberg (and maybe you and I were thinking). Same observations, different interpretation.

Reconfirmation of in built human biases
We are full of biases that we aren’t even aware of. Many of Weinberg’s anecdotes remind me of some in particular. For example, he talks about how managers running projects that continue to fail, blame it on “bad luck”, or “something out of their control”, whilst taking personal credit for those that do succeed. This is a really good example of the Fundamental Attribution Error.

Things that didn’t work for me
Throughout the book, Weinberg refers to Pattern 1 and Pattern 2 type organisations. Even though he explained them early on in the book, I found it difficult to anchor any real meaning to them by the time I’d finished the book. I would have liked to have seen him give them better names and use them throughout. It’s a minor detail, however I did notice this slowing down my reading.

Summary
I’d recommend this, still highly relevant, book to people involved in IT today. Though it’s published in the early 90s, I’m surprised at how many of the stories are still relevant. It not only explains the basics of thinking with systems using models anyone can relate to. It also explains those systems diagrams that apply to the software problems of today.

Book Review: Object-oriented Software Metrics

February 21, 2011 / / 3 Comments

Working for a client in Berlin, I find the plane time where I normally catch up on some reading. Services like Read It Later make bookmarking online pages for offline reading a pleasure. This morning’s trip, I finished reading a book Michael Feathers tweeted about that. Titled, “Object-oriented software metrics”, and published 15 years ago I found this book most easily from a online second hand book store, and have to say I enjoyed many aspects to this book.

Wondering how much interest a metrics book could be, the author did well to keep the short book punchy and brief. I enjoyed the conversational style of the writing, and the pragmatic nature of his recommendations, such as “I put the threshold at zero so that we explicitly consider any violations.” He starts the book describing metrics and that they should be used for a real purpose, not just randomly corrected, and something I’m pleased resonates very well with a chapter I’m contributing to a book. It’s obvious he comes from applying metrics with real purpose in the real world, talking about examples where various metrics might be used to drive various design choices, or further investigation.

The author divides the metrics into two sections, the first focusing on metrics related to estimating and sizing, or project planning. The second set focuses on design metrics related to code. The metrics that emphasise estimation piqued my interest as a reflection on how estimation methods used to be run, or maybe in some places still are run such as Developer Days per Line of Code, or his suggestion on Developer Days per Public Responsibility. I think the second set proved more relevant to me.

The author shares some of his preferred metrics thresholds and, they too, resonate strongly with my own views of size of methods, number of instance variables in classes, etc. In fact, I’d almost say they were definitely much more extreme such as 6 message sends per method, with my preferred number between 5-10 depending on the team I’m working with. Part of this, something that the author emphasises, is also heavily influenced by the programming language of choice.

Few of the metrics talked about were new to me, having made use of tools like Checkstyle and PMD, although I found he used several I’ve not really tracked such as number of classes thrown away, number of times a class is reused and the number of times a class is touched, something I’d like to ponder on a lot more. One metric I’ve also never considered collecting or tracking is number of problems or errors reported by class/module though I suspect the overhead in tracking this may outweigh the benefit it brings because it’s much harder to automate this.

His emphasis on the influencing factors on code metrics also got me reflecting on my own experiences, once again strongly resonating with my own experiences. His mentioning of key classes resonate with the domain model described in Eric Evans’ Domain Driven Design. I would also anecdotally agree that the type of UI heavily influences the number of supporting classes with technical interfaces (i.e. APIs) requiring less classes than rich GUIs. I like a lot of the distribution graphs he uses and will definitely consider using these in the future.

I’d highly recommend this book if you’ve never really sat down and thought about using code metrics on your projects. It’s got me thinking about a number of other interesting side projects about visualisation and further feedback loops on projects.

Freedom from Command and Control

August 30, 2010 / / 0 Comments

We’re fortunate to be having John Seddon keynote at our internal conference in a few weeks so I wanted to read some of his material in advance. I bought the Freedom From Command and Control book out of interest to see how he applied systems thinking to the service industry.

Depending on what your background reading has been, it may or may not be heavy going. I really appreciated the background I’d done in reading about lean thinking, systems thinking and other respects so I found most of my interest seeing how he viewed the application of these tools, rather than the description of the tools themselves.

Despite some warnings from a number of people, I found the book easy to digest – made all the more entertaining by the repetitive (in a good way) and controversial statements thrown in the book. I figure Seddon wrote them in to intentionally jar your traditional manager into thinking differently.

My biggest takeaways follow:

Stop creating failure demand – Lean thinking looks towards the end-to-end flow of value – starting from customer demand. Seddon articulates on focusing on the idea of shaping the demand and service organisations often get to choose what sort of demand they have (to a degree). More often than not, organisations instead flex their capacity to meet all demand – not really spending the time to think about whether or the demand they have is what they want or not.

For me, this links into another view such that organisations need to address bigger root causes, improving quality and experience for customers to stop generating failure demand. I see these ideas equally apply in a software context – many of the practices we adopt is intended to build quality in from the start so the development effort can be focused on helping the flow of business ideas, rather than spending time on fixing “defects” for customers that should not have reached them in the first place. Similarly, properly addressing user experience early enough will help to prevent failure demand.

Reaffirmation that arbitrary targets are bad – Seddon isn’t fearful to state his view around the idea that setting targets are bad – in that, you get what you measure and the targets are often not really related to the purpose of the system. This seems to sit well with the discoveries of the Beyond Budgeting Movement who’ve realised you cannot use the same instruments for measurement, planning and setting goals (decouple them!)

I found interestingly Seddon still explain to people the importance of measurement, just not arbitrary ones that managemet set and then create systems around.

Using Capability Charts to map demands – Seddon describes the capability chart as a way to visualise the way demand is being generated. Its focus on visualisation is a way of helping people to see natural fluctuations in a system and a way of identified trends not easily seen when boiled down to a matrix of numbers.

Book Review: Agile Coaching

May 4, 2010 / / 2 Comments

It’s about time I got around to reading the whole Agile Coaching book by Rachel Davies and Liz Sedley. I’ve owned it for at least six months now but has sat with a number of other books that demanded my attention. Fortunately long flights (like back to Australia) give you lots of time to pass with books to read. I’m glad I finally got around to reading it as well. The short version: if you’re interested in what agile coaches do, or if you’re working in an agile team, particularly a leadership role, this book is for you.

AgileCoachingBook

When you first open the book, it’s obvious it is a Pragmatic Press book. It jumps straight in with lots of helpful hints for those that want or are currently looking to be an agile coach. It’s broken up into four main areas, with smaller sections revolving around specific agile practices. This also means it’s fairly easy to digest it in smaller pieces (something I probably could have tried) doing the daily commute on the train.

I’ve been fortunate to know Rachel and Liz before and during their book writing. This book really captures the way they work, and great advice in the form of very practical tips for people. I hope that any readers, even without knowing the authors, can tell the wealth of experience both of them bring. I think writing a book on agile coaching is pretty tough. There’s a temptation to focus on the coaching elements alone, or to capture the distilled gotchas around introducing and coaching teams on specific agile practices. This book definitely gets the balance right for those new to coaching agile teams – enough background to the practice with helpful hints (it’s not meant to be a definitive guide on a particular practice) yet framed in a way that would definitely help anyone introducing and encouraging an agile way of working.

There are many other people this book wasn’t written for (more on that later) yet in its form is the best collection of wisdom steeped in experience that I see budding agile coaches benefiting from. I wish I had something like this when I first started out explicitly acting as an agile coach.

Like all the pragmatic books, this one is really easy to read. I think it took me about three hours on the first leg of my flight to finish it. Reading through each of the sections, the authors offer advice and helpful techniques. Many I’ve drawn upon over the years and draw upon often, a few I’ve never used and many that I definitely needed a reminder about using them. In other words, this book contain lots of practical advice that can really work depending on your team and circumstance.

There are many things that I like about this book – including the small personalised stories from both authors, named techniques that will help new coaches remember them better, and a very direct try this and see sort of philosophy that is both pragmatic and living by an agile way of working. I particularly approve of this book being, for the most part, methodology-neutral mentioning a broad spread of practices and principles individual methodologies espouse followed up with many other links to resources, books and references for agile coaches to then follow. I also like the hurdles section (there’s often much more than those listed!) as it hopefully prepares agile coaches for what happens when things don’t go to plan (almost always).

This book definitely fills a need – helping new agile coaches work out where to start with lots of advice that can be applied almost immediately. This book is also a useful reminder of tehcniques and a way of filling in some gaps for agile coaches who might have only experienced some of the agile practices and ways of working.

Like all well focused, practical books, part of what makes it so well focused and good are the areas that it leaves out (something I’m sure will be filled by other books to come). Some of these topics include:

  • Setting up an agile coaching gig right (when they perhaps need something broader than agile coaching) – it’s no panacea for all organisational problems and coaching isn’t guaranteed to turn every situation in short timeframes
  • Coaching larger teams or large organisations
  • Coaching distributed teams
  • Helping organisations “go agile”
  • Different types of coaching engagements (full time – to part time)
  • Working with other agile coaches as a team

I’m glad someone got around to putting this book together – and I’m happier knowing that it’s also written by practitioners grounded in plenty of real world experience and a variety of different contexts. To new coaches, many of these apporaches may seem optimisitc or impossible but I know that they’re all tested and can work in the right circumstances. Read this book as a way of starting off and refining your own agile coaching style – don’t view this as a definititve book to agile coaching, and as the authors put it so well at the end of the book – develop yourself continually.

97 Things Every Project Manager Should Know

August 24, 2009 / / 1 Comment

It looks like I have become a published author along with three other ThoughtWorks‘ colleagues (Adrian Wible, Joe Zenevitch, and Anupam Kundu) in the “97 Things Every Software Project Manager Should Know” book.

97 Things Every Project Manager Should Know

I contributed two tips, “Documents as a Means, Not an End” and “You Are Not In Control“.

You can buy it the print or ebook version of the book with a 30% discount via the Orielly.com website, using the code ABF09. Congratulations to all the other contributors to the book, including the author who organised the book, Barbee Davis.

The Black Swan

March 23, 2009 / / 2 Comments

My good colleague Alistair lent me a couple of books that I was finally able to get around to reading on my recent holiday. Fifteen hours travelling on a number of planes gives you plenty of time to read a book! One of the books I finished was The Black Swan. It’s been on my list of books to read so I’m glad that I finally read it.

The contents of the book are juicy, detailed and highly relevant given the state of the current economy. It’s almost a little bit too detailed to the point where I almost found it quite hard to read. The author writes using a very flowery, whimsical style, combining stories and facts to drive home the key idea to the book: Hugely significant events occur in ways that we refuse to acknowledge or be able to cope with.

His stories (sometimes false ones) create pictures and explain historical events where we try to observe data, and attempt to create models to predict the future, yet we never seem to be able to accept a completely unexpected event will eventually come along.

More importantly, he uses the book to describe how these highly improbable events having an unforeseen impact. The author chooses his words carefully to distinguish between those events where one simple random sample (e.g. people’s heights) may not affect an overall sample, but many examples in history change the game.

« Older posts Newer posts »

© 2024 patkua@work

Theme by Anders Noren — Up ↑