Scrum and the Art of the Obstacle Course

What do you need to get through a complicated, every changing software development project and a Tough Mudder obstacle course?  A great team is a good starting point.

This concept isn’t new.  Ken Schwaber and Mike Beedle talk about it in “Agile Software Development with Scrum.”  They liken building software to running an obstacle course.  “Agility, flexibility and adaptability are required to succeed (p 99).”  They argue that following a set plan won’t get you to the finish line.  It is the art of balancing everyone’s skillsets, collaborating at each step, and openly communicating that allows for software development success.  Schwaber and Beedle further push the point by emphasizing that the team needs to self-organize and lead the efforts.  A manager, project owner, product owner, or other stakeholders can only assist the natural order of the team.

This resonated pretty well against everything that I heard about the Tough Mudder, and similar obstacle course races.  The Tough Mudder started with a 30-something fit men demographic who could probably “brute-force” their way through many of the obstacles.  That demographic has evolved to include 80-somethings and more fun focused teams,  In all cases, it has become less about “brute-force” and more about collaborating on the best solution.  Competitors have challenged Tough Mudder obstacle creators by using obstacles in unanticipated ways.  Like the agile team, a coach is going to be able to provide minimal support during the actual obstacle course.  It is his/her job to prepare the team for the challenge and eliminate hurdles prior to show-time.

Having managed multiple software development projects, this approach seems pretty intuitive.  Each team member knows their strengths, weaknesses and skillsets.  They will also be first to see the challenges.  Therefore, it makes sense for the team to to manage themselves, with a coach to nudge them in the right direction.  This approach requires an incredible amount of trust between team members.  Once this is established there should be a cohesive and collaborative group to overcome the typical challenges in software development.