Having worked predominantly in small companies and teams this is a brain dump of issues and considerations:
- Understand your biggest constraint is the only one that matters. Find it, fix it, then find the next one.
- Only solve problems you actually have.
- Understand what constitutes "Done" for a piece of work.
- Reduce process overhead. A board and cards will probably do. How often do you use the audit trail you might think you need? CI server + tests will probably handle enough of this for you.
- Don't be too rigid with your process. If it doesn't suit then adjust it.
- Mandate quality appropriate to the software at hand (controversial I know!)
- Stakeholders may not always be available. Understand their expectations. You may need to play analyst too. Communicate by frequently demonstrating software or screenshots if you have to. Limit the size and scope of misunderstanding.
- If you are a major stakeholder then get on with it but don't ignore others.
- If stakeholders are always available then great!
- Plan 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 possible/tolerable.
- Avoid multitasking development.
- Talking does not build software. Decide, Do, and Review over a short timeframe.
- Timebox unpredictable tasks if you have an inferior but more deterministic fallback plan.
- Question people if you don't understand.
- Avoid email for in-depth discussions about how something should work. If you have to then try using stories and/or tables to communicate unambiguously then talk it through with a phonecall.
- Adopt industry standard terminology for your domain.
- Understand your development capacity and be honest about what you can achieve.
Okay so that's a long list of things and there's probably more. Feel free to contribute ...
Posts
