Well Oiled Machine

As a leader, I am always looking at situations to find the lessons that are hiding.  The other day I watched a team of engineers working together and it was inspiring.  Here are some of my observations and commentary.

Over the last several weeks, the team has been working on refactoring some of the code that is deep within the bowels of our infrastructure. There has been no shortage of challenges in making these changes.

The code was refactored with backwards compatibility in mind, but that doesn’t always work out so nicely.  It was decided to only retrofit the systems that were in their domain since they are closer and have more intimate knowledge.  They started out strong, but the challenges started to pile up.

There were issues with namespaces, assembly references and code that was removed that needed to be swapped out.  Once the new assemblies were referenced the scope of the issues started to be clear.  One interesting issue that cropped up was a ghost assembly that was somehow being inserted back into the project.  The problem is that was the one library that is getting ripped out.  I blame NuGet (easy target).

We are big fans of swarming our work, but work like this refactoring didn’t seem to lend it self to a swarm.  For those of you who are not familiar with swarming, it is where the entire team works together on a single work item until it is complete.  We have found that in many situations this works well, but that is a topic for another day.

Back to the inspiration.

I walked out of my office and I notice a huddle around one of the engineers cube.  I was curious so I hung out listening and watching, and I was very impressed.  This team was swarming together to help one of the engineers with their refactoring task.

What I saw was an even playing field.  There were no pretenses of superiority and no egos.  Just four engineers working together to solve a problem.  It was a beautiful thing to see!

All to often I see the game of “it was his code” or “that is her PBI”.  That doesn’t sound very teamish (feel free to use that word) to me.  You maybe thinking that all engineers should work together to deliver business value, right?  Unfortunately that is the exception and not the rule in my experience.

It is not often that I get to see that level of team work within a team.  These engineers are some of the most professional teammates that I have had the pleasure to work with.  The interesting piece is that half of the team members are junior, but they operate as a well oiled machine.  I was inspired by their cohesion around the problem, it was awesome!  I was so inspired, I took a photo (pixelated for security 🙂 ).






Remember this for later:

Teamwork: cooperative or coordinated effort on the part of a group of persons acting together as a team (http://www.dictionary.com/browse/teamwork)

I have always like the idea of team work, but I think over the years my definition has warped.  I work in a scrum environment, where we are divided into teams of around 7-9 members.  By definition, scrum team, we are all working towards a common goal to produce the highest value backlog items each sprint.

We were introduced to the concept of a swarm and some of teams tried it.  They felt that it did help them produce higher quality software faster.  From my perspective, I saw 7-9 people in a room watching one person drive on the projector.  I can’t pass judgement because I was not there as a participant.  I think this can be considered teamwork.

There is another team that also works in a scrum environment, but their team work seems  to be a little different.  I often see them sitting together working in a more XP fashion.  There is no goofing around, just focused work.  They produce high quality work each and every sprint.  This seems to fit the definition of teamwork.

Over the years, the teams that I have been a part of didn’t have the intersections where we would need to work that close.  Even recently I was working on a team, but the work that I was doing was orthogonal at best.  I worked on my backlog items and they worked on theirs.  In reflection, this does not seem to fit the definition of team work.


Fast forward to today and let me talk about the team that I am on now.  On this team there are 3 junior developers and 3 senior developers.  We only have one or two backlog items and we are working them together.

Today , for instance, I had one or two developers at my desk for most of the day.  We were struggling to get the VMWare’s c# libraries working with SSPI.  The remainder of the team split the work and they were at another developers desk working together in the same way.

In some ways I push back,  wanting to be left to solve the problems on my own because this is unfamiliar behavior to me.  Fortunately my friend is very pushy and he is forcing me to engage.

I am also working on including the junior developers as much as I can.  I have always believed that it is the responsibility of the senior members to train and impart good practice on the juniors.  I have not always done it or done it well.  This time I am making it one of my missions.  Fortunately for me, the juniors have a strong work ethic and they are all really smart so my job is a little easier.

I am fortunate to be on a team that is willing to work hard and really drive towards the finish line.  They are teaching me the purpose and value of teamwork.  Thanks SOC!