People like to rave about Agile or Waterfall or whatever and they love to hate Agile and Waterfall and whatever. Well there are some things that take a little bit of common sense to get done right and software development is one of them.
First I got a list of "do not" items. Then I'll have a list of "do this" items.
Do Not List
- Do not set arbritrary deadlines for a project until full scoping or some type of reasonable expectation the date can be made has been completed by the developers. If you set a date, then continually have to push it back it only increases the negative vibe of the team and creates an environment which will in turn create turnover. Turnover is bad for any software project.
- Do not create specific use cases, business workflows, UML docs, or other docs that are in essence empty and then act like they're fully formed and complete documents. This is a very quick way to erode the enthusiasm of all but the most brazen, determined, and capable software developers (re: What makes a good software developer).
- Do not create an unworkable environment schedule. Never, and I mean never, I've seen this before, but never, not even when hell freezes over even, ever force developers to work an 8-5 schedule. The second you set a time frame they have to come in you've knocked 10-15% off productivity. The two elements of good productivity are developer chosen hours and a good communication and honesty in hours worked, not setting a schedule for someone to meet.
- Do not leave developers without standards unless you want sphagetti code in large volume. No programmer programs the same from day to day, the technologies change, and the development of said individuals changes with personal growth and knowledge.
Do This List
- Do setup guidelines and standards for coding, documentation, and patterns and practices.
- Do setup schedule guidelines based on developer estimates x32 and be flexible within x4 of the estimates. Software development is not a "set engineering process". Even bridge building doesn't always stay according to process and schedule, don't expect something like software development to.
- Do setup a flexibe work schedule with each respective developer so that developers and customers (literaly and figuratively in the sense of "management") can meet and keep communication open and clear.
- Do make clear documentation when needed (which is often) and document the history of the project as well. When documentation is needed it should be had!
