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.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in Agile. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Good post.

    I like the idea of tracking some artifacts in TFS not least as our users are not on-site, however having to get CALs so that users can read/contribute is ridiculous.

  • Great post!

    The image with arrow and guided missile is simply totally accurate.

  • @Colin

    Does VSTS Web Access help at all? I think I remember each of those users needs a CAL too.

    The main problem we had with persisting stories in VSTS was that they stuck around too long and were difficult to maintain. Stories are supposed to be disposable, and the stickier the medium, the less likely customers will purge unwanted stories.

    Scrum for Team System definitely helped us with our burndown charts, however.

  • Great post. Prior to Telligent I was at a shop that attempted the VSTS love-fest (love that term!) and failed miserably at it. All that work item information became fairly useless as we would often here the “what are you working on” question from our team lead at the end of the day.

    This was after he had just approved the 5-10 work items that we had just sent over to him to approval and he had re-assigned work items at the start of each sprint.

    The information was all supposed to be there for him in VSTS, but the granularity was actually more of a headache for him to manage than getting information from his team.

  • Reminds me of the military-based strategy known as the OODA Loop (http://en.wikipedia.org/wiki/OODA_Loop), which, despite the conincidental acronym, has nothing to do with object-orientation. It stands for Observe, Orient, Decide and Act.

    In your example for the second type of control, the statement “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.” resonated with the core reason that OODA is an effective strategy:

    “The winner of these battles is not necessarily the fellow who makes the best decisions. More often than not, it’s the guy who makes the fastest decisions.”

    “Blue breaks left. Red does too. Both pilots observe, orient, decide, act. But Blue is faster. While Red is still orienting himself, building the situational awareness he needs to decide and plan his action, Blue has already chosen a maneuver and executed it. This renders Red’s previous orientation useless: Blue is no longer where he was a moment before.”

    “Should Blue make a mistake he will observe it before Red can, re-orient himself, make a decision to correct the mistake and commit to the new action all before Red is even aware that Blue has blundered. Red, on the other hand, may be making superior judgments… hell, Red may be making a string of perfect judgments, but that won’t save him because his perfect moves are in response to a situation that no longer exists. He’s doomed.”

    Blue, in this context, would be the developer. Red, the customer’s business goals.

    Granted, the OODA Loop is more suited to a strategy where there is an actively evasive target, but I think it is still somewhat applicable to a passively evasive target, such as the customer’s business goals.

    (quotes from http://www.ejectejecteject.com/)

  • @Troy

    It’s funny how much control-systems metaphors can work when describing software development. Feedback is feedback is feedback.

    “his perfect moves are in response to a situation that no longer exists” – brilliant