Scrum offers minimal guidelines for Agile project management. In his book “The Scrum Field Guide”, Mitch Lacey provides Scrum practitioners with material that should help them improve their Scrum practices. The book is divided in four parts. The first part gives you advice on getting started with Scrum. The second part will help you overcome some of the initial stumbling blocks met by Agile teams and organizations.
The third part of the book deals with some of the larger, deeper issues that companies face, like adding people to projects or fixing dysfunctional daily standup meetings. The final part of “The Scrum Field Guide” presents less discussed topics such as budgeting projects, writing contacts or writing documentation in Scrum projects. You can read this book from start to finish or pick a chapter about a specific issue that you want to solve.
Each chapter of The Scrum Field Guide book starts with a story that put the topic in perspective. It is followed by a discussion on the conceptual aspects. At the end of the chapter, a “Keys to Success” part that summarizes the important content of the chapter and a reference section provides pointers to additional knowledge.
I have particularly appreciated the chapters about the sprint length determination, doing new development and maintenance at the same time or the sprint emergency procedures. The book is easy to read and I will recommend this book to every Agile and Scrum practitioner and every non-Agile practitioner too ;O)
Reference: “The Scrum Field Guide : Practical Advice for your First Year”, Mitch Lacey, Addison-Wesley
Book page: https://www.mitchlacey.com/the-scrum-field-guide/
Quotes
Albert Einstein said, “We can’t solve problems by using the same kind of thinking we used when we created them.” One of the biggest impediments to a successful adoption of Scrum, or any agile method for that matter, is the inability to have a shift in mindset, the inability to use a new way of thinking to solve problems. As a result, Scrum and all agile practices require a certain degree of open mindedness, at least for the first three to six months. When I worked on my first Scrum project, it took nearly a year before I truly understood what Scrum was about.
Whatever technique you use to arrive at your velocity, remember that this number is the epitome of a ball-park estimate. As soon as you have run a sprint, any estimates derived from historical data or blind estimation should be thrown out and replaced with a predictive range based on whatever velocity was attained in your first sprint. As the project progresses, your confidence in your velocity range will increase. Continue to throw out previous estimates and replace them with new ones as you gather more data. Most importantly, communicate with and be transparent to your customers and stakeholders so that they too understand how much confidence they should place in your initial, interim, and later estimates.
Supporting a defunct system while trying to build its replacement is inherently difficult. Whatever approach you choose, the most important thing is to acknowledge that making it work requires a commitment of either time or personnel.
Whether your team is able to choose its own team members or has to take what it gets, returning to normal after a new team member is added is one of the toughest challenges an established team has to face. Sometimes just knowing that temporary pain is to be expected and that there is a route back to a performing state can make the transition quicker and easier for all involved.