Every year I join a group of friends and ride a 100K charity bike ride. This ride takes about 4 hours and has turned into a fun yearly tradition. This year, as I was battling my way up the hills of Chilmark (the ride covers most of Martha’s Vineyard), it occurred to me that there were a lot of similarities between the cycle ride I was a part of, and a Scrum team.
Some of the similarities I came up with were as follows:
Once you know the basics, you can ride a bike a long distance, or participate on a Scrum team. However, having solid training for each makes doing them much easier and more efficient.
Developing a regular cadence is valued in both Scrum and cycling. Going to hard and fast early on can quickly burn you out, making it hard to finish the job.
Buying a Scrum tool doesn’t make you a better Agile organization, just like buying a new carbon-fiber bike doesn’t make you a better, faster rider.
I’m a long distance runner, and not a great cycler. However, riding with my friends, many of whom are serious cyclers, makes me a better rider. As the ride progressed, I rode smoother, tighter and faster. Working on a Scrum team has a similar effect for team members. Knowledge readily spreads to the teammates through frequent communication via daily stand-ups and backlog grooming activities, making them stronger, better engineers.
Due to the fact that the ride occurs mid-Spring, each member of the team arrives with a different level of fitness, depending on how much training we put in on indoor trainers during the long New England winter. As such those of us less capable rely on help from the stronger riders. With cycling, teamwork is core to the effort. Riders work together, take turns leading the group, breaking the wind for the rest of the team, pulling the group, allowing others (slower, tired riders!) to draft behind them. Similarly, Scrum is focused on teamwork and less about solo achievements. Sprints (and thus product releases) can only efficiently succeed if the team works together and arrives at the end together.
There was a strong team commitment to finish the full 100K. During the ride there were several opportunities during the ride to cut it short - to quit early. Additionally, the event offers 2 shorter rides, of 10 and 30 miles. But we, as a team, committed to completing the 100K ride regardless of the weather or any other adversity that came our way. Scrum teams develop a similar strong focus and commitment to delivering potentially shippable product increments and overcoming impediments.
My friends and I had great weather and a fun ride. We reached the 100K mark, the “finish line” together with a team velocity of 17 [mph] story points. I’m looking forward to next year’s ride.
One of my favorite Scrum quotes is “Scrum is like chess.”
Like chess, the “rules” for Scrum are fairly straight forward. But also like chess, Scrum practitioners require continued practice and ongoing learning to be come good.
So why do it? If it is hard to master, why change our development process?
Ken Schwaber, a co-author of the Scrum Guide, sums it up best: “Those who play both games and keep practicing may become very good at playing the games. In the case of chess, they may become Grand Masters. In the case of Scrum, they may become outstanding development organizations, cherished by their customers, loved by their users, and feared by their competitors.”
Being loved by users and feared by competitors would mean that we’re delivering highly desired software products which are generating significant sales growth and, ultimately, more corporate value. This is the state we, as a company, want to achieve, and it is one of the drivers for our transition from Waterfall to Agile.
So what can you do to become better at Scrum?
Being part of a Scrum team and new to Scrum, you are likely devoted near-full time on learning new ways of working as well as actually delivering potentially shippable product every Sprint. But this shouldn’t stop you from allocating some time to digging further into the nuances of Agile software development practices, communication and organizational behavior.
There’s a wealth of information, as well as tons of opinions from many of the great Agile industry experts, on two public Internet groups. The first, and older, is the Yahoo! Group, Scrum Development(http://groups.yahoo.com/group/scrumdevelopment/). The second, a Google Group called Agile Leaders (http://groups.google.com/group/agile-leaders?pli=1) was recently created and also features some lively discussions, often by the same cross-section of folks on the Scrum Development list. By just becoming an observer to these lists you can glean many useful tidbits of information on all aspects of Scrum as well as Agile software development. While these are great resources for every Scrum team member, aspiring ScrumMasters and Product Owners should take particular note of these two valuable resources.
There’s also numerous blogs and webinars that can give you insight to different facets of Scrum. I’d start there before buying too many books (Amazon lists over 300 books for “Scrum” and over 1300 for “Agile”). There are many formal and informal Agile and Scrum gatherings, such as Agile New England (http://www.agilenewengland.org) that regularly host events and meet ups.
And finally, as with any discipline, nothing beats practice coupled with an ongoing desire to learn.