My Bookshelf

Since I stopped doing value adding work (writing code) and started being an administrative expense (management & process stuff), I have read many work related books. I try to balance between reading fiction and other lighter material and then management books. Originally I was rather strict that reading books that benefit the company should happen during the company time, but I've a bit softened my view on this. It sounds like a cliché, but reading and learning new things is really an investment. So, since I also like reading that stuff, I've given myself permission to read interesting books also during my leisure time. :)

Now I'm dropping the bomb: every management or process book ever written isn't a pearl! That's right. Actually, many really, really aren't worth a read. That's why I'd like to save everyone's time and just list the ones that have somehow made an impression on me.

I start from the one that has maybe made the biggest impact on my thinking: Coaching Agile Teams by Lyssa Adkins. I read this when I had just started as the Chief Scrum Master. I'm still on the voyage, but this book actually started the journey. Well written and worth reading if you want to help teams as an Agile coach.

The second one in the series of really good books that offer something new and neat is Lean Startup by Eric Ries. It doesn't go into the category of coaching, but has given me a lot of nice ideas regarding product development. I think it should be a must read for any Product Owner and could be really thought provoking for any Agile Developer. Some great catches from the book: Minimum Viable Product, experimenting, pivoting and actionable metrics. Just read it! <3

Third one in the series I actually read when again starting in a new role. This one is for Agile managers and is called Management 3.0. It's written by Jurgen Appelo and belongs to the same Mike Cohn signature series as Coaching Agile Teams. (This is not a paid commercial, but I just say that that series has a lot of good books.)

I'm not sure if the ideas are really original, one might even say that they are copied and just put under one cover, but it doesn't matter. Like Scrum combines many useful practices under one easy name and is easy to get a buy-in for, Management 3.0 groups a set of management practices. It's easy and fun to read and I think quite many managers (people who are responsible for the well being of others) should read this book. In most cases people are working in a company voluntarily. They are free to vote with their feet. Especially skillful, talented people. As a manager you should realize this and create an environment where these people enjoy working.

For the rest of the books I won't give such a lengthy description. These are a couple of easy to read books about change management:

• Who Moved My Cheese?
• Our Iceberg is Melting

Then these didn't make it into the top three, but I'm still a big fan of Henrik Kniberg's work:

• Lean from the Trenches: Managing Large-Scale Projects with Kanban
  
• Kanban and Scrum - making the most of both
  
• Scrum and XP from the Trenches
• Lean Mindset: Ask the Right Questions (co-authoring with the Poppendiecks)

This book by Daniel Pink is an excellent introduction to intrinsic motivation:

• Drive

All of the above a books that I could recommend people to read. Of course you should consider what fits your personal needs. 

Finally, a couple of books that I've read, but maybe wouldn't promote that much. If you are the author of these books, I'm sorry. But maybe you can take this as an improvement opportunity. ;)

• Lessons in IT Transformation
• Virtual Team Success: A Practical Guide for Working and Leading from a Distance
• Agile Software Development with Scrum (sorry Ken..)
• Agile Project Management with Scrum (..and once more)

And truthfully, many of these books aren't really in my personal library. But we have them at work and some I've borrowed from the local library. In addition to books you can find plenty of interesting (and free) material online. Blogs and videos are also good ways to stay up to date.

Edit (12/2015): Since the original time I wrote this post I've read a couple of really interesting books. Thinking Fast and Slow by Daniel Kahneman and Rocket Surgery Made Easy by Steven Krug. Both are excellent if you want to understand human behavior better.

Maintenance vs New Development

Blogoverse is awesome! Here everything I say is the truth, because there are no counter arguments. In reality it's not always that easy to get people convinced. :)

I'm giving here an example situation and my opinion for a solution. The readers are more than welcome to offer their opinions and join the discussion.

Our releases are planned in cadence. Teams craft their own objectives which we call simply Release Plans. Then the Release Train Engineer (which is me) gathers those so anyone in the organization can quickly get an idea of what will come most probably is coming out in the next Release. The Release Plan is a list of features and changes to the software that we predict to be ready by the next Release Day.

Now, depending on the magnitude of technical debt, maintenance burden, customer contacts and possible fire-fighting issues, some teams have a lot less capacity for developing new features. It can be that over half of their time is usually spent on something else than new features. Like fixing bugs or refactoring. Taking into account all the facts, that's ok.

Somewhat due to misunderstanding and also because it doesn't feel nice to present an empty Release Plan, the teams urge to have also the maintenance issues in their Release Plan. This would make it easier to communicate why they are not able to create so much new business value. Seeing how some people have failed to understand the difference between Release Plan and what activities the teams are doing during the release period, this seems like a valid point.

But personally I find this to be a dysfunction. I think it's the team's choice anyway how they spend their time. And since we have all the maintenance issues in our Product Backlog, the people who are interested in what's happening in the team's daily work can check the situation there. Or participate in the Sprint Reviews. Or go and have a chat with the team or just look at things are going. There's no lack of transparency, people just need to go and have a look.

I see an analogy between this and the work of individual team members in a Sprint. For me the essence of Agile software development is that we have skilled and disciplined individuals who are the best judges of how to do their work (and spend their time). No-one should be micro-managing them and telling how to do their job. It's an issue of responsibility. And trust. If you are more into waterfall, go get yourself a Project Manager. ;)

But as the Scrum Master is educating and coaching the team, I find myself responsible for educating the organization. Don't worry, I'll do my best. Challenges make life interesting!