Scrum Day Dallas was incredible! I was fortunate enough to attend and spend the whole day learning new things, meeting new software professionals, and having my ideas and experience sharpened by my colleagues from around the US. It was the first time I have felt part of a community of professionals, the concept advocated in the software craftsmanship manifesto and I’m eager to share my experiences.
Scaling Scrum with Ken Schwaber
The day kicked off with a talk by the man himself, Ken Schwaber. Ken talked about their efforts over the past years to figure out how to scale Scrum. As many of you all can attest, large numbers of Scrum teams working on the same product backlog presents a real challenge for an organization. The coordination of multiple product owners, integration efforts, and cross-team dependencies can seriously diminish the overall effectiveness of a large number of Scrum Teams. For more on Scrum.org’s take on tackling the problem of Scaling Scrum, check out the deck Schwaber talked through that morning.
Ken had talked extensively on how Scrum is designed to help an organization identify and address problems rather than it being a “silver bullet” meant as a panacea. After Schwaber’s talk, they opened the floor for questions and I got to ask the following question: “How have you all been able to sell something that doesn’t solve problems but rather just tells you, ‘You’re doing it wrong!'” Ken thought for a minute and responded with this, “Anyone who thinks Scrum will solve their problems is naive beyond belief.” He went on to describe their efforts to gather data proving the validity of processes like the ones Scrum prescribes, but that phrase stuck with me, “…naive beyond belief.” I am constantly uncovering my own naivete as I learn more about teaching and coaching teams to use better Scrum. Occasionally, I’ll fall into the trap of thinking that a better process or a shinier tool will solve a team’s problems when in reality the problem is organizational in nature or in the internal drive of individuals.
Open Spaces with Professional Scrum Trainers
After being inspired and challenged by Schwaber, I stepped into a day of Open Spaces. The concept of an Open Space is a facilitated, ad hoc discussion. The facilitation was managed by Professional Scrum Trainers and the ad hoc discussion was generated by the participants. There was an initial round of topic brainstorming and choosing, then the day progressed with interested participants flowing in and out of the discussions that interested them. At the end of each discussion – each lasted about an hour – one person was tasked with being prepared to give a brief summary of the discussion in a larger forum.
Concurrently with the Open Spaces, more traditional presentations were taking place. I was too enamored by the Open Spaces to participate in any of the talks, but I hear they were wonderful ;).
At the end of the day, we all came together and had a wrap up session. During this session, the folks who agree to summarize the Open Space discussions got up, one by one, and gave their summaries. I was really cool to see the engagement of participants and the ownership they exhibited over their group’s contributions to the Open Space discussion.If you ever get a chance to attend a Scrum Day, YOU SHOULD ABSOLUTELY ATTEND. If you value being part of a community of professionals passionate about Scrum and agility, I have not found one better. The PST had a combination of wisdom and competence I’ve rarely seen and Schwaber’s talks were poignant and practical.I’ll close by some other things Schwaber said that impacted me. Several times he mentioned how lucky we are to be working as software developers. He likened it to getting together with your friends to work on a fun problem; however, the business of software development too often robs us of that joy. I could see him tearing up as he described the joy lost in these kinds of environments. He encouraged us by giving us example after example of companies who get it and who are running circles around the competition as a result of it. The reality he conveyed was one where companies developing software must improve or they will be consumed by their more agile “Scrumpetitors.” Don’t blame him for that terrible pun…that one’s an original ;).