Book Review: Leading Agile Teams
Ever since my first exposure to agile development my sophomore year of college, I have been an agile enthusiast – whatever that means. I do not live and breath agile or exhibit a fanboy-like enthusiasm, but the more I read about it the more it makes sense to me. After the initial honeymoon phase I thought I knew it all, at least at an abstract level. I went through a Certified Scrum Master course, learned about Scrum in college, spoke at a conference, and even gave a lecture on Kanban. Agile expert may have been an under statement.
When I picked up Leading Agile Teams and started reading, I thought I would breeze through it. After all, I knew the Scrum artifacts and agile principles. But this book slowed me down – significantly. See I had knowledge of the individual puzzle pieces, but very little experience in implementation. Even though I’m a Scrum Master on a team (custom implementation here), I do not currently have the luxury of years of experience with different organizations that commands some of the greatest Agile thinkers.
Author Doug Rose wrote a straightforward book on the agile mindset. He begins with the why (explaining the history of development with waterfall and why current circumstances deprecate that model), explains the how (different agile artifacts – particularly Scrum), and concludes with the what. Throughout each chapter he utilizes numerous illustrations, personal experience, and cartoonish looking pictures that increase your understanding. Even though I knew much of the content, the personal anecdotes provided insight into organizational behaviors.
Even though it has been weeks since I have read this book, I still remember the following points:
- When you start agile development with your team, put up a post-it board. Software (looking at you JIRA, VersonOne, Rally, etc) can handle stories and workflows, but it cannot beat a physical board. At a psychological level putting up a white board signals to upper management and the team that big changes are coming, and that work will soon revolve around the board. Though our team does not use a post-it note board, just the mere effect of putting up something new that affects behavior struck me as something worth keeping in mind.
- Scrum Masters should be coaches. Yes I know what Scrum Masters should do (enforce Scrum artifacts) but I’ve previously adopted a top-down approach where the Scrum Master should continually tell the team what to do. Oops. While some element of telling will remain in certain circumstances, the principle of Scrum Mastering should help prop the team up, instead of dragging the team behind you. This mentality has affected how I approach certain issues at work (which I will share in coming posts). Suffice to say I know see the team as the one responsible for the work, and have moved to a more supportive role.
- Sprint Demos should be run by the Product Owner. Arguably the weakest area of my scrum understanding, I’ve always seen a demo as a test that the people who took grade themselves. In this case, the developers would showcase their work to the stakeholders. However, Rose pointed out this is not optimal because the product owner can field inevitable questions from the stakeholders, let the developers observe the stakeholders in their environment, and it also helps prevent developers from becoming defensive about their work. We currently do not do sprint demos, but I am hoping to change that in the future.
As I’ll probably say with every book I read and share with you, I learned so much more than I can share here. However, if there is at least one thing I can implement into my life from every book I read, then that book has been a success.
In this case, Leading Agile Teams is worth a read if you are a beginner to agile and looking for a very easy way to understand what the heck everyone is talking about.