Hi, Gwen here again. Just getting back after 4 days at MADCamp. MADCamp is the Chicago-area Drupal conference, with over 300 attendees ranging from folks who work on Drupal core, long time PHP/Drupal developers, themers, site builders, and brand new members of the Drupal community, from folks who work for large Drupal agencies to solo developers and people like me who use Drupal within their company. I went last year, I attended the sessions, talked to a few people, and learned a lot. But this year, I opted to take a couple extra steps outside my comfort zone and deeper into the Drupal community.
First, back in January, I submitted a proposal to do a short session on Views/Views UI, the most popular module outside of Drupal core. It was accepted, so on Friday afternoon, I presented a 20 minute session. While I'm perfectly comfortable speaking at the TIG conference, in front of folks I've known a long time, speaking at a Drupal camp was a definite step outside of normal for me. Second, I participated in my first "non-ILAO" sprint on Sunday. At this stage in my Drupal development, I'm not going to be writing patches for Drupal 8. I don't know everything (or even a lot) at this point and I'm sure there were people in the room way more experienced than me at contributing to Drupal, but I went anyway. And sure enough, I was able to contribute back to Drupal, and learned enough to be able to continue to contribute.
Both of these required a willingness on my part to take an extra step forward, to go beyond what felt safe and comfortable. Successfully using Scrum requires a lot of the same. It's not easy and it's not comfortable. It definitely requires going outside my comfort zone. I was completely in favor of the decision to adopt Scrum when we made it; I'm still in favor of that decision, but it would be misleading to say that it's been perfect and easy. It hasn't.
Adopting Scrum means accepting:
- That everything is in a state of flux. The product backlog is never done. We can get something "done" by our definition and then have to go back and make even more changes after the demo. It can leave you feeling that you aren't getting anywhere.
- That your organizational chaos is going to be much more obvious. We have a part-time team working on this project. There's a lot of days where our daily Scrums read like "I did nothing yesterday and I did nothing today." Part of that is just the roles we have; part of it is all of us have other projects going on. You can't really hide a lack of resources to get work done in a Scrum process with quick turnarounds.
- That conflicts aren't as avoidable. When you have increased communication, conflicts happen. When the product owner wants things that have technical consequences or the tech staff are willing to compromise UX to avoid having to do a bunch of custom work, there's going to be disagreements. When the content managers think our content strategy should be one thing and other team members disagree, there's going to be conflict.
- That it creates new pressures. The team is under pressure every two weeks to deliver our completed stories. When we don't complete our stories, everyone knows. On our last sprint, we completed no stories. We got close on several but ran into technical problems; coupled that with testing late in the sprint and me being off the sprint for a week, nothing got "done" within our definition. It was very difficult for me to have to go tell Teri, our Product Owner, that bit of news.
- That you are going to fail. We get it wrong all the time. We built out "Organizations," then threw it away, started over. Then got stuck finding a way to do one piece and had to go down a completely different path.
But like my experiences at MADcamp, it's totally worth taking the steps. Scrum has allowed us to fix things early in the process before we get to far in, through the feedback loops we have and yes, by failing. It has allowed us to work in a cross-functional group whereas before it was me off doing my thing and the content folks off doing theirs and Teri trying to manage between us. It's allowed us to have conversations now that if we avoided would result in an inferior product, even if those conversations are difficult and uncomfortable at times. But there's still work to do. For me, the hardest part is the unknowns and I have to work on finding ways to accept that we will never have a fully complete product backlog, that we don't know everything about what we are building, and that we are going to screw it up from time to time. Because it's the only way to truly move forward.