Musings on project management: Scaling down... way down

Sunday, January 12, 2014

Scaling down... way down

Most of the posts I read are about scaling up to ever larger projects, but what about scaling down? What if you are doing bug fixes and small scale projects with just one or two people? Is a methodology of any help, and if you're working with software, can Agile be helpful scaled down?

To the first point, my answer is: Sure! A methodology -- which is just a repeated way of stringing practices together -- can help. Why invent the 'string' (methodology) each time you do something? Just follow the same practices in the same sequences each time. Thus, you can have a methodology for just driving your car... perhaps the ultimate team-of-one.

Re agile and small scale: Really, the agile manifesto does not inherently break down at small scale; nor do the agile principles. It's actually easier to go smaller than to go larger.

But, not so fast! What about:...

Teams and all the stuff about team work if you are only one or two people?
Pair programming?
Redundancy and multifunctionalism?
Collaboration and communication by osmosis with others?

Admittedly, you give up a few things in a team-of-one situation -- perhaps pair programming and redundancy -- but there's no reason to give up the other ideas of agile:

close coordination and collaboration with the customer/user
a focus on satisfying expectation over satisfying specification
quick turn around of usable product
personal commitment and accountability
collaboration with peers and SMEs on a frequent and informal basis
lean thinking
Kanban progression and accountability

The hardest thing to deal with in a too-small team is lack of redundancy -- or not being anti-fragile -- and lack of enough skill and experience to work over a large domain. It's pretty obvious that one person team has a single point failure: when you're away, the team is down. Such a failure mode may not tolerable to others; such a failure mode is obviously fragile, unable to absorb large shock without failing.

And, one person's experience only extends so far... thus limiting the domain and extent of possible solutions (leading, sometimes, to: "if all you have is a hammer, then everything is a nail" misuses and abuses of whatever your skill set is. I once had a person who was a loner and also an expert with MSAccess... no matter the problem, he seemed to solve it with Access!)

As managers we are responsible for making it work. So in the situation of really small teams, there can still be, and we should insist upon: