Lecture Software process improvement: Lesson 31 - Dr. Ghulam Ahmad Farrukh

Lecture Software process improvement: Lesson 31 provide students with knowledge about: agile software process; adaptive software development; extreme programming; feature-driven development; SCRUM; agile modeling; crystal; the agile manifesto;... Please refer to the detailed content of the lecture!

Lecture # 31

• The development guidelines stress delivery over analysis and design (although these 

activities are not discouraged), and active and continuous communication between 

developers and customers

• Two key features of these development 

methods are

– They accept that change will occur – changes in  requirements and changes in technology; they  therefore adopt a more ‘adaptive’ or iterative 

approach to planning

Agile Software Process

• One consequence of both of these is that 

they tend to create less documentation than conventional methods – it is not that they 

don’t value documentation – just that they actively avoid creating it for its own sake

• Proponents of agile methods have published 

a ‘Manifesto for Agile Software 

Development’

6

The Agile Manifesto

individuals and interactions  over process and tools

working software over comprehensive documentation

customer collaboration over contract negotiation

responding to change over following a plan

That is, while there is value in items on the right,

we value the items on the left more

• Note that they do state that there is value in the items on the right

• The Agile Manifesto is based on the 

following twelve principles:

Agile Principles

10

• Build projects around motivated 

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

12

• 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

Agile Principles ­ 4

• 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

• Simplicity­­the art of maximizing the 

amount of work not done­­is essential 14

particular is based on a matrix of methods 

depending on the size and criticality of the 

• As a general principle, most agile methods focus on issues such as overall approaches 

to programming, testing, documentation, 

planning and team interaction, rather than the details of, for example, how you carry out your configuration management

– Accept that the real world (from which your 

requirements arise) does change, and manage that  change

– Don’t try to be more rigorous than the situation 

• Software process improvement has been 

practiced for over two decades, but picked 

up after the introduction of CMM­SW and later many model based methods for 

software process improvement were 

introduced

20

• The ‘manifesto’ is certainly intended as a counter­blast to, for example, the higher 

‘maturity levels’ of CMM/CMMI

• But for serious professionals concerned 

with efficient system development, 

responding to customer needs, and 

• It is also worth noting that reaching CMMI capability level 4 or 5 for a process area is conceptually feasible but may not be 

economical except, perhaps, in situations 

where the product domain has become very stable for an extended period of time

• How many of us work in such a product 

domain?

22

• ISO 9001:2000 requires that an 

“organization shall continually improve the effectiveness of the quality management 

system through the use of quality policy, 

quality objectives, audit results, analysis of data, corrective and preventive actions and 

• It would therefore appear that agile methods are entirely consistent with process 

improvement, both in general, and as 

interpreted by ISO 9001:2000/2008

24

Improvement

28

Improvement

• Process improvement should be carried out 

in an agile manner to an iterative life cycle, taking full account of the way in which 

people actually work, and taking care to 

work closely with the people at the 

programming shop

Agility Applied to Process 

Improvement

• One of the principles which ‘agile process improvement’ may need to challenge is the inexorable (unyielding/unalterable) link 

between measurement and process 

improvement

• We should see quantitative data as a 

valuable bonus for process improvement, rather than an absolute prerequisite

30

Improvement

• New software development technology is still appearing at an astounding rate

• Some of it is self­evidently good

• Some of it doomed to the annals of 

interesting (or less interesting) culs­de­sac (dead end streets)

Agility Applied to Process 

Improvement

• We should adopt the following approach to process improvement

– If people believe something needs doing, then 

do it

– If something looks like a  good approach, then  try it

– If you can cost­effectively collect data to 

support your process improvement activities,  then so much the better,  but don’t hold your 

– If your new approach requires spending lots of  money, then of course you will need to justify 

it, but make sure that by ‘lots of money’ you  really mean lots of money ­ $1,000 on a 

$5,000,000 project is not ‘lots of money’.  Be  (informally) quantitative and logical about 

deciding whether to be (formally) quantitative

– Estimating is an area which is by definition 

quantitative, and you can’t get away from the  fact that people like to know in advance how  much you’re asking them to spend.  Don’t  use  this section as a justification for avoiding 

methodical approaches to estimating

34

• The messages of agile methods are:

– While we value and use processes and tools, we  should not allow them to deter us from talking 

to our customers and users

– We should never forget that working (and 

usually, maintainable) software is the key 

36

• Engineering professionalism should not 

prevent us from having good relationships with  our users and customers and responding to 

their needs

• Some of you will see all of this as the thin end 

of the wedge, working inexorably to separate 

• An agile approach to SPI would be 

responsive and flexible to local needs, 

encourage innovation in the process, build SPI projects around those who are 

motivated, encourage self­organizing 

competent teams, and promote sustainable development of the processes

38

• The following figure conceptualizes the 

features considered necessary to support an agile approach to SPI

Following slide to be inserted

A Model of an Agile SPI Method

40

SPI Coordination

• Improvement in process management is ‘a continuous effort to design an efficacious process by understanding the relationship between process configurations and process outcomes and embedding the knowledge in the process through routines and formal 

process definitions’

42

SPI Program – 1

• Changes must be aligned with business 

strategy and priorities should be based on the business context

• Commitment to improve and investment 

required

• Must come from top

• The results of the SPI should be monitored

44

• Explicitly moving away from a software 

process philosophy of stability to one that is adaptive and flexible to local concerns will encourage a change in the actor’s 

intentions, as the norms of the organization will change from remaining consistent to 

• This is not to suggest that methodologies or process life­cycles should be abandoned, 

rather the aim should be to produce a 

successful product rather than following a pre­defined methodology at all costs

• The objective is not change for its own 

sake, as there is a need to balance between optimizing the current approaches and 

48

• To support the learning and innovation 

activity, the SPI initiative can be supported through a suitable infrastructure 

• The SEI view of setting up process action teams under the software engineering 

process group (SEPG) is a model that can 

• Rather than the SEPG being the sole 

identifiers of process areas that need to be introduced, they could act as a facilitating group. By supporting through training, 

• One way to improve the relevance of the 

SPI activity is to align it with the emergent business strategy

• Both planned and improvised 

improvements could be coordinated to 

focus upon the areas that are expected to be important to the business to engender a 

sense of purpose over the longer term

52

• A final point: whilst good processes are 

fundamental to success in the software 

business, good people will bring their own processes with them, and can therefore 

produce good work in an ‘immature’ 

organization

Summary

54

• “Agile process improvement?” by Keith 

Southwell, in TickIT 3Q02, pp. 3­14

• “Towards an Agile Approach to Software Process Improvement: Addressing the 

Changing Needs of Software Products” by Ian Allison, Communications of the IIMA,