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.

Where are all the Women in Technology in DC?

As Co-Chair of the Workforce Development Committee (WFD) of Women in Technology (WIT) for the past 6 months, I have had the pleasure of being introduced to several local companies as part of WIT’s Meet the Company series.  For each of these events, WIT partners with one organization in their facility to showcase, the business, technology and culture.  The hosting organization invites executives to speak to attendees and provides opportunities for attendees to get the know the company, the recruiters and executives.  WFD meets with company representatives before and after the event for planning, setting expectations and lessons learned.  One of the recurring themes of these interactions is women in technology – where are they and how do companies hire them?

According to Women Who Tech, “women account for 32.3% of the IT workforce in Washington DC.” Women in Technology, a non-profit with almost 1000 members and a mission to advance women in technology from the classroom to the boardroom, identifies 22% of members as current holders of technical roles.  I know there are many members who previously held technical roles, but have since moved into more managerial or strategic positions.

So what makes it so hard to deliver women in technology to these companies, at these events?  I don’t think it is the event itself, as the companies are clearly interested in attracting women in IT, and are trying multiple methods, of which the WIT event is only one.  So, what is it about women in tech that makes them so scarce?  Is it that most of these events are in the morning before the workday or in the evening after work, times women are usually with their families?  Is it that women in tech are secure in existing jobs and therefore are not networking as much as they should?