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 🙂 ).

IMG_3524

Cheers

 

Is Scrum Agile?

You may think that the title is utterly ridiculous, but bear with me.  I recently had the opportunity to sit through a class with Allen Holub on Designing for Volatility and it was there that he disrupted one of my long held beliefs.  I was trained on Scrum by Ken Schwaber in 2008 and again in 2012, so I was sold but now I am thinking a little different.  I want to explore the question of “Is Scrum Agile“?

Scrum works on a timed boundary that begins with a planning session and ends with a review/retrospective.  These are designed to setup an interval (sprint) where the work is immutable. Typically a team sets an interval boundary of two, three or four week intervals.    If there is a necessary change in the work, it does have an allowance to abort the interval and start over.

Aborting a sprint is a significant decision and activity and is not to be taken lightly.   In this event, the team would stop what they are doing, button up, and start over with a planning session to plan the new work.  This seems to be agile, but…agile  What I see all too often is where we try to make sure we have enough work for the team to work on.  As opposed to make sure that we are delivering the most value to the customer as fast as a quality job can provide.

I believe that trying to find enough items so that each member is busy may start to divert from agile.  If this is your practice, you will inevitable set lower value items higher in the backlog to fill the team’s time.  That seems to stand in the face of the agile principle of delivering the highest value items as fast as possible.

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software” – Agile Manifesto

The team should always be working on the next highest priority items, no exception.  I would guess the question that follows that statement is, “What will the rest of the team members do during the sprint?”  It is a good question to ask, but it is also easy to answer.

In a development cycle, there are many activities that have to take place such as requirement refinement, test case development, test automation and of course development.  Teams can rally around a single item to see it through to the release.  I was very skeptical about swarming around a user story and I assumed it was full of waste, but I have since been proven wrong.

Swarming around the user stories is the optimal activity of a self-organizing team.  If you have a cross functional development team (quality, development and business) then you execute on another one of the principles.

The best architectures, requirements, and designs emerge from self-organizing teams. – Agile Manifesto

Another comparison that is a divergence from agile is the idea of continuous delivery.  The models that I have seen, creates the activity of deployment at the end of a sprint.  This is in opposition to the first principle in the agile manifest.

Our highest priority is to satisfy the customer through early and continuous delivery
of valuable software – Agile Manifesto

Now to be fair, there is nothing in scrum that says you cannot deliver software as often as possible.  The goal of each sprint is to complete a potentially deploy-able increment of software.  At face value,  this end of sprint demarcation promotes deployment at the end instead of when it is ready.

One of the main things that Allen drove home was how agile means that you are always working on the highest priority without the need for artificial boundaries.  I think I agree with that.  Scrum has several ceremonies that occur every sprint and I wonder how many of them are needed in that regimented fashion.

Whether you are moving around backlog items to fill time or you are waiting till the end of the interval to deploy, you have to ask if you are really an agile shop.  The team that I am on is taking a more agile approach.  We are a scrum shop, so we have to operate at some level within that process.  We have only been taking in one work item at a time and we swarm until it is done and then we ask the product owner what is next.    As a self-organizing team, we have decided that this is what allows us to be agile and how we can deliver quality stories to the customer and it works.  This are just my thoughts, but I would love to debate this further.  Cheers