OC APLN Mtg April 1st - ScrumMaster Anti-Patterns

Join us on April 1st at the Orange County Agile Project Leadership Network for a presentation on ScrumMaster Anti-Patterns.

ScrumMaster Anti-Patterns - Where Does It Go Wrong?

With the ever-growing popularity of Scrum, ScrumMaster has become a de facto role on many agile projects. Yet quite a few ScrumMasters struggle with the role, and a lot of organizations aren't gaining the benefits a ScrumMaster is intended to provide.

For example, do you recognize these anti-patterns? Do you know why they can cause pain?

* My ScrumMaster has never been on a Scrum team (but he took a class).
* My ScrumMaster can't really explain to me why we're using Scrum.
* My ScrumMaster is my manager.
* My ScrumMaster runs our daily status meeting.
* My ScrumMaster is busy writing code.
* My ScrumMaster never goes to lunch with us.

Through more than 4 years as a Certified Scrum Trainer and over 9 years on agile teams, I've spent a lot of time with ScrumMasters and what the role is supposed to be. But I've also seen too many dysfunctional ScrumMasters and how that affects product delivery and costs the business.

In this lively and thought-provoking talk, we'll explore the ScrumMaster role, why teams end up with dysfunctional ScrumMasters and how that hurts agile projects. We'll explore common ScrumMaster anti-patterns, why they occur and how to avoid them. We'll challenge the ScrumMaster role, compare it to other models, and address if agile teams really need a ScrumMaster.

Your Speaker:

Paul Hodgetts has been involved in lean and agile development as a coach, mentor and team member since 1998. He is the founder and CEO of Agile Logic, a local Southern California agile consultancy, and has helped companies like Microsoft, SAP, Cisco, PricewaterhouseCoopers and Kelley Blue Book achieve success with challenging, real-world agile projects

Slides from March Presentation

...on building off-shore teams can be found here. 

Great presentation from Edward Uy & Nikos Ioannou from Kelley Blue Book on how Kelley started their off-shore scrum teams in China and India. Kelley now has approximately 18 teams and 200 scrum users. One principle that permeates what they do is The Five Dysfunctions of a Team, including using facilitated exercises from the Field Guide (separate book).

Good questions regarding apply the principles of the book were asked, such as how do you separate issues that need to be addressed from the actual person and what if there's only one person on the team that ever calls for accountability.

On the off-shore topic, KBB found the biggest improvement when the Scrum Master split user stories along technology tiers, giving someone in India the back-end part of the story, and a developer in Irvine the front-end. This increased communication and commitment to getting the story completed.

Also, KBB believes in having off-shore and on-shore team members visit the other team several times a year, and especially on kick-off of the off-shore effort having the U.S. team go to the other country for 3-4 weeks.

As far as tools, KBB is using VersionOne as their project planning and management tool designed specifically for Agile software development, and SharePoint for collaboration. KBB selected VersionOne over Rally in a selection process, and didn't include ScrumWorks or ThoughtWorks' Mingle because they didn't feel at the time, in 2007, that they were in high enough adoption. One useful discovery was using SharePoint's discussion threads for cross-team capture of agile requirements documentation.

Slides from Agile Architecture Presentation

The slide deck from David Bleeker's February presentation at the Orange County APLN can be found here. Not only did I learn a lot about how to apply iterative, agile approaches to architecture and design, but I especially liked his insight on the role of the software architect and lead developer.

David's recommendation to weave good architectural design while iteratively building an application is to assign an architect to the team. You do this by making the architect the team lead. From a developer perspective, there's no reason that arcthitect shouldn't be knowledgable to do this, but the architect may not want to do this if he is more concerned with position. Otherwise, it would be great for the developers and architect.