SidesWays Blog

I've been a fan of Jim McCarthy since I heard a recorded session of his talk at one of the Microsoft developer conferences back in the 90s. The thoughts represented are echoed in Agile practices today. There is a nice set of short videos at: http://www.mccarthyshow.com/the-23-rules-of-thumb/ which are also available on YouTube: http://www.youtube.com/user/McCarthyShow#g/u He also has a recent (Dec 2013) keynote at InfoQ: Culture Hacking http://www.infoq.com/presentations/culture-hacking-singapore Some my selected favorites: Rule 1 - Don't know what you don't know Rule 4 - Don't go dark Rule 5 - Use feature teams Rule 6 - Use Zero Defect Milestones Rule 7 - Don't flip the bozo bit Rule 8 - Beware of a guy in a room Rule 13 - If you build it, it will ship (daily build) Rule 23 - Get the team into ship mode

Regardless of your thoughts about Agile and Waterfall and the amount of process overhead that is appropriate for a project, the PMBOK Guide is an invaluable resource for project management practices that can be adapted to your project. Note that many practices and artifacts fall outside of the areas covered by Agile development processes. For example, project initiation tasks include creation of a project charter and methods for gathering requirements are all covered in the PMBOK Guide. Besides the Project Management Institute, which is the keeper of all things PMBOK, there are many great examples on the web including one from the state of Oregon at: http://www.oregon.gov/DHS/admin/pmo/publications/pmo_templates.shtml With a concise Word document summary of the various templates with links at: http:// www.oregon . gov /DHS/admin/bpm/pmo /docs/PCoE_PMBOK_4TH_EDITION_TEMPLATES. doc

If you're a project manager who came from a programming background it's amazingly helpful to dig back down into code for a day just to remind yourself of how the process really works. Regardless of the approach to project management (Agile, Waterfall, etc.), at the most basic level the development process remains an exercise in code / test / repeat. It's a very satisfying exercise, but it makes you appreciate that there is a lot of detail behind each feature or requirement. It's my belief that the greatest productivity gain for programmers individually is to have as rapid a code / test loop as possible. This is one of the biggest advantages of interpreted script languages (e.g. JavaScript) over compiled languages. There are obvious productivity benefits to being able to see your work quickly and there are psychological/motivation benefits as well.