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.

Have you done Agile is a common interview question these days if you're applying for a position related to software development. A few quick thoughts: When C++ came along many of its features formalized practices that skilled C programmers were using already. For example: encapsulation. Of course C++ introduced many new concepts. Similarly, Agile (however you define it) formalizes some practices that development groups had been using before the term Agile was coined and added more. For example, timeboxing of releases was a common practice at Dolphin (1984-2005). The concept of a daily build was in use at Microsoft as described in the book ShowStopper (Windows NT development). Zero defect milestones were described by Jim McCarthy in The Dynamics of Software Development . Pair programming was around before XP was coined. The point is that Agile builds on the past and many of us have done Pre-Agile in various forms and should use this experience to adapt to Agile in whatever form...

For my Project Management Certificate at Rutgers I read and wrote a summary for Agile Project Management with Scrum by Ken Schwaber. The PMBOK Guide was the curriculum for the certificate course and I wanted to read up on Agile since we'd already been using some Agile-like procedures at Dolphin (1984-2005) developing software for educational publishers. The Project Management Institute (PMI) is in the process of adding an Agile credential and I would bet Agile will start to appear in future PMBOK Guide editions. Here is the book summary: Summary The book provides an overview of Scrum including the roles of project participants and the tools and techniques used. The author then tells a series of stories about successes and failures in organizations where he consulted on Scrum projects. I found the book to be a valuable contrast to the process heavy PMBOK curriculum that is the heart of the Project Management Course. I discuss at the end of this sum...