Originally Posted by livexxx

No epics, no themes. No breakdown of tasks and clear understanding of what each module or section should really contain. Lack of an intial Product requirement document. No user stories for each part of the deliverable. Lack of review of previous estimations and subsequent adjustments. No peer reviews of code. Insufficient guidance, probably allowed too much leeway in defintion of critical business requirements. Feature creep by stakeholders and the ever present developer assumption of what was asked for was wrong and so what should be developed is. No wireframes, lack of user voice definitions detailing the objectives.

Primarily a problem experienced with solo and small developer teams that have been allowed to define and deliver to their own timetables and designs.

Also if it is a defined deadline, detail, require and follow up on intermediate milestones. Maintain a daily RAG status (Red, Amber, Green) of each part of the job and also upkeep a RAID log. (Risk, Assumptions, Issues , Dependency) I've run two development teams side by side of 8 members each who were both required to attend 10 minute meetings every single morning to define what they did yesterday, what they will be doing today and what problems or holdbacks are current. It's part of the agile methodology and can work with either 1 member or 20. Also maintain a burn down chart based on initial estimates of each sub-task to identify exactly whenever any part of the process is slipping and address.

Ended up on occasions with delivery ahead of schedule , which was then addressed as the estimates were then still wrong (in a good way) and the estimation process fine tuned so that when it was supposed to be delivered, it was.

Kind of treated it like it was a real job ;)