As stated in the Agile Manifesto, Agile software development is about “Individuals and interactions”. The importance of having a performing team where individuals collaborate is an essential factor for the success of software development projects. In his “Forming Agile Teams Workbook”, Jesus Mendez provides some tools that offer an alternative-proven way to add more structure, transparency and visibility to formation of Agile teams.
The approach proposed in the book is based on the famous Bruce Tuckman’s group development theory. This model says that team undergoes various stages during their life: Forming, Storming, Norming, Performing, Adjourning. Based on the practical experience of the author, the book proposes tools for the Scrum Master to help teams getting organized and structured, before navigating to the “Storming” stage of the Tuckman’s theory of group development. Adopting Scrum practices is not always easy and this book open the discussion on all the issues that might occur during this stage, with the daily stand-up meeting for instance.
This book is easy to read and well-structured, offering a detailed description of the proposed activities used in team formation. Many tables and figures help also in understanding clearly the proposed concepts. An appendix provides step by step instructions for using the tools and exercises mentioned in the earlier parts of the book. I will recommend this book not only to Scrum Masters and coaches involved in the early stages of Agile projects, but more broadly to every software development (project) manager that wants to improve the cohesion and performance of his teams.
Reference: Forming Agile Teams Workbook, Jesus Mendez, http://www.jesusmendez.ca/books/forming_agile_teams/
A change that requires a lot of effort in time and money which, in my opinion, needs to be supported with a transition plan. But why do we need a plan to transform a team, isn’t it something that’s going to happen in an agile fashion, I mean iteration by iteration? Why should we care about planning changes, when playing the Scrum Master or Agile Coach role? Well in my personal opinion it depends, but I prefer to have a clear understanding about what’s motivating the stakeholders to invest resources in what I’ve called “the team’s transformation project”.
People enjoy engaging in deep technical discussions, especially during the daily sync. That’s cool, but the agile team has the whole day to do that, so let’s keep it light and energized. If you see someone engaging in a deep technical discussion, let it finish, and by the end of the daily sync meeting ask permission to share some observations; by high-lighting how that deep technical discussion contributed to the purpose of the daily sync or whether it did not contribute.
I’ve noticed that by not allowing the development team to present items considered not “Done” that they considered ready to be demonstrated, I was diminishing the power of short development cycles and feedback loops. Also it was causing frustration in the development team up to a point that it was generating a negative impact.
You will have only one unique chance to be part of the forming stage of the team that you’re working with, so make it count. For that, I’ve found myself trying to guide the team’s journey and trying to set my mark by telling them what to do and when. Please don’t do that, instead I would invite you to be flexible and let the team begin their self-direction. Set the example, but open the space for craziness and joy. To make it worthwhile, celebrate different behaviors, laugh together, enjoy the moment and be there for them.