Issues Of Software development

I am completely convinced that in today's scenario one or the other "agile" methodology is the way to go. However, whatever you do some common problems appear. Mostly people related. Would it not be wonderful if we did not have to deal with such issues! But there's no way, people have to develop the stuff. I'll basically be discussing about 3 blog posts that look at these issues.

James Shore talks about how software have to be "done done" to be useful. One of the cornerstone of agile delivery is that we attempt to deliver fairly well cooked stuff every release cycle.Problems arise as everybody's sense of closure is widely different. He has a checklist that tells us when it's "done done". A quick look below.

• All unit, integration and customer tests are finished (tested)
• All code written(coded)
• Code refactored to team's satisfaction (designed)
• Software being released is completely integrated UI, database etc. (Integrated)
• Build script includes any new modules (builds)
• Build script includes the story in the automated installer (Installs)
• Build script updates database schema if necessary and installer migrated data when necessary (Migrates)
• Programmers, testers & customers have reviewed the story for bugs and UI glitches (Reviewed)
• All known bugs have been fixed or rescheduled as newer stories (fixed)
• Customers agree that the story is completed (Accepted)

This is really a chapter of his upcoming book "The Art Of Agile Development". Rest of the chapter is devoted to how to fulfill all the above criteria.

The second issue is taken from another blog "perils of pair programming" by Matt Stephens. Pair programming is an essential framework for the extreme programming methodology. When the capabilities of both programmers are nearly matched, pairing works well. But pairing like novice-novice or novice-expert does not work well at all. Even when in novice-expert like pairing the expert is a willing mentor, productivity is likely to suffer. It is a difficult optimization to achieve in general in a team then. Add to that not everybody is inclined to sit with another at the programming terminal and be extrovert enough to make it work. It is difficult to select people by programming orientation, and pick those who are pair-programming oriented!

A third angle tackled in Kelly Waters' blog "what if my Agile colleague won't play ball?". Kelly is an experienced project manager and discusses various ways of dealing with the situation". The essence being counseling first, unlike the team putting in peer pressure to make the misfit leave. Change is phobic to many people and they may not even realize it. Hence the counseling and discussions based approach. Obviously when all else fails, surgery has to be resorted to!!