thekua.com@work

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.

Comments(0)

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.

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.

Comments(2)

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.

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.

Comments(0)

Liz Sedley and Rachel Davies have just announced the release of their book, Agile Coaching. We really don’t have enough of these books so I’m glad to see one being published.

Comments(2)

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.

Comments(2)

I will confess at the outset of this review that I did not buy the Agile Adoption Patterns book, rather it was sent to me by the author (Amr Elssamadisy) whom I’d met a few years ago at XP2006. I intended for my review to be as independent as possible but wanted any readers to recognise the potential for bias given the context. The history of the book is an interesting one, combining the author’s own experiences with that of many agile practitioners derived from workshops that he ran at many agile/xp conferences over the course of several years. The benefits for the reader is that it captures the lessons learned of a collective crowd from a number of different contexts, something difficult for a single person to achieve on their own. One side effect of this is that the practices are a little self selecting with many of the practices biased towards XP and Scrum practices (and less of those originating from FDD, DSDM or lean).

I ended up reading this book twice before writing this, although the first time I simply flipped through it lightly to get a feel for the book. I remember distinctly thinking, ‘Yet another book on agile practices? Do I really want to spend more time reading through it?’ The second time, with much more time on a train, I’m glad I did as the author spends a lot of effort setting the context for how to go about using the book.

Given the content, I do feel the title of the book slightly misleading as it talks less about patterns in which people successfully (or unsuccessfully) adopted agile as a whole. Though a good book at what it does, I think it would have been better called, “A framework for adopting agile practices” or “Patterns of agile practice adoption” given its emphasis on the practices and less so on the principles behind them. For me, I find it’s important people recognise the difference between practices (good for beginners during the Shu learning phase) and principles and values (better for the Ha and Ri learning phases) and I’m a little disappointed that little of this seemed emphasised. Of course, this book is not targeted at seasoned agile practitioners, so it fits the audience. I think it bothers me that people thinking that adopting practices alone automatically makes them agile especially when you consider sustainable agile in organisations.

Structurally, the author lays the book out well, setting the context and history of the book and the intended audience. Although he mentions it’s not useful for advanced practitioners, I do think there is value as a means of diagnosing smells in practices for teams that already implement the individual practices. To get the most of out, I would recommend they simply jump to the practices they’re using to see if they recognise any signs of the smells described.

I like the format and I do believe this book contains a lot of useful information although suffers from a small set of problems. One of them is that it suffers the same problem many other pattern books do – it’s a great reference over time, yet a little too repetitive to read in one sitting. Another is that I think this is a great reference for people starting, yet leaves a gap about what to do when you get some of the practices implemented. Often I find some practices are great intermediate practices (iterations and time boxing as a way of developing rhythm) yet doesn’t detail what people should do to ensure agile is sustainable in the long term (dropping practices, and developing their own). My only other issue, as minor as it feels, is that the aesthetics of the book feel really dated, with many of the diagrams and the cover feeling like a textbook I would have used for university.

On the plus side, the author presents a simple, clear and step framework for people to follow when looking at a wealth of agile practices. It’s not prescriptive, and gives a balanced perspective by describing the benefits and the possible less desirable side effects of an individual practice and highlighting the impact of wrongly applying a practice in the wrong context. This is a great addition to the large body of literature on agile that will prove useful for early adopters.

Comments(1)

On Wednesday, a whole bunch of IT people descended on McNally Robinson’s bookstore in downtown Calgary to attend the signing of the Thoughtworks Anthology. On a usual week, we’re lucky enough to have two of the contributors in town and unfortunately, one of them, Ian Robinson ended up on a flight from the UK that could have almost taken him all the way to Australia (at least time wise). More fortunately, the other author, Stelios Pantazopoulos (my favourite picture of the night below) made it with plenty of time.

Although I regret being too busy to submit an article, at the time the book was being assembled, it makes me proud to look at the book now and see the breadth and depth of the ideas it contains, and to know that many of my other colleagues share the same level of passion and enthusiasm for really finding more effective ways for IT to work with the business to deliver greater results. It’s wonderful that they can also share this wisdom with the rest of the industry and everyone else benefits from it as well.

Comments(2)

I haven’t lived through as many methodologies that Boehm and Turner have, and as a result, their book offers an insights into what the industry has been through. For those who’ve only worked in an agile manner, it demonstrates some of the drivers of more rigorous process driven methods, and for those who’ve only worked in the latter style, shows what a more lightweight process brings to the table.

They even offer a model for you to assess to what degree you need to blend the two for your particular situation. I appreciate the model is driven through a risk analysis of your current situation, and they even acknowledge, albeit briefly, how you might move your organisation towards more agility or less when needed.

