Research Roadmap on Agile Methodologies Resumen de las opiniones de expertos

1
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
2
Expertos Consultados

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

3
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.

4
Dave Astels

1. The question of "Agile Contracts" will be very
   useful to research. It is an issue that many of
   us are pondering and working on.
2. The issue of defining metrics to help decide
   which AM is "best" is interesting.
3. 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?
4. 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.
5. 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.
6. Will your research be confined to Europe, will
   you be gathering information (e.g.
   questionnaires, interviews, etc.) globally?

5
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.

6
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.

7
David Parnas

1. 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.
2. 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.

8
Jim Highsmith

1. 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).
2. 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.

9
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.

10
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.

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

12
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.

13
Kent Beck

1. 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.
2. 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.

14
Kent Beck

1. 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.
2. Also, have you talked to Jerzy.Nawrocki_at_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.

15
Laurie Williams

1. 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. 
2. The octopus is very catchy!
3. 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?) 

16
Mary Poppendieck

1. 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.
2. I like the emphasis on research into management
   and particularly project management.
3. 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.

17
Mary Poppendieck

1. 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...)
2. 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.
3. I'm really glad to see research in agile
   methodologies.  It can only help make software
   development a better discipline.

18
Peter Coad

1. 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.
2. 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.