In response to my previous post Iterative Development (Part I), and the resulting comments, Peter Stuer made some very interesting remarks:
While each of the agile methodologies in theory stresses ceremony and artifact creation should be in line with the project type, the >culture< flowing out of the agility groups (maybe unintended) emphasizes minimalism in these issues more that "adequateness". For some types of projects and teams, "minimalism" simply won't cut it. E.g. in long running projects with a high team turnover, the “implicitness” of too much knowledge can become a real problem.
I agree. That is one of the reasons I think documentation ought to be regarded a prime deliverable, and no iteration can be considered complete if the documentation isn't up-to-date. This includes documentation of design and code, and of course a good user's manual and maybe a hands-on lab by the time the project is actually delivered to the customer. And, to use Peter's term, the documentation should be adequate for newcomers to the project as well as old hands...
Peter also writes:
Also the organizational structure of the setup in large projects can be an inhibitor. When you are dealing with many partners and subcontractors the contractual setup often confines the “fluidity” of the method. Agility needs trust, which might unfortunately not always be practical to achieve.
I agree with this too. Especially XP stresses the concept of Collective Ownership, which states that everyone's co-responsible for everything, and that everyone should be able to tackle any task -- and should be moved around in the team. MSF doesn't talk about that but the practice in Redmond is that everyone is owner of his or her particular piece of code, and that nobody else touches it.
I prefer the middle ground. I am very much convinced that development teams need both generalists and specialists. Some tasks require a high degree of specialization in order to do them right; one example is database design and optimization. While most developers are surely competent to do a basic database design, and to write stored procedures, a good DBA can do it better and knows how to squeeze more performance out of the system. So I think some roles should be assigned to specialists only, and the project lead or technical lead should be pragmatic about whom gets to play which role.
This leads to a different kind of fluidity and a different type of needed trust. Team members depend on each other, as always, but since everyone's responsibility is confined to what he or she knows best (in case of specialists), not too many people are actually moved around. Team members can actually take ownership of "their" piece of the pie. I think this leads to better end results, and certainly to more accountability.
The Zero-Defect Mindset
So what about Collective Ownership? XP argues that this principle makes sure there are no turf wars within the team. That sounds about right, but I think the same can be achieved by MSF's principle of the Zero-Defect Mindset, which states that every member of the team should strive for maximum quality, and everyone's accountable for their own work (see also what this other ex-Microsoftie, Joel Spolsky, has to say about this).
In practice, developers should make sure that code that contains known defects gets fixed as soon as possible. That is reflected in Smart Development's notion of alternating "new features" and "bug-fixing/optimization" iterations (more on that later), and the notion that no new features should be implemented when there are still known bugs in the system. It doesn't mean code has to be perfect, just that the measured quality of the output should be as high as possible.
Teams whose members all have the Zero-Defect Mindset don't need Collective Ownership.
Corporate Culture
This is a caveat, of course. Introducing an agile methodology, or even basic agile practices, into an organization whose culture isn't compatible with it, is very hard at best. Getting team members to adopt a Zero-Defect Mindset requires that they be open to reflecting about their work, challenging themselves and taking pride in the team and in their own output. Unfortunately, many companies and organizations have a culture where such a mindset or such behavior is not encouraged, and people are not held accountable for the quality of their work.
What are your experiences with corporate culture in such matters?