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?
Methodology
To the first point, my answer is: Sure!
A methodology -- which is just a repeated way of stringing practises together -- can help.
Why invent the 'string' (methodology) each time you do something? Just follow the same practises in the same sequences each time.
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:...
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.
Managers
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:
To the first point, my answer is: Sure!
A methodology -- which is just a repeated way of stringing practises together -- can help.
Why invent the 'string' (methodology) each time you do something? Just follow the same practises in the same sequences each time.
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?
- 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.
Managers
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:
- An opening narrative
- A conversation about requirements and approach (to include architecture)
- Peer review by other experts
- Code inspections and commitment to standards
- Rotation of assignments among context to drive broadening
- Reflection and retrospective analysis
Buy them at any online book retailer!
