Flexibility and control

At our recent Headspring .NET Boot Camp, Jeffrey and I had an interesting conversation with a couple of attendees whose company was considering an all-out VSTS love fest.

Already using TFS source control, the company was looking at using the Work Item and Team Build features, specifically to get integration between the two.  Most build systems (including CCNET) note what recent check-ins are included with each build.  The Work Item integration goes one step further, linking persisted Work Items (which could be User Stories, Product Backlog Items, Sprint Backlog Items, etc.) to individual builds and check-ins.

Nearly simultaneously, Jeffrey and I asked: And how are you going to USE that information?  Neither developer could answer, and they had to IM their manager to get an answer.  The reply back was something about compliance, which was definitely not what this VSTS feature was designed to help with.  What was more likely was that this feature was intended to be used to exhort more restrictive control over development, through command-and-control management. 

Check-ins would need to be associated with features, and builds would be checked to see what tasks were worked on and delivered.  Needless to say, the developers weren’t too pleased with the extra burden of keeping up with all this extra information.

The manager had likely fallen under the illusion of rigid control leading to more predictable success.

Two kinds of control

Think of the difference between an arrow and a guided missile.  The arrow is aimed once and released, and accuracy is pretty high for short distances.  Over longer distances, wind pushes the arrow astray, and the original trajectory, no matter how precise initially, becomes irrelevant.

With a guided missile, small or large corrections can be made during flight to ensure the missile hits its target.  The initial aiming doesn’t have to be precise by any means, as long as it’s not pointing at the ground.

In the first example, control is achieved through rigidity, leading to long term inaccuracy.  Taking five minutes to aim an arrow at a target a mile away isn’t going to help me hit the target any easier.

In the second example, control is achieved through flexibility, leading to long term accuracy.  It doesn’t matter how much I aim the missile initially, as I’m likely wasting time.  Instead, through regular feedback and correction, I can change and correct the course to achieve previously unheard of accuracy.

Feedback and accountability

Instead of trying to manage daily tasks, the manager in the example above could have fostered feedback and accountability.  The goal isn’t to have a list of features checked off at the end of six months, it’s to deliver value and achieve the customer’s business goals.

Through regular feedback, the team’s course can be shifted and corrected to aim at the customer’s often moving target.  Through accountability, the team becomes responsible for acting on that feedback and ensuring the missile’s rudders aren’t stuck.

Jeffrey and I suggested the team use the lightest tools possible, story cards, until the need can be proven for more heavy-weight tools.  The team needs to question their process and ceremony, always ensuring that their actions always work towards their stated goals.  Applying rigidity and inflexibility to this system will most surely lead to wild and disappointing misses.