Everyone is talking about Lean organizations, but what does that mean?

A lot of people think becoming more efficient means minimizing cost and time to market; however, there are other ways to look at it. In the end, the only thing that matters is the ability to measure…

Similar Posts:

• Squeezed Links: July 2009
• Refinance Your Technical Debt Just Like Your Mortgage
• The Correct Process Guides Us (Tracer Architecture Cont.)
• Don’t Unit Test? Start Counting Your “Oh Shits!”
• Adding People To A Late Project Makes It Later

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

As Spiderman once put it, “With great power comes great responsibility”… well unfortunately there are a ton of roles and people that have never heard that phrase because I continually run into people who believe their current position entitles them to bossing people around while providing little value in terms of leadership. I am a huge believer of leading by example and as a result I have modeled my architectural duties around the Tracer Bullet Development tactic.

If you have never hear of tracer bullet development, it was a term coined in the classic The Pragmatic Programmer: From Journeyman to Master. In short, it is very important to trailblaze unknown territory through activities such as mockups, prototyping, and spiking.

However, I sometimes find “architect” level people providing no more worth to their team than a whiteboard full of boxes and arrows and a mouthful of hollow words of encouragement (sarcastic quotes explained). What teams need is clear direction on a clear path.

If what I just said wasn’t clear enough, let me be more blunt – whiteboarding and diagramming are the lowest forms of architecture and they provide the least amount of worth. I realize that I will receive some comment on how in their company is special and creating BUFD UML diagrams is key, blah blah blah. The point I am trying to make is, these activities 99% of the time are nothing more than echoes of the obvious – as a leader it is your responsibility to give direction to the non-obvious!

For example, the current project I am on we need to provide a very rich search capability. As an architect you could really suck and throw some buzzwords at your developer and send them on their way. You could suck less by throwing a couple of real technologies to a developer to give them a launching point for research, but more than likely you are delegating a very important architectural decision to someone who is not veteran enough to make the correct choice. The final option is, you do your job and lead by example by researching the alternatives yourself, picking the path, creating a prototype to validate your hypothesis, and then hand it off with a pre-cleared path.

In order to become a trailblazer, you have to blaze trails. Good architects do not blaze trails with their bossyness and whiteboard markers, instead good architects do it with their intelligence, code, and ability to communicate.

PS – Here are a few more tracer bullet resources, here and here.

Similar Posts:

• The Correct Process Guides Us (Tracer Architecture Cont.)
• Burning Down the Architect Title
• What Your Dog Can Teach You About Building Teams
• Do Managers Prey on Developer Pride?
• Book Review: Agile Retrospectives

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

Something that never ceases to humor me is how managers still believe that scaling people on a project will increase the productivity by an equal proportion. We all know the old saying, “You can’t make a baby in a month by getting nine women pregnant”, but the question is why do we still practice this bad habit? Is it because we do not recognize the the law of diminishing returns when it occurs?

I have talked about Brook’s Law before and that adding people to a late project makes it later, so as not to repeat myself I want to look at this from a different perspective and instead of telling how to avoid it, ask the question why this phenomenon slows efficiency and creates a Claustrophobic Team.

Claustrophobic people show anxiety and panic when they fell they are being locked in or their personal space is encroached; however, this encroachment can happen at many different levels on an overly staffed team:

Intellectual Space Encroachment

The DBA doesn’t want anyone else to touch the database without 7 written forms of consent because that is his job and space. The project manager who wants you to call every time you need to use the restroom. The client who does not want to be told a more productive process work flow.

We have all been on a team where people like to protect their intellectual sandbox. We fence these spaces primarily out of:

• Fear of not being needed or under utilized
• Ego and the need to be important
• Self esteem and the need to be appreciated

Everyone wants to stay busy and when people stack up on each other intellectual boundaries tend to be less respected and therefore encroached. As long as the work is getting completed in any one sphere attempt to respect the roles of individuals even if they do create a slight inefficiency as the inefficiency of having them work against you is greater.

