In his book Agile Reflections, Robert Galen has aggregated multiple articles that he wrote about transitioning to Agile for the online publication PM Times. The book is based on his experience as in Agile coach helping companies in different phases of their transition to Agile software development.
The book deals with five main aspects of Agile adoption: beginnings, execution, customer, mindset and leadership. It articles that discusses many different topics like Agile metrics, team appreciation or focusing on value. Each chapter is easy to read as it mixes in a pleasant way the description of some actual situation met by Robert Galen in his Agile coaching career with considerations on how to solve the general issues presented. You can read this book sequentially or pick the topic the more relevant to your context as each article was published individually.
It is a book that I will recommend to everyone involved in Agile software development or even using a more traditional approach to project management as it provides a lot of interesting “from the trenches” material and thoughts that can be applied in many different contexts.
Reference: Agile Reflections – Musings toward becoming “Seriously Agile” in Software Development, Robert Galen, https://leanpub.com/Agile_Reflections
Quotes
That’s one of the key points I wanted to make in this chapter. The agile methods are deceptively simple and often newbie teams want to go it alone with too little training and little to no initial coaching. In most-all cases I think they’re making a HUGE mistake. Agility is very much of a mentored and experiential approach to software development. You’ll want to engage an experienced coach to help you adopt the basic tactics towards “doing Agile”. But also to help you internalize the core behavior changes at all tiers in your organization towards “being Agile”, so that you truly gain the benefits of adoption to drive business value across your organization.
From what I’ve observed in the professional landscape, it’s that individuals are truly reluctant to ask for any kind of assistance. Is it ego? Is it embarrassment? Is it perfectionism? Is it trust? Is it perception? I believe it’s all of these and more.
One of the first mechanisms that drive value is the Product Backlog – the simple prioritized list that defines what an agile team builds. Every team should be laser focused on prioritizing their backlogs in numerical (1..n) order. There can’t be three or four priority one features – there can be only one; then a two, a three, and so on. Trust me. Your customers and stakeholders will want to play infinite games with priority.
It’s a myth that agile teams figure out architecture “as they go”. Teams should identify the cases where they need architectural or, design look-ahead, in their early backlog grooming efforts of epics. In these cases, the team can either initiate a Sprint #0 to clarify larger areas of ambiguity, or explore prototyping and experiment, OR they can create research / spike stories that allow for that sort of thing on a more finely grained basis. The key point is that these sorts of discussions are healthy and necessary as teams actively guide the emergence of their systems and component designs.