Even those individuals who have years of experience developing in a Scrum environment might be intimidated by the prospect of serving as a teamsÂ’s ScrumMaster. The breadth of what a ScrumMaster is asked to do for a team is very expansiveÂ—it can range from reminding a team to more closely follow the tenets of Scrum to more hands-on resolution, like replacing a fried CPU. Given how divergent the challenges a ScrumMaster face, itÂ’s helpful to have a guide from an experienced ScrumMaster to make sure the basics are being covered. Below, IÂ’ve included links to two very good guides that will certainly be helpful to any new ScrumMaster.
First off, check out Tirthankar BarariÂ’s Â“Tips for First-time ScrumMastersÂ” on the Scrum Alliance website.
Secondly, take a look at Certified Scrum Trainer Michael JamesÂ’ blog, Â“A ScrumMasterÂ’s Checklist.Â”
There are a lot of blanket statements made about agile from both sides. Proponents say Â“agile is a silver bullet.Â” Detractors decry agile as complete chaos. Of course, neither of those ends of the spectrum are very accurate. But it can take folks a long time to arrive at that realization. Recovering project manager Andrew Makar writes about this experience on a recent article on the Gantthead website, titled Â“Agile Myths Debunked.Â” In it, he recounts how, several years ago, he and a colleague shared a laugh over a vendor championing Â“extreme programming.Â” Now that agile and its engineering practices have grown up quite a bit more, Makar remarks, Â“IÂ’m not laughing anymore.Â”
In the article, he goes on to list four major misconceptions he had about agileÂ—ThereÂ’s no documentation in agile! ThereÂ’s no planning in agile!, etc.Â—and, one by one, explain how heÂ’s seen those myths debunked through real world experience. IÂ’m not sure any experienced agile practitioner will find much here that will surprise them, but thatÂ’s hardly why itÂ’s a good read. Instead, itÂ’s satisfying to step back and consider how far agile methodologies have advanced. Truly, it wasnÂ’t very long ago that these types of criticisms were leveled at agile and, in an article like MakarÂ’s, theyÂ’re held up as evidence of how far our thinking on the topic has come.
What do you think? Have you seen the acceptance of agile methods and techniques grow in acceptance in recent years? Or do you perceive that folks are still clinging to the Â“mythsÂ” Makar outlines?