You definitely won’t agree with everything they say, yet don’t let that blind you to other important things they do have to say. For example, straight from the onset, I don’t see agility and discipline as two opposing forces. Perhaps agility and defined process is more appropriate. I also find it hard to believe some of the situations they describe, such as when the developer working in a waterfall style tracks how much time they spend, to the minute, designing, coding, on the phone, in meetings, etc. I think all developers I know struggle with a weekly timesheet, let alone tracking activities down to every minute of every hour.

Summary: Every agilista should read this book to gain a bit more of a balanced view of their world.

Comments(4)

Update (20 Feb): I probably want to add the same disclaimer that I did on the previous post. I highly recommend doing reading on these things and I do want to emphasis that reading will only get you so far, so try to find someone who’s worked with in this way before (i.e. an agile coach) to help you apply all these concepts appropriately.

Building upon the Essential Agile Reading List, here’s the extended one that includes either books that I’ve not read (and have been recommended) or those that help facilitate further understanding or more advanced practices. Buy all of them via Amazon’s Listmania here.

Methodologies and principles

• Crystal Clear: A Human-Powered Methodology for Small Teams by Alistair Cockburn
• Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
• Implementing Lean Software Development: From Concept to Cash by Mary Poppendieck and Tom Poppendieck
• Agile Software Development, Principles, Patterns, and Practices by Robert C. Martin
• Agile Software Development by Alistair Cockburn
• Agile Software Development in the Large: Diving Into the Deep by Jutta Eckstein
• The Art of Agile Development by James Shore
• Organizational Patterns of Agile Software Development by James O. Coplien, and Neil B. Harrison

Additional context

• The Mythical Man-Month: Essays on Software Engineering by Frederick P. Brooks
• Joel on Software: And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity by Joel Spolsky
• Peopleware: Productive Projects and Teams by Tom DeMarco
• Debugging the Development Process: Practical Strategies for Staying Focused, Hitting Ship Dates, and Building Solid Teams by Steve Maguire

Teamwork

• The Five Dysfunctions of a Team: A Leadership Fable by Patrick M. Lencioni

Continuous Improvement

• Project Retrospectives: A Handbook for Team Reviews by Norman L. Kerth
• Accelerating Process Improvement Using Agile Techniques by Deb Jacobs

Project Management

• Agile and Iterative Development: A Manager’s Guide by Craig Larman
• Agile Project Management: Creating Innovative Products by Jim Highsmith
• Manage It!: Your Guide to Modern, Pragmatic Project Management by Johanna Rothman
• Managing Agile Projects by Kevin, J. Aguanno

Requirements and planning

• Software Estimation: Demystifying the Black Art by Steve McConnell

Development practices

• Refactoring to Patterns by Joshua Kerievsky
• Test Driven: Practical TDD and Acceptance TDD for Java Developers by Lasse Koskela
• Practices of an Agile Developer: Working in the Real World by Venkat Subramaniam
• Release It!: Design and Deploy Production-Ready Software by Michael Nygard
• The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt and David Thomas
• Working Effectively with Legacy Code by Michael Feathers
• xUnit Test Patterns: Refactoring Test Code by Gerard Meszaros
• Continuous Integration: Improving Software Quality and Reducing Risk by Paul Duvall, Steve Matyas, and Andrew Glover
• Refactoring Databases: Evolutionary Database Design by Scott W. Ambler, and Pramodkumar J. Sadalage
• Code Complete: A Practical Handbook of Software Construction by Steve McConnell
• Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans
• Pragmatic Project Automation: How to Build, Deploy, and Monitor Java Apps by Mike Clark

Comments(1)

One of the searches that stumbled across my blog was the “Agile Coaching Reading List”. Running the same query returned a huge mish mash of lots of different things so I thought I’d put together my list of essential reads. Of course, simply reading the books won’t mean that you’re an expert (and I suggest working with another coach to develop that) though it’ll definitely help in providing context, advice or skills that you need to practice.

Methodologies and principles

• Extreme Programming Explained by Kent Beck.
• Agile Project Management with SCRUM by Ken Schwaber.
• Lean Software Development by Mary Poppendieck and Tom Poppendieck

Additional context

• Slack by Tom De Marco.

Teamwork

• Collaboration Explained by Jean Tabaka

Continuous improvement

• Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen.

Requirements and planning

• User Stories Applied by Mike Cohn.
• Agile Estimating and Planning by Mike Cohn.

Development practices

• Refactoring by Martin Fowler
• Test Driven Development: By Example by Kent Beck.
• Pair Programming Illuminated by Laurie Williams.

You can easily add all of these books to Amazon from this list here.

Would you recommend anything else? What did I miss? Please leave a comment if you do. I’ll also post the other books I still think are worth reading that didn’t quite make the cut and why.

Comments(11)