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!!

It's Not Done Until It Is Shippable

James Shore is writing a book on agile methodology "The Art Of Agile Development" and parts of that was being published in his blog. The latest is "Done Done". His point is that whatever is the methodology a piece of software is not "done" until it is shippable. In the sense it has been tested, detectable bugs have been ironed out etc.

Surprising how wide a range of meaning is attached to something being done by individuals. It can really be a huge range of completeness. Some would consider it done when he has finished coding and may be the piece runs, nobody knows if rightly or wrongly. Other end of the spectrum obviously is a tested, tried, polished piece of functionality.

I still remember reading an article on "sense of closure". It was precisely this issue being discussed. I have always maintained with my colleagues that when reporting something being complete the only test one can use is, is it ready to be shipped? Would somebody pay money to buy that piece of functionality. That, of course applies to any kind of product be it software or hardware or a mix of both in the form of embedded product.

SCRUM Works For BBC

I have been looking for evidence to see effective these "agile" methods of software development really are. What the specific religionists say, though honest, are always biased a little in favor of the religion/process they are promoting. I do feel these methods ought to work wonders. The waterfall or any such document/process heavy schemes are not workable they way they are required to.


Here comes a case study that show how BBC has used SCRUM to their great advantage. The story was presented at JAOO. A premier European developer conference on software technology, methods and best practices. The conference presents in-depth presentations and tutorials by researchers, engineers and trend-setters in software engineering and technology.


Andrew Scotland, the presenter, is Head of Development within the BBC's New Media Division. He is a certified SCRUM master and has successfully introduced SCRUM practice into the New Media division's multidisciplinary development teams (Software Engineering, User Experience, Information Architecture, Editorial, Product Management and Project Management).


The Author tells how BBC's New Media division, characterized by a lot of uncertainty and emergent software process, decided to use Scrum to more effectively deliver software amidst all that change and uncertainty. Three years later - the difference is significant, and the journey was worthwhile.

The environment is ever-changing thus it's really good to see Scrum succeeding in a situation it is supposed to work best. I'll need to look around for more such stories.