The Name Consortium

EuropeEurope, , MarchMarch 200 20033

NAME

The NAME ConsortiumJosé H. Canós, Mike Holcombe, Michele Marchesi, Leon Moonen, Manlio Reisoli, Bernhard Rumpe,

Giancarlo Succi

Research Roadmapon Agile Methodologies

< The NAME Consortium > 2

The Name Consortium

Content

Introduction - Agile methodologies The research agenda The business dimension Management implications Human factors Technical considerations Infrastructure How to answer the questions? Conclusions

< The NAME Consortium > 3

The Name Consortium

Introduction – Agile methodologies

Extreme Programming, also known as XP Dynamic Systems Development Method

(DSDM) SCRUM Feature Driven Development (FDD) Crystal Agile modeling Lean Software Development

< The NAME Consortium > 4

The Name Consortium

Agile manifesto I Our highest priority is to satisfy the

customer through early and continuous delivery of valuable software

Welcome changing requirements, even late in development, Agile processes harness change for the customer’s advantage

Business people and developers must work together daily throughout the project

< The NAME Consortium > 5

The Name Consortium

Agile manifesto II

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale

Build projects around motivated individuals

Give them the environment and support they need, and trust them to get the job done

< The NAME Consortium > 6

The Name Consortium

Agile manifesto III

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation

Working software is the primary measure of progress

< The NAME Consortium > 7

The Name Consortium

Agile manifesto IV

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely

Continuous attention to technical excellence and good design enhances agility

< The NAME Consortium > 8

The Name Consortium

Agile manifesto V

Simplicity -- the art of maximizing the amount of work not done -- is essential

The best architectures, requirements, and designs emerge from self-organizing teams

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly

< The NAME Consortium > 9

The Name Consortium

Issues raised by AMs

This radical departure from the large, design-led, and often bure-aucratic, approaches to software engineering raises questions about feasibility, effectiveness, success,

relevance and cost. These are the main focus for the

research of NAME

< The NAME Consortium > 10

The Name Consortium

Fundamental questions A rigorous evaluation of AMs and their

value in software development will provide a clear framework for planning future software development projects

If being an agile business is vital for success in a dynamic economy then the systems support for the business must also be of an agile nature

The question is: do agile methodologies deliver this?

< The NAME Consortium > 11

The Name Consortium

The research agenda

The research questions can be partitioned into several broad areas Information is required about the efficacy of AMs, how

good they are for different types of projects How senior managers and decision takers can make

decisions about whether to use them What implications do AMs have for the management of

projects? What technical issues are involved in using AMs and

what infrastructure support is appropriate?

< The NAME Consortium > 12

The Name Consortium

The “Agile Octopus” – level 1

< The NAME Consortium > 13

The Name Consortium

The “Agile Octopus” – level 2

< The NAME Consortium > 14

The Name Consortium

The “Agile Octopus” – level 3

< The NAME Consortium > 15

The Name Consortium

The business dimension I How do we measure the benefits and the

costs of using AMs as opposed to traditional approaches?

When faced with a choice of whether to adopt an AM how could a decision be made and on the basis of what data?

There is a need to survey the uses of AMs in a variety of business sectors and try to collect data that would provide insight into this question

< The NAME Consortium > 16

The Name Consortium

The business dimension II

An increasing issue being faced by many software houses is the need to obtain accreditation such as CMM, ISO or industry specific such as Pharma

With stringent regulatory regimes in some industries it is important to understand how AMs fit into this landscape

< The NAME Consortium > 17

The Name Consortium

The business dimension III

Evidence needs to be gathered about the regulatory requirements and whether specific certification of companies using AMs is feasible and desirable

What are the legal implications of adopting an AM? How would AMs fare in terms of Product Liability litigation?

How should potential clients decide if an AM approach is suitable?

< The NAME Consortium > 18

The Name Consortium

The business dimension IV

What are the attitudes of clients towards AMs?

What data would they need in order to make a decision?

How should an AM be chosen What are the main differences between

the various AM-based approaches?

< The NAME Consortium > 19

The Name Consortium

The business dimension V

How should such a methodology be selected and adapted to fit an individual situation?

How can we create a framework for selecting and/or adapting an AM?

What are the critical success factors and the major impediments for the successful introduction of AM into an environment / application domain?

< The NAME Consortium > 20

The Name Consortium

The business dimension VI

How and to what extent can we transfer experience from an AM project to another AM project, taking into account the fact that AM are human intensive?

Can AMs be extended to contexts where they have not been applied previously? For example, is it possible to apply AMs to develop embedded systems?

< The NAME Consortium > 21

The Name Consortium

The business dimension VII

Are there ways to perform some sort of Agile Business Process Modelling for businesses?

How and in what domains do AMs increase profits (efficiency, quality, reliability) for the developers, for their customers?

< The NAME Consortium > 22

The Name Consortium

The business dimension VIII

