A problem with resources

One classic trait you will find throughout enterprise software development is that people are literally treated as individual resources – to be shared, allocated, etc.

Of course the management has a perfectly reasonable motivation – how else would you maximize gains or lower the cost of while solving multitude of problems that need solving?

There are several underpinning factors that have to be in place for this mentality, but first, let’s examine what it really means:

  • part-time commitments – it’s harder to foresee when any single feature is going to be actually in customer’s hands
  • limited window of opportunity – there’s little or no chance to address bugs or overlooked features
  • no ownership – things to tend to deteriorate when there is no reason to maintain overall consistency by going beyond the immediate feature/scope

If that looks acceptable, we’re done, read no further!

 


 

On the other hand, if that causes a familiar sinking feeling and you totally can imagine the problems down the line, let’s see how organization ends up in this situation:

Well, duh, Waterfall:

Yes, the process calls for Requirements Phase and we can’t let anyone sit on their hands, we gotta keep everyone busy while that happens. The commitments have been made and the corresponding budget has been allocated last year and for 12 months ahead! Besides, we need more people, right now – over there, on that project.

Organization structure:

Centralized leadership that’s expected to maintain technical and domain expertise, project management skills and a charismatic personalty necessary to solve the problems and effectively manage manpower to implement the solutions. These leaders have to be good at everything! And oh, yeah, the leaders will know the best how long something is going to take.

Tradition of partitioning the responsibility: 

Sole but partitioned responsibility is a terrible setup. BA – for requirements, an architect – for the technical stack and “best practices”, a coder – for the immediate feature code (with a potential separate role for a person responsible for deployment infrastructure) and tester – for the quality: “Hey, don’t look at me, my part is done!”

Lack of talent:

It’s been said many times, but you don’t hire top 10%. Nobody does, and while you could bring up the average, see above – “we can’t let anyone sit on their hands”. Besides, they’ll just quit and use their newly acquired skills elsewhere, right? Lack of training in broad problem solving leads to skill set silos.

If you find yourself in an organization with those traits – that’s it, prepare to reap the consequences of treating the individuals as resources, indefinitely: low morale, quality problems, slow and unreliable feature delivery, rotting code base and employee turnover.

 


 

Incidentally, what might fairy-land of Agile have to address this? Optionally mapping to Agile Manifesto

Teams:

Stable units with the broad skill set to solve a problem from the original statement to tested product in customers hands. Own the code and the solution as a whole. Give the team the problem, give them a lot of problems, just line them up and let them finish – one thing at a time.

Figure out the requirements together with the solution (Customer Collaboration):

The requirements are never done, solution team working with the customer (or Problem Stater, to use flavor-independent term) will come up with a better problem statement (or a better problem!) than a BA marinating in his/her own juice. Chances are it will have to be broken down into smaller problems in order to be solvable. In the end you’ll definitely have a better solution.

Decentralized leadership (People and Interactions):

Problem Stater and Impediments Remover are the only two assigned roles (and arguably they are not even on the team), the rest is allowed to emerge within a team any way the team feels best (and the best itself is allowed to be figured out by the team). People tend to stick to and be happier with the commitments they take and estimates they make themselves. We all try to take pride in what we do and self-commitments allow us to do better. All you have to do is position them for success and let them.

Definition of done (Working Software):

Seriously, you can’t even talk about quality unless you defined what it means to be Done. Refactor, keep the consistency or don’t and know you are paying the price the next iteration, but since you own it – it’s yours to pay. Pick the best stack that works for your team and the problem, but make good and deliver.

Iterative delivery (Responding to Change):

Test ideas, change tracks, fail early, develop deeper understanding of your customer (or discover a different customer!). Deliver, make profit, repeat.

Continuous focus on improvement:

Keep asking “what we can do differently, what we can do better?”. Improve skills, tools, processes, artifacts, etc. as matter of course.

 

In the end…

If all you want is a cog, then all you’ll get is a cog. But make a person matter, let people take pride in what they do, let them grow and feel the benefits of their accomplishments and they will stick around to make you a handsome profit.

Advertisements
A problem with resources

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s