In this episode we chat with Ron Lichty, who discovered his passion for technology early on, when he realized that programming in assembly language was easier for him than writing in English. And he knows the difference, because he’s also worked as a journalist and published several books with co-authors. His most recent book, Managing the Unmanageable, is about how effective management can help software engineers achieve the ecstatic state of flow that Ron says coding in a productive environment can produce. We ask Ron about how he gravitated toward management despite his enthusiasm for programming, how and why he took his career from full-time employee to independent consultant, and what his experiences writing with co-authors have taught him about collaboration.
I was very excited to learn that my new book, Scrum: Novice to Ninja, is now available for preorder from Amazon, O’Reilly, and SitePoint. I’ve been working on this book for about six months. I was contacted by the publisher after writing several articles about scrum for their readers. It’s probably the longest nonfiction project that I’ve worked on since I wrote my Masters thesis.
Right now the book is in final edits. I’m working on the preface, creating a mini glossary, and watching as the designer comes up with representations of the sketches I created to illustrate different concepts. I love working with a team, and the process has been magically straightforward.
I wrote the book with the target audience in mind of web developers and mobile developers. I thought the title might reflect that, but the publisher’s including it in a series of other books with a similar titling structure. I don’t think that’ll be a problem.
I’m looking forward to hearing what people think of it. I took a few liberties as I wrote, and I would say that it’s probably not your typical nonfiction book on process management for engineering teams. I’ll let you know as soon as it’s off the presses and in my hands.
I’m having a blast working on my new book about scrum for web and mobile development for SitePoint. I decided to take a slightly offbeat approach to the subject, and incorporate a little fiction into the work.
It’s easy to list out the details of how scrum works, and explain abstractly why it’s such a useful system for supporting web and mobile development teams. It’s something else to make the process come alive for the reader. So I decided to dust off my fiction writing skills and give the team in the book a little color.
I’ve created a set of characters derived broadly from the interactions of engineers, product managers, designers, executives, and others I’ve worked with or coached over the years. I’m trying to show how real people work together, what problems they face, and how they can use the tools of scrum to deal with them.
Scope creep? Covered.
Technical debt? Covered.
Unrealistic expectations? Covered.
So far the editors seem to like what I’m doing.
By showing realistic situations, fears, challenges, and accomplishments, I’m hoping to make the subject more concrete. I also want to address some of the concerns about scrum that I’ve read from people who may have had strong negative experiences.
I truly believe that scrum, properly applied by people who don’t think that it’s either going to magically give them the team they always dreamed of having, or that it is a management plot to steal an engineer’s freedom, can be powerful and effective.
Don’t read yourself into any of the characters; more than the names have been changed….
I was really excited when my publisher, SitePoint, contacted me and asked me to write a book about scrum for mobile and web development teams. I’ve been writing articles about web development and scrum for SitePoint for a little over a year now. And when I did the math, it turned out I have over 10,000 hours of experience leading and participating in scrum engineering teams doing web or mobile development.
What really impressed me was the way the process was structured to make sure the book got written and edited efficiently. SitePoint uses Github to track changes and manage feedback. The entire manuscript is written in markdown and submitted through pull requests for each chapter. Editors for content, copy, and overall project management are assigned at the start, and an agreed schedule breaks down the writing time separately from the revision time.
Writing long-form pieces is always challenging, but a structure like this seems more likely to result in a finished piece and a predictable timeline. Every chunk is clearly defined before starting, and seems do-able.