Tuesday 23 December 2014

The Art of Lean Software Development - Interview with Curt Hibbs

 

Preview this book1.  Hi Curt.  Your new book  The Art of Lean Software Development, co-written with Stephen C. Jewett and Mike Sullivan, has just been published.  Can you tell us why you wrote it?

The story, at least in part, is told in the preface of the book. I was having a discussion with a colleague about Lean software development. She knew next to nothing about it and was asking a lot of questions. Finally, she asked "If I could only do one thing, what should that be?"

The answer I gave was "Automated Testing", but I couldn't stop thinking about the motivations for asking such a question in the first place. I finally realized that she really didn't want to spend a lot of time learning and understanding Lean software development, she just wanted to be told what to do.

This attitude fit perfectly with what I knew about the Dreyfus model of skill acquisition. This model states when someone acquires a skill, they pass through five levels of proficiency: Novice, Advanced Beginner, Proficient, and Expert. At each proficiency level the way that they work with that skill changes. Novices want rigid rules and prescriptive advice, while experts discard rules in favor of intuition and tacit knowledge.

Most Lean-Agile books are aimed above the level of Novice, and this presents a entry barrier for many (or at least makes it more difficult).

This book is aimed squarely at the the novice and doesn't require the reader to make a bunch of decisions for which they don't yet have the experience to handle. Instead, we lay out five concrete practices that we present roughly ordered the value they provide for the effort expended (this ordering is our subjective opinion).

I think that this target audience was not previously being served (or at least poorly served).

2.  Can you tell us a little about you and your co-authors backgrounds?  [Feel free to pass this on to your coauthor if you like]

All three of us work for Boeing in St. Louis.

I have been working professionally in software for 36 years. Most of that time I've been an independent consultant or part of a startup. I'm a tech nerd who has always been attracted to the cutting edge, and in 2003 I joined Boeing and started applying my entrepreneurial skills to improving the state of software development in Boeing.

Steve Jewett has is a Boeing lifer who has been with the company for 23 years. He has always been a forward thinking maverick who has pushed for change when change was needed (including being an early adopter of Agile within Boeing). That's why I asked Steve to co-author the book with me.

Mike Sullivan has a university teaching background and joined Boeing in 2005 (I think) where he immediately began introducing Agile practices into his team.

3.  Who is the book's primary audience?  What will they be able to do differently after reading the book?

As I said before, this book is aim squarely at the complete novice. The software developer who has been hearing the buzz about Lean and Agile software development, but know nothing about it. Its for the developer who finally decides its time to do something, but they don't know where to begin.

This book will introduce them to the major concepts, topics, and practices surrounding Lean and Agile development, but without too much depth. With this working knowledge, they should be able to dive more deeply on selected topics of interest (we provide references to allow them to do this).

The will also learn what we consider to be the five most important practices they can used to improve their software development. These practices are ordered roughly be return on effort, and can be implemented one at a time and still realize benefits (of course they are synergistic, so the benefits multiply). Once they have implemented all five practices, they will be doing full on Agile development.

The book finishes off by introducing a variety of common Lean analysis practices and some alternative approaches. This includes things like kaizen, value stream maps, root cause analysis, kanban, ToC, etc.

  4. Why is the book so short?

This is my third book, and they are all short. I guess I write the kind of book that I like to read: short, to the point, without any fluff. I'm too busy for anything else!

[Click to read a sizeable google preview of the book: http://oreilly.com/catalog/9780596517311/preview.html]

No comments:

Post a Comment