Development Ideas For Small Companies & Teams

Having worked predominantly in small companies and teams I've collected a few wisdoms along the way.

General

1. Address your biggest constraint, it's the only one that matters. Repeat
2. Solve only problems you actually have
3. Mandate quality appropriate to the software at hand

Communication

1. Take time to understand stakeholders' expectations and availability
2. Establish a regular cadence for stakeholder reviews and other events
3. Frequently demonstrate new functionality, even if incomplete. Limit the potential for misunderstanding
4. Question things you don't understand, however small
5. Avoid email for in-depth discussions. If you must try using stories, tables and mockups to communicate requirements then talk it through over the phone
6. Adopt industry standard terminology for your domain

Process

1. Reduce process overhead. How often do you use the audit trail you might think you need?
2. Prioritise work with a simple familiar system such as a queue. Consider limiting this to a small number of next features. Get enough detail to roughly size the features then analyse them in detail as Just-In-Time as is tolerable
3. Adjust your process to suit you

Planning

1. Don't start until you understand what "finished" means
2. Plan, but don't expect to have thought of everything
3. Timebox unpredictable tasks and have a fallback plan
4. Work on as-few-a concurrent projects as possible
5. Understand your development capacity and be honest about what you can achieve

What advice would you have for someone in a small company or team?

Why be "agile" when effectiveness is what counts?

It struck me today whilst talking to a colleague how the term "Agile" can easily be misunderstood.

Colleague: "Agile is SCRUM, a load of stakeholders get together in a meeting and decide by committee what development will happen the next week"

"Agile" is not just SCRUM or really any other "Agile" methodology; it seems to me more of a loose collection of principles to organise delivery sensibly and allow large companies to operate more like small ones. Agile, SCRUM, Kanban, XP are just methodologies are just tools, and as any DIY enthusiast knows choosing the appropriate tool for the job is paramount in any life or death shelf hanging scenario.

"Agile", in my opinion, has become over-used and under-understood owing mainly to the aspirational nature of the word. We've seen numerous CVs with a heavy sprinkling of "Agile" dust only to find the candidate has little or no understanding of "Agile" development practices. Worth noting it's also a very easy word for agents to substitute in before others such as project, team, architecture. Agile Architecture?!

Effectiveness over "Agile"-ness

The real goal is not to be "Agile", or adopt some set of sacred practices in the hope that this new religion will suffer none of the weaknesses of the old; but discover a software development methodology that works for your team's situation. A good place to start is by learning the principles of Agile methodologies (see The Agile Manifesto and The Twelve Principles), reading a few different books, sharing experiences with people doing it in anger and not just writers or non-practising conference circuit theorists.

If you can understand these principles, and have a broad knowledge of the tools available then you're in a place when you can start to effect change.