We were going around the table at our monthly Project Management Institute (PMI) book club meeting, introducing ourselves. PMI, which is a project and portfolio-management advocacy association, made up of professionals in the field with an in-person group that meets up here in Southern California.
“I’m Ben Rodilitz and I’m currently a ScrumMaster at Dealer.com…” I began. Before I could continue, the gentleman across from me interrupted with, “You can’t build a house using Agile!”
And thus began my quest to chat with other project managers about what exactly Agile/Scrum is and, just as important, what it isn’t. And rather than lecture on the ins and outs of Scrum, I decided to discuss the first year in Dealer.com’s transformation to Agile – which we began in August, 2013 – as an exemplar of successes and challenges that might be encountered during such a transition.
First, a little about my audience. PMI members span the project management landscape. At any given meeting, only half the attendees might be from the software arena. Of the software project management attendees, maybe half of those are even aware of Agile methodologies. Rather than address the main Los Angeles PMI monthly meeting with 80+ attendees, I chose to present to smaller satellite meetings. These are more intimate gatherings (15 to 20 attendees) and are at locations dispersed across the greater LA area. Specifically, I met with the South Bay group in August 2014, Santa Clarita in November 2014, and San Fernando Valley in January 2015. The informality of these settings afforded a better opportunity for give-and-take than there would be in a large-room presentation, so the dialog was always lively.
To give you a taste of what comprised other presentations:
- Dealer.com’s history and culture: Provided as context for success. Dealer.com’s culture of openness, trust, and unfettered communication are excellent predictors of a successful Agile transition. The company’s “all in” commitment to Agile greatly enhanced our positive experience.
- Reasons the company moved away from waterfall’s linear “define, develop, deliver” approach. I highlighted that we never know less about a project than at the beginning of it. Additionally, we want to focus on delivering features and value, rather than focusing solely on tasks. The intent was to add transparency, predictability, and agility in our delivery of products and services to our customers
- A little primer on the main elements of Scrum: 2-week intervals of development work, during which engineering focuses on delivering the product leadership’s top-priority features. And how working code is demonstrated at the end of each 2-week interval. Product leadership can alter their prioritization of features as often as they feel appropriate, and engineering uses whatever the list looks like at the start of a 2-week interval
- How we implemented Scrum: Detailing, again, the all-in nature of our transition and touching on team make up, changes to the physical plant
(Scrum pods), and Scrum processes we use
- Successes: Examples of how our Agile methodology greatly enhanced our ability to accept significant changes in priorities. For instance, the presentation highlighted how we integrated a huge, new, mid-quarter ask into our already-planned work. It also discussed cases where work was reassigned from one team to another with comparative ease. This section also talked about our continuous improvement, touching on retrospectives (a meeting at the end of a sprint to discuss wins and opportunities for improvement), communities of practice, training, and even the revamping of the Howard Street engineering area. For this last point, I provided a picture of teams’ dedicated pods illustrating how we created scrum-specific work spaces.
- Opportunities to Improve: Examples of where we are striving to get better. We touched on quarterly planning, working with remote/non-collocated team members, and metrics
- Next Steps: What we’re looking to implement as we move forward. This section focused on how we intend to modify our Scrum implementation as well as how we handle product- and portfolio-level planning using the Scaled Agile Framework (SAFe), and look at/integrating other methodologies such as Kanban and Lean UX
- Summary: The presentation wraps up with Bryan Landerman’s comment in recapping our first year using Scrum: ”It’s been an exciting year since Dealer.com began our transition to an Agile product development organization. Engineering’s ‘All In’ approach has resulted in both dramatic changes and impressive results. The change required a redesign of our teams, our development processes, and even our work space. As a result, we’re seeing increases in our productivity, predictability, product quality, and team morale”
After a year and a half of heads-down implementing and refining our agile process, it was gratifying to share that journey externally and get overwhelmingly positive feedback. With the PMI groups, it was great to see dyed-in-the-wool waterfall Gantheads “get” the reasons for trying an agile approach with a concrete example of what it looks like when that transition works. The small group format allowed us to tackle some hard questions like “using Scrum, how does leadership know what they’re going to get and when they’ll get it?” It also made it easy to finish up with one-on-one discussions on how those interested could follow up with an eye toward trying scrum at their shops.
Now that we spread the word to potential non-believers, the next presentations were set for true believers – the Southern California scrum/agile community.