Research Roadmap on Agile Methodologies Resumen de las opiniones de expertos

Research Roadmap on Agile MethodologiesResumen de las opiniones de expertos Patricio Letelier Departamento de Sistemas Informáticos y Computación Universidad Politécnica de Valencia II Workshop NAME, Madrid, 25 de marzo de 2003

Expertos Consultados • Dave Astels • David Parnas • Jim Highsmith • Martin Fowler • Ron Jeffries • Ken Schwaber • Kent Beck • Laurie Williams • Mary Poppendieck • Peter Coad

Dave Astels • Should Agile Modeling be considered an Agile Methodology? It is a separate thing that can be used in the context of any of the AMs or other non-Agile methodologies. • Beyond the question of whether AMs *are* profitable is how to show that for a given project/situation an AM would or wouldn't be profitable... alternatively.. Can you make a classification system to decide whether an AM would be most profitable? • I think there is some merit to certification for a company or organization (it could be a group within a larger company). For example, if a consulting company claims that they "do" XP (or SCRUM, or FDD, or...) how can a client have confidence that they in fact do. If the client knows the AM in question they can tell, maybe, but if they don't (and I suspect it may be a while before many client do) then there should be some way for them to be secure that they are getting what they expect, and what they are paying for.

… Dave Astels • The question of "Agile Contracts" will be very useful to research. It is an issue that many of us are pondering and working on. • The issue of defining metrics to help decide which AM is "best" is interesting. • Research into distributed Agile projects will be interesting. I suspect there will be some boundaries on the various factors (cultural differences, time zone separation, etc.) Also, what AMs are better amenable to a distributed environment, and why? • Personnel development... My thinking is that development in an AM (I'm thinking especially of XP) will be more of mastery and skill development as opposed to advancement up the hierarchy into management. • I hope that the research on tool support will identify tools that are needed in enough detail that projects could be started to address the need. • Will your research be confined to Europe, will you be gathering information (e.g. questionnaires, interviews, etc.) globally?

David Parnas • I strongly disagree with the opening section of the proposal. The problem of changing requirements was obvious as long ago as the 60s. Almost all of the methods work done then and since that time took into account the need for change and proposed methods that they thought would lead to software that was more easily changed. For example, my well-known papers in the 70s were explicitly aimed at achieving what you would call agility (though we never used that term) but the problems that I addressed were well known ones and others were addressing them as well. It is extremely misleading to suggest, as your paragraph does, that we were not looking for more agile systems. Where that work and the current "Agile" work differ is on how to achieve the flexibility that both strive for. The "classic" work was based on the assumption that to achieve agility one had to invest some time in design before beginning to code. This would result in a structure that would be easier to change than simply coding. The Agile community seems to have given up on the idea of such up front investment feeling (not without justification) that it does not help. They propose skipping the up front stages and will devote all of their time to producing code.

David Parnas Thus, there is a difference in method, not goals. My own view, expressed fairly clearly at the conference where we last met, is that the Agile group has given up too soon. The up front investment has not worked because it is generally very badly done. Where I have seen it well done, it has worked. (I recently viewed a project at Dell which, although it did not do what I would have suggested, did invest in a set of documents that were very clear and well organized and it paid off beautifully. However, such projects are very rare.) • With regard to the heart of the proposal it seems to raise a lot of valid and interesting questions and to propose to investigate them. Since this is not my type of research, I cannot evaluate the proposal in this respect more professionally. I think that Brian Fitzgerald could. I would suggest that you ask for his comments.

… David Parnas • One obvious weakness is that all of the names that I recognize among the researchers are people who are part of the Agile community. If you propose to evaluate the claims of these methods, the group should include both people who are opposed to these methods and people who are as yet undecided. Otherwise the work may appear biased even if it turned out to be objective and sound. In fact, it is very likely to be biased. I think you need to broaden your group to include people from outside the community. A thoughtful reviewer would see this as a weakness if you do not. • I would be no more likely to name a project NAME than I would be to name a folder on a Macintosh "untitled folder". It is simply confusing.

Jim Highsmith • The Management area seems to touch on individual topics, like "project approval," but isn't project approval just one piece of project management? I'd like to see areas like: project management, product management (many of my clients are product companies), portfolio management (where projects get approved and initial processes get established, and contracting (a big deal for many companies). • Alan McCormack of Harvard Business School is making a presentation at the Salt Lake City conference on 3 large studies he has been involved with (Cusamano was involved with one). He might be worth talking to at some time. Also Cutter has done several surveys. There are also a couple of new articles coming out in IEEE Software over the next few months (I've reviewed several). Lots of material to consider.

Martin Fowler • I'll admit I don't know much about the style of these things, so my comments aren't terribly helpful. But it seemed okay to me and I don't have any comments.

Ron Jeffries • I like it. It seems like a worthy effort. Of course, there are many details to be worked out, but laying out the map is a good start. • To me, the phrase "Human Factors" suggests GUI design or the design of software to be easily and effectively used by humans. I might have said "Human Issues" or something. But the meaning is clear from context. • (3.4.1 Design). AMs minimize up front design and design documentation. Many projects experience a need for a more explicit design phase. Can AMs be successfully extended to include design and/or modelling? Is it possible to combine some AM practices with UML in a lightweight way? Is there a role for Interaction Design in AMs and how can they be combined? When/where does refactoring become (re)design? This sounds like a mischaracterization, to me. Agile methods do reduce up front design, but they do not lack design. I would rephrase this topic to make that clear. In addition, I believe there are some very interesting theoretical questions here, hidden in that last sentence.

… Ron Jeffries • (3.5.2 Distributed projects). Are there tools facilitating the use of AMs with distributed development teams? If not, what are their requirements/how can we create them? What are the inherent limitations of distributed projects with regard to agility, even with the best possible tools? What are the implications of these limits for how projects should be undertaken? • In summary, I like the approach very much. Clearly much work remains to be done. This is an excellent starting roadmap. My congratulations to the authors!

Ken Schwaber • I read the NAME research roadmap with interest. I find the octopus to be a good representation for the various aspects, and that most aspects are well represented. I would like you to consider the following two points in considering the octopus and roadmap: • The underlying theory of agile processes is relatively unknown. For instance, we rely on emergence, but no one knows how emergence works, just that it does work, if you arduously prune. I suggest a branch for theory. • The "culture" issue is very significant. Most approaches to software development rely on the deterministic approach encapsulated by the Project Management Institute. This is reflected in the contractual relationship between customers and developers, outsourcing, and every aspect of software development. How to cause this to change is an incredibly vast subject for research.

Kent Beck • What you want is the agile software equivalent of The Machine That Changed the World, the book resulting from an MIT-led study of lean production. TMTCTW took lean production out of the realm of vague, "Sure the Japanese say it's better, but that's just marketing," and threw is squarely in the face of anyone manufacturing. One third the defects, twice the productivity, half the floor space. If in 5 years you could write The Machine That Changed The Virtual World, you would have made a significant contribution. • The biggest hole I see is in engaging business and economics academics. Prof. Zaninotto seemed to understand us very well. If we could engage people from his community, that would enable communicating to a whole new audience. Also, the budgeting, accounting, and tax implications of XP will be significant obstacles to large-scale adoption, and I'd love to see them worked on early.

… Kent Beck • There's also a missing theoretical piece--why do AMs work (assuming you discover that they DO work)? I just read "Linked" by Barabasi, about scale-free networks. I believe software development is a scale-free social network. If so, there are a bunch of fascinating and far-ranging implications that I only just barely glimpse. • Also, have you talked to Jerzy.Nawrocki@put.poznan.pl? I don't know when you can bring Polish researchers into an EU-funded project, but it might be better to do it sooner rather than later.

Laurie Williams • That it is an incredibly extensive and exhaustive list of questions! Wow! So, I felt the need for a plan and a prioritization scheme to work through ALL those questions over the next five years. I'm not sure where that fits into the state of where you are. I was also curious about some kind of summary of September 2002 workshop input by the stakeholders. • The octopus is very catchy! • In the grant proposal that I'm working on with Boehm/Basili, we will also be doing experimental research with agile methodologies. Would it be possible for you to send me a letter briefly explaining NAME (one paragraph) and stating that we plan to work collaboratively on sharing research results and plans? (If you are, indeed, willing to do so?)

Mary Poppendieck • I think it is critical to keep the roadmap agile, as you noted. What we know to be critical issues will change over the duration of the research, for sure. • I like the emphasis on research into management and particularly project management. • I wonder what the difference is between 3.1.1 benefits (which seem to be cost related) and 3.1.9 profitability. I have always had a problem with a fixation on cost - it is often a sub-optimizing measurement. Minimizing cost does NOT necessarily bring the greatest benefit to a business. The one thing you do not want to do is promote the concept that saving money is always a worthy goal in an of itself. Definitely not so. Business leaders know that saving money on advertising, for instance, is often a bad strategy. But somehow they forget that the same concept applies in other areas of a business. So I personally would not separate profitability from benefits, because otherwise you are going to have people looking at isolated 'benefits' which may not be benefits at all when the big picture is taken into account.

… Mary Poppendieck • I would put testing into a category outside of tools - I would put it on the same level as configuration management or maintenance or design or reuse. Tests can substitute for requirements documents. Delivering a test suit along with the code is a possibly the best kind of documentation to deliver with a system, the best approach to long term maintenance, and the best way to support reuse. So it interacts with each of these items - which means it is much more than a tool. (On the other hand - configuration management is a tool...) • I would like to see the issue of database interaction called out somewhere. I think it is a big area that is going to get a lot of attention as agile projects start to get involved with legacy databases. • I'm really glad to see research in agile methodologies. It can only help make software development a better discipline.

Peter Coad • I very much enjoyed the octopus diagrams (similar diagrams are sometimes called "mind maps" over here, a kind of visual notetaking). i am a very (very) visual one, so those diagrams were especially interesting to me. • Randy Miller, a co-author of "a practical guide to extreme programming," works here at borland. he's spearheading the agile movement here. so via e-mail, i'd like now at this time to introduce you two. i think you will find randy a joy to work with. and i think randy will benefit from your work, perhaps even find ways to make your work more visible on a global basis, via the borland developer network, bdn.borland.com.

Research Roadmap on Agile Methodologies Resumen de las opiniones de expertos