This post originated from an RSS feed registered with .NET Buzz by Darrell Norton. Original Post: Review of Debugging the Development Process by Steve Maguire Feed Title: Darrell Norton's Blog Feed URL: /error.htm?aspxerrorpath=/blogs/darrell.norton/Rss.aspx Feed Description: Agile Software Development: Scrum, XP, et al with .NET Latest .NET Buzz Posts Latest .NET Buzz Posts by Darrell Norton Latest Posts From Darrell Norton's Blog

I had the opportunity to borrow this book from a friend, so I read it over my “currently reading” book. It's a quick read, and the time was well spent.

As I was reading Debugging the Development Process, I realized how much agile practices evolved from solid software development experience like Steve Maguire’s. Look at the foundational practices he puts forth:

• Any work that does not improve the product is potentially misguided
• The lead (or PM) should eliminate any obstacles that keep developers from working on the product
• Find out what the true goal is of any activity, then find the most efficient way to get the value of it
• Establish coding priorities and quality bars to guide the development process

Maguire ended up fixing a lot of projects at Microsoft until the company changed its scheduling process. His methods bear significant influence on what we call agile practices today. For example, fix bugs before writing new code (Test Driven Development), continually improve the process (Scrum), shorten feedback loops (Lean Software Development), and stem process growth (all agile software development). You can easily see how Maguire’s guideline to “implement features only if they are strategic to the product” bears more than a passing resemblance to the strict prioritization of requirements inherent in most agile processes.

One thing Maguire challenges is the idea of the daily meeting. In Scrum, subsequently adapted by most agile processes, there is a short (i.e., 15 minute) meeting to report what each person did yesterday, what they are planning to do today, any problems encountered, and any ideas for improvement. Maguire said that he can get the same information from that meeting without having everyone meet. So how does the team get together to interact? He counters with they should be interacting constantly in their place of work, and if not, take the group out to lunch or something similar. Activities that have no negative connotation with them will usually result in better team interaction.

There is an entire chapter dedicated to “scheduling madness.” The key takeaways are that the PM or lead should never allow the schedule to demoralize the team, yet should be aggressive enough to keep everyone focused. The short iterations in most agile software development processes leave little time, if any, so there is no problem with focus there. Steve also suggested breaking projects into short subprojects (iterations again) and making sure each subproject has an exciting conclusion. I think the agile focus on always creating fully functional software is roughly equivalent.

There’s more to the book, with chapters covering attitudes, improvement, and how to avoid overtime (that would be my favorite!). There is almost no code in this book, but it is definitely a must-read for people that are taking on project-related duties.