Virtual Work Space Encroachment

For the software developer, you can read – code.

I have always had the belief that collective code ownership is just as a dangerous extreme as team silos. There is always some level of expertise in particular areas of the application and thus pseudo ownership, buy anyways I digress…

To many people working in the same area of the application can create a huge amount of churn. This overhead can be as simple as extra communication or complex as continuous code merging. Two people working in the same class file is a headache, three people working in the same file is just mayhem.

Especially in environments where intellectual thought is being transcribed, people need a few degrees of freedom in which to explore and modify. Unless you are pair programming, having more than one person work at a time on the same section of an application may start to become disastrous.

Physical Space Encroachment

Whether you realize it or not physical space encroachment happens a lot in claustrophobic teams. Just because you still have your desk and the office hasn’t become “standing room only”, does not mean that you aren’t feeling the pressures of encroached personal space:

• Increased communication means more people interrupting you whether through email or a face-to-face chat
• Kanban boards (and online issue trackers alike) become overloaded, hard to navigate, and harder to interrupt visibility
• Offices can become more densely populated when consultants or other workers come in to aid.

So what is the answer to all of this? Well, I am going to be very cliche and say – it depends.

Different businesses, teams, and people all have different thresholds of team claustrophobia and need to be dealt with accordingly. However, it is the responsibility of the team lead to recognize the symptoms of an overly staffed team and realign project expectations while not moving more people.

Similar Posts:

• Frustrated With Coworkers? The Clue You Don’t Want To Hear…
• Adding People To A Late Project Makes It Later
• The 3 L’s Towards Loving The Code We Hate
• Your New Process (Some Assembly Required)
• When Everybody’s Responsibility Becomes Nobody’s Responsibility

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

Agile and Scrum has done a horrible and irreversible injustice on software culture with it’s term – Product Owner.

The definition of Product Owner straight from Mountain Goat:

The Product Owner (typically someone from a Marketing role or a key user in internal development) prioritizes the Product Backlog.

Scrrrreech. Repeat that? Don’t see the problem yet? There are really two pieces here, so let me explain.

The first flaw is in the semantics of the word – owner.

owner: to have or hold as one’s own; possess – Dictionary.com

In short, we have mislabeled this role to begin with. The person who “owns” the product (i.e. the business, a CEO, or in Mountain Goat’s definition some Marketing role) is more appropriately the person who has financially paid for and owns all legal rights to the software. I would wager that 99% of software projects are not consumed by the legal owner of the end product, but by a subordinate.

This leads me directly to my next point [that I find it ironic] the term Product Owner has become synonymous with the role of being the person who is responsible for the delivery of the product. In most cases, this is the true legal owner (or someone who is very accountable for the time and money spent).

So here is the big question: Product Owners are not responsible for the long-term care and usage of it, so why are they in charge of the delivery of it?

Contextually, it is absolutely no different than a father who test drove, purchased, and owns a car he bought for his child with only a small amount of verbal input. From a salesman perspective, I want to know what the father says, but as an engineer I want to know what the child wants! Adding salt to the wound, we now have processes centered around a social antipattern which are appropriately mislabeled.

In all reality, I know we will never be able to break the habit of the people accountable for the project budget wanting to be involved in the process. They need to receive a false sense of assurance that the software will delivered and they will get what they paid for. However, I do believe by correctly labeling the most active role to something more representative of the person we want to engage in a meaningful client relationship with, we can reverse the trend of placing so much emphasis on the “when” and more on the “what” and for “who”.

Similar Posts:

• Is Product Splintering The Future Of Software?
• Customer Polarizing – Why Microsoft Will Always Be A Mediocre Giant
• 7 Ways To Piss Me Off and Not Buy Your Software
• Estimation Is Not For Accountability (It’s For Visibility)
• Extra Squeezed Links: July 2007

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.