Can the agile principles be applied in other business contexts?

What is the relationships between AMs and various other development approaches?

< The NAME Consortium > 23

The Name Consortium

Management implications I

AMs will interact with the customer’s administrative process in a different way to traditional projects

Documentation for business purposes such as project approval, budget and financial planning, legal and contractual agreements will have a different role

< The NAME Consortium > 24

The Name Consortium

Management implications II

AMs tend to emphasize a lightweight approach to the productions of documentation, taking the view that all documentation must have a real purpose

The issue of the requirements document is a key one, if the requirements are changing. How can a requirements document be constructed?

< The NAME Consortium > 25

The Name Consortium

Management implications III On the other hand, in a post-Enron world

there is likely to be more emphasis in commissioning companies on due process and clear budgetary approval of a development project

If the outcome of the project is not described in a document such as a requirements document, then will Chief Executives feel vulnerable?

Which kind of documentation is essential, necessary, useful and for what goals?

< The NAME Consortium > 26

The Name Consortium

Management implications IV

AMs talk a lot about customers Who are the customers and where are

they? Essentially the issue is about effective

and continuous communication between the customer company and the development company

< The NAME Consortium > 27

The Name Consortium

Management implications V

How easy is this, what are the problems that make communication of this sort difficult?

Can a remote customer still have excellent communications with developers?

What happens if the representative of the customer changes during the period of the project?

< The NAME Consortium > 28

The Name Consortium

Management implications VI What anxieties do developers/managers

experience introducing AM processes? What on-going information, support

mechanisms etc. do managers need? How can a distributed, agile project be

managed? What are the most effecting ways of

managing teams with unequal knowledge/ capabilities?

< The NAME Consortium > 29

The Name Consortium

Human factors I

What are the cultural perspectives in software development methodologies? Do AMs work better in some cultural settings than in others?

There are claims that AMs give better motivation, better job satisfaction and a better quality of life?

Is there evidence for this? Does this lead to less staff turnover?

< The NAME Consortium > 30

The Name Consortium

Human factors II

What are the training needs of AMs as opposed to traditional techniques?

Do AM customers need training as well as developers?

Are some of the agile practices difficult to adopt?

Are agile methodologies only suitable for the best programmers?

< The NAME Consortium > 31

The Name Consortium

Technical considerations I

AMs minimize up front design and design documentation

Many projects experience a need for a more explicit design phase

Can AM be successfully extended to include design and/or modelling?

< The NAME Consortium > 32

The Name Consortium

Technical considerations II

What effect has the use of AMs during development on the later maintenance of the system?

Is software that was developed using AMs easier to understand/maintain?

< The NAME Consortium > 33

The Name Consortium

Technical considerations III

Do AMs result in more or less code reuse? Can the lightweight AM approach to

documentation help increase code reuse? What is the role of configuration

management in AMs? What is the role of testing in the different

AMs?

< The NAME Consortium > 34

The Name Consortium

Infrastructure I

What are the tools that are really needed in AMs?

Do we need automatic tools supporting all aspects of AMs?

Are there tools facilitating the use of AMs with distributed development teams?

Is it possible to create an integrated tool that can be used for all AMs?

< The NAME Consortium > 35

The Name Consortium

Infrastructure II

What are the metrics that give us useful information about the current status and evolution of an agile development project?

Which kinds of tools, method and techniques are there: i. For measuring testability and improving testability

through refactoring? ii. For adding tests to code that is hard to test? iii. For identifying and dealing with un-testable code?

< The NAME Consortium > 36

The Name Consortium

How to answer the questions?

Qualitative research: case studies, experience reports

Quantitative research: design of experiments, larger collections of data

Both need industrial context: so lets work together

< The NAME Consortium > 37

The Name Consortium

Organizing advance in FAME

Fame dissemination and recruitment of new

potential partners

New FAME Partners

Fame Experience Base

Focused R&D activities

Experiments, pilots, case studies, surveys,

technology transfer, …

Research Roadmap

NAME

Experimental Framework

Programme of jointly executed research

Integrating activities

Activities designed to spread excellence

< The NAME Consortium > 38

The Name Consortium

How we proceed Programme of jointly executed research

on site training, experiments, pilots, case studies, all actuated according to the common guideline of the experience framework

Integrating activities analysis and dissemination of the results for each experiment refine results integrating data from experiment replications identify best practices and metrics validate and refine the experience framework and the

research roadmap Activities designed to spread excellence

publishing articles to the major journals advertising results in conferences and workshops share and exchange knowledge with the partner companies

< The NAME Consortium > 39

The Name Consortium

Conclusions

This programme offers a wide ranging evaluation of what is a rapidly emerging and exciting area of software development, namely the agile methodologies.

Already, good progress has been made in identifying the issues that are of primary interest to a wide consortium of industrial and academic partners

< The NAME Consortium > 40

The Name Consortium

Thank you for your attention

Questions?