Agile advice from P&P

Posted by Chris on October 04, 2006

I have been listening to an excellent webcast called “Lessons Learned from the Warroom”:http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032286000&EventCategory=5&culture=en-US&CountryCode=US. It features “Peter Provost”:http://www.peterprovost.org/, “Brian Button”:http://www.agileprogrammer.com/oneagilecoder, “Brad Wilson”:http://www.agileprogrammer.com/dotnetguy and “Darrell Snow”:http://blogs.msdn.com/darrellsnow (all working in the Patterns & Practices group at Microsoft) discussing what they have learned from working by agile methodologies. Among the projects they have worked on following agile principles are the “Enterprise Library”:http://www.gotdotnet.com/codegallery/codegallery.aspx?id=295a464a-6072-4e25-94e2-91be63527327 and the “Composite UI Application Block (CAB)”:http://www.gotdotnet.com/codegallery/codegallery.aspx?id=22f72167-af95-44ce-a6ca-f2eafbf2653c, so they have aquired quite a lot of experience.

If you have not listened to the webcast I definitely recommend you do so, it is filled with great advice. Below are some notes from it, posted here mostly so that I will remember them myself. But I have also added some comment where appropriate.

* Do not forget to do reflection when you are planning. As Peter Provost comments, this is simply following the process since the process tells us to reflect on the past iteration while we are planning the current iteration. But somehow this part is often forgotten. To add to that, you should of course not only reflect while planning the current iteration, reflection should be done as often as possible.
* Manager approval and sponsorship is very important to agile projects. For instance, a common problem is that people are used to being judged by their individual achievements. But agile advocates that the whole team and the results it produce (in particular) is what is important. Therefore it is a manager’s job to make sure that the importance of setting aside your ego and instead working for the team is communicated to everyone.
* One specific area is pair-programming. Developers (who have not tried it) can be reluctant to do it. A similar problem is pairs that never change, e.g. some or all of the pairs are always comprised of the same developers. Peter suggested a pairing chart to help with these issues. List all the names of the developers in a matrix and note down when two developers pair. The goal is to have all the columns in the chart filled. Someone added that a pairing session should not be more than a couple of hours long, spanning a “single coherent logical thought”. After that you should move on to another partner and problem.
* A particularly interesting part (to me) was remote pairing. The P&P team includes a number of consultants that are not present in the warroom at Microsoft at all times. Some of the work was done by people in South America. All the time though people where pairprogramming. They tried a number of different setups, including Skype, VNC and LiveMeeting, similar to what “me and Andrés”:/articles/2005/11/22/distributed-pair-programming/ tried. Although this seems to have worked very well for them, they where also quick to note that when they where actually pairing at the same physical desk theyfelt much more productive and focused.
* The final thing I want to mention was the discussion on how to get people (developers, management, customers etc) interested in working with agile principles. This was interesting since Andrés recently did a presentation with similar ideas called Guerilla Agile at Dotway’s latest competence weekend (actually I ended up presenting his material since he got sick the night before). The most obvious way is to simply show them how well it works. For instance, write your code using TDD even if you are the only one. It should soon be obvious that your code is better. :) When someone presents a design as a diagram, ask if you could state it as a test to document it. Pairprogram whenever you can, soon pairing will be the default instead of the other way round. And my favorite quote from Peter Provost: “If you do not have a warroom, steal one”. Book a conference room for weeks, days, hours or whatever it takes. Share the reservations between the team members, finally management will understand that you really do need a dedicated room.
This is just a small set of all the great advice from the webcast. I hope you are not satisfied with my notes and go listen to the whole thing ASAP.

Trackbacks

Trackbacks are closed.

blog comments powered by Disqus