Agile Maturity Model (AMM): A Software Process Improvement framework for Agile Software Development Practices

Article (PDF Available) · January 2009with 29,891 Reads 
How we measure 'reads'
A 'read' is counted each time someone views a publication summary (such as the title, abstract, and list of authors), clicks on a figure, or views or downloads the full-text. Learn more
Cite this publication
Abstract
Agile software development methodologies have introduced best practicesinto software development. However we need to adopt and monitor thosepractices continuously to maximize its benefits. Our research has focused onadaptability, suitability and software maturity model called Agile Maturity Model(AMM) for agile software development environments. This paper introduces aprocess of adaptability assessment, suitability assessment, and improvementframework for assessing and improving agile best practices. We have alsodeveloped a web based automated tool support to assess adaptability,suitability, and improvement for agile practices.
Advertisement
3
Agile Maturity Model (AMM) Patel and Ramachandran
Agile Maturity Model (AMM): A Software
Process Improvement framework for Agile
Software Development Practices
Chetankumar Patel(1) and Muthu Ramachandran (2)
(1) Innovation N ort h, Faculty of IT, Leeds Metropol ita n U niv ersity (United Kingd om)
E-mail: c.pa tel @le edsmet.ac.uk
(2) Innovation N ort h, Faculty of IT, Leeds Metropol ita n U niv ersity (United Kingd om)
E-mail: m .ra mac handran@lee dsm et.ac.uk
ABSTRACT
Agile software development methodologies have introduced best practices
into software development. However we need to adopt and monitor those
practices continuously to maximize its benefits. Our research has focused on
adaptability, suitability and software maturity model called Agile Maturity Model
(AMM) for agile software development environments. This paper introduces a
process of adaptability assessment, suitability assessment, and improvement
framework for assessing and improving agile best practices. We have also
developed a web based automated tool support to assess adaptability,
suitability, and improvement for agile practices.
Keywords: Software Process Improvement, Agile Maturity Model, Agile Software
Development
1- INTRODUCTION
Agile software development methodology is a conceptual framework of prac-
tices and principles to develop software faster, incrementally and to produce
satisfied customer. Several agile software development methodologies have
been suggested in the literature, like Extreme Programming [3], Scrum [32],
Crystal Methodology [12] and Mobile-D [19]. All these methods adopt agile
principles, such as iterative development, frequent and early delivery of work-
ing software, and simplicity as defined in Agile Manifesto [1].
Agile methods defines how the development should be carried out under agile
values and principles [1], to address the challenges like requirements change,
customer satisfaction and rapid development [30]. According to [18] “Agility is
the ability of to both create and respond to change in order to profit in a turbu-
lent business environment” [18].
While on the second hand CMM(I) or software process improvement has
4
Int.J. of Software Engineering, IJSE Vol.2 No.1 January 2009
gained a lot of attention during the last decade. Due to the increasing competi-
tion in the software market faster delivery, high quality products and customer
satisfaction are the major concerns for software organizations. A quality proc-
ess can have a positive impact on services, cost, on-time delivery, develop-
ment technology, quality people and quality of products [35].
It is challenging issue that the CMM, CMMI for software and process im-
provement were applicable to the agile methods, these two approaches have
been informally characterized as having the same relationship as oil and wa-
ter [34].
Agile software development methodology is the iterative software develop-
ment methodology for small to medium organization and main objectives are
lower cost, high productivity and satisfied customer. The CMM tends not to
focus the software process on an organization’s business objectives in their
software process improvement programme [28]. Also most companies, small
to large companies found it is too difficult to reach higher levels in the CMM
[7][8] [22].
[17] reported the use of the CMM in several software organizations. The study
consistently showed significant organizational performance improvements that
were directly associated with process maturity. The study also mentioned that
the CMM improvement path is not always smooth, the efforts generally took
longer and cost more than expected. While agile software development meth-
odology is targeted to lower cost. Some of the KPAs have been found difficult
to apply in small projects [7]. This may be because CMM was originally struc-
tured for big enterprises [22]. CMM addresses practices such as document
policies and procedure that large organizations need because of their size and
management structure [7].
Normally agile software development practices do not support the heavy
documentation at all and people communicate verbally on on-going basis.
Unlike CMM, CMMI does not just focus on software process management; it
also considers other department such as marketing, finance and purchasing
[2]. So it could be seen unnecessarily complex, when it is applied to agile
software development practices like Extreme programming, Scrum and lean
development. When businesses adapt the CMMI they should be familiar with
the CMM practices. CMMI Based upon the software CMM and has most of the
same process areas. It may also inherit some of the same problems as CMM,
such as the problem in reaching higher capability levels [5]. This is not ac-
ceptable against the agile software developments principle and motivation.
CMMI is a process oriented. Maturity of an organization is depends on the
practices that are to be followed, not on the result. But Agile practices (XP)
promises client satisfaction, no over time etc. thus it would not be a good idea
to say that a given project is on the highest level of XP/Agile maturity while it
suffers from the overtime and lacks of client satisfaction [23]. It is really im-
portant to have a process improvement framework for the agile software de-
5
Agile Maturity Model (AMM) Patel and Ramachandran
velopment practices. CMM and CMMI and their like have been accused of
being bureaucratic models that forces their client to go through their maturity
ladder without ensuring that they will achieve a quality product or meet their
business objectives [33]. According to [16], CMM and CMMI and their like as
not a ‘Good medicine’ for even very large system engineering projects and
they are overly complex for most IT projects.
There is a consensus that the current standard software process improvement
frameworks such as CMM can not be applied unmodified to small organiza-
tions [7]. While majority of the organizations who adopt or using the agile
software development practices are categorized as small to Medium enter-
prises. In addition, they need to be tied to the business objectives as there is
no mechanism for doing this yet with the current software process improve-
ment models [28].
Agile software development practices are more business objective oriented
practices. Achieving business objectives is one of the important recipes for
information technology business success [20]. Current software process im-
provement models have not yet shown a mechanism for aligning SPI Activities
with business objectives [13] [15] [28] [33]. So it is really difficult to do map-
ping the current software process improvement model with agile software de-
velopment practices. However Paulk [24] suggested the Extreme program-
ming form a CMM perspective. But this approach is also difficult and inade-
quate to identify or define the maturity level of the organization based on his
report.
There is a need for a Software process improvement model to suit agile soft-
ware development environments. Therefore the purpose of this paper is to
propose and evaluate a Software process improvement model for Agile Soft-
ware development environments and enhance the adaptability of agile soft-
ware development methodology and its practices. The purpose of this paper is
to define a generic process model for s oftware process improvement that is
suitable for agile software development environments, to identify and define
agile practices for each maturity level and relate agile practices problem to
agile practices improvement goals
2- PROCESS IMPROVEMENT FRAMEWORK FOR AGILE
SOFTWARE DEVELOPMENT PRACTICES (Agile Maturity
Model (AMM))
According to Christie [11], defining processes is recognized as critical ele-
ments in the software process improvement [11]. To keep the representation
clear, understandable and usable the AMM links the agile software develop-
ment practices to maturity levels, but it is not an exhaustive representation of
agile software development practices. The AMM model is based on the agile
software development values, practices and principles.
6
Int.J. of Software Engineering, IJSE Vol.2 No.1 January 2009
The AMM model is designed to improve and enhance the agile software de-
velopment methodology and boost up the agile principles and objectives like
the lower cost, customer satisfaction, software quality, etc. Figure 1 introduces
the AMM (Agile Maturity Mode)l for agile software development. This high
level view of the model shows how agile software development practices ma-
ture from an initial or ad-hoc level to continuously improving level based on
the agile principles and practices. In this model each level has a pre defined
goal to help practitioner or organization focus on their improvement activities.
Figure 1 Agile Maturity Model (AMM)
Level 1: Initial Level (Not accommodating at all There is no process im-
provement goals defined at this unstructured level)
The software development practices or process is very slim at this level and
not necessarily repeatable. Organizations typically do not provide a stable
environment for development. Level 1 company does not have defined agile
software development process. The main problems at this level relate to over-
times, schedule slips, communication, software quality and development cost.
These companies operate in their own unique way and depend on particular
Initial (1)
Explored (2)
Project Planning
Story card driven development (Requirements Management)
On Site Customer (Sta keholders Ide ntification)
Introduc tion of Test D riven Develop ment
Defined (3)
Customer Relationship management
Delivering Working Products or SW
Frequently
Pair Programming
Mutual Interaction
Test Dri ven Developm ent
Impleme ntation and I ntegration
Coding Standards
Improved (4)
Project Management
Sustainable pace
Self organization team
Risk Ass essment
Code Op timization C ode
Sustained (5)
Project Performance Management
Defect P revention
7
Agile Maturity Model (AMM) Patel and Ramachandran
8
Int.J. of Software Engineering, IJSE Vol.2 No.1 January 2009
Level 3: Defined Level (Customer satisfaction, Software quality and de-
velopment practices)
Level 3 denotes a more focus on practices related to customer relation ship
management, frequent deliveries, pair programming, communication, coding,
testing and quality of software. The goals for this level are as
Customer satisfaction
Communication improvement
Software quality
Enhancement on coding practices and coding standards
The customer relationship is maintained very well at this level. At this level
companies ensure a deeper understanding of the test driven development for
coding and testing, pair programming and subsequently enhance the ability to
deliver software frequently and coding standards.
Level 3 companies had increased their control over their technical practices
like coding and testing practices and furthermore the practices related to cus-
tomer relation ship management is focused, but saw little improvement on
managing the practices related to people. They continued to report problem
on working hours or overtime management sustainable pace for development
team and project management. At this level no structured risk assessment is
performed. Furthermore no co nsideration is taken towards code optimizations.
At level 3 most of the technical problems are solved but the organizational
problem like problems related to the team are unsolved.
The AMM at level 3 maturity aims to help developers identify and improve
problems related to customer relationship, coding, testing, frequent releases
and coding standards. This is achieved by an assessment of current process
and to identify where weakness lie. The table 1 summaries goals, key process
areas and assessment questionnaires for AMM maturity level 3.
9
Agile Maturity Model (AMM) Patel and Ramachandran
Figure 2 Goal, Key process area and assessment questionnaires for AMM
Level-2
10
Int.J. of Software Engineering, IJSE Vol.2 No.1 January 2009
Table 1 Goal, Key process area and assessment questionnaires for AMM
Level-3
3.1.1 System metaphor is defined,
which allows the customer represen-
tative to understand the system
(Choose system metaphor)
3.1.2 Customer and business repre-
sentative present or at least invited to
all team estimation sessions
3.1.3 Refactoring is encouraged via a
little-and-often approach and larger
refactoring reprioritised with the cus-
tomer
3.1.4 Make small frequent release
3.1.5 User stories are written.
3.1.6 Project plans are created to
create project plan
3.1 Customer Re-
lationship Man-
agement
3.1.7 Effectively collaborate customer
3.2.1 Made small frequent releases
which will create feedback loop
3.2.2 Only one pair integrates code
at a time
3.2 Delivering
Working Prod-
ucts/SW frequently
3.2.3 Integrate often
3.3.1 move people around
3.3.2 the customer pay frequent visit
to the development team
3.3.3 all production code is pair pro-
grammed
3.3.4 only one pair integrates code at
a time
3.3.5 use collective code ownership
3.3 Pair Program-
ming
3.3.6 overtime data are collected and
published
3.4.1 All code is pair programmed.
3.4.2 Story cards are written by the
collaboration of on-site customer and
developers
3.4.3 Communicates result through
acceptance testing
3.4.4 Refactoring is encouraged via a
little-and-often approach and larger
refactoring reprioritised with the cus-
tomer
Level 3: De-
fined Level
(Customer
satisfaction,
Software
quality and
development
practices)
3.4 Mutual Interac-
tion
3.4.5 Team members have an open
work environment that supports col-
laboration and conversation
11
Agile Maturity Model (AMM) Patel and Ramachandran
3.5.1 Code the unit test first
3.5.2 Refactor whenever and wher-
ever possible
3.5.3 All code must have a unit tests
3.5.4 All code must pass the unit test
and score must be published before
it can be released
3.5.5 When a bug is found tests are
created
3.5.6 Are the best practices for
automated tested encouraged, re-
warded and in place on the project?
3.5.7 Perform Peer-reviews
3.5 Test Driven
Development
3.5.8 Analyse results and identify
corrective action
3.6.1 No functionality is added early
3.6.2 Integrate often
3.6.3 Automated testing is used to
support frequent integration test
3.6.4 No up front design
3.6.5 team delivers useful content for
business review every 1-4 weeks
3.6.6 the list of user story is repriori-
tised based on an updated evalua-
tion of the project at each iteration
boundary
3.6.7 the best practices for continu-
ous integration are encouraged, re-
warded and in place on the project?
3.6.8 Prepare for product integration
3.6 Implementation
and Interaction
3.6.9 Determine integration se-
quence
3.7.1 Codes must be written to
agreed standards
3.7.2 Code the unit test first
3.7.3 All production code is pair pro-
grammed
3.7.4 Only one pair integrates code
at a time
3.7 Coding Stan-
dards
3.7.5 Use collective code ownership
12
Int.J. of Software Engineering, IJSE Vol.2 No.1 January 2009
Level 4: Improved (People orientation and project management Prac-
tices)
Companies at this maturity level are in a position to collect detailed measure
of the software development process or practices and product quality, both the
software development practices and products are quantitatively understood
and controlled using detailed measurements [25].
The improved level of the AMM model is foc used on the project management,
working hours, self organising team, risk assessment and more related to de-
velopment team rather than product it self. This is an internal attribute of the
team which is not directly visible to the customer. Level 4 denotes a more ac-
tive and mandatory examination of risk and respect to the team who is going
to develop the system. The goals of this level are
Empowered team and rewards
Project management
Risk assessment
No over time
Simplicity
Level 4 called the improved level includes the people orientation and project
management practices. This level focuses on responsibility accepted by the
team instead of given to them, considering to do the simplest thing that could
possibly works, no hard work but smart work and self organising team.
The AMM at level 4 maturity aims to help developers or managers to respect
for the co-workers or people involved in the project, identify and improve prob-
lems related to team sustainable pace and organising team by itself. This is
achieved by an assessment of current process and to identify where weak-
ness lie. The following figure 3 summaries goals, key process areas and as-
sessment questionnaires for AMM maturity level 4.
13
Agile Maturity Model (AMM) Patel and Ramachandran
Figure 3 Goal, Key process area and assessment questionnaires for AMM
Level 4
14
Int.J. of Software Engineering, IJSE Vol.2 No.1 January 2009
Level 5: Mature level (Performance Management and Defect prevention
practices)
Companies at this level continually improve their processes through quantita-
tive feedback from the process and form testing innovative ideas and tech-
nologies [25]. Companies moving up from level 4 to level 5 should have a
wealth of metric data to manage the course of process [11].
The mature level of AMM addresses issues of customer and developer’s satis-
faction. Here we decided to take into account not only the software process
but also result achieved by the team. The goals of this level are
Context improvement
Uncertainty management
Tuning project performance
Defect Prevention
There are two KPAs at this level which are project performance and defect
preventions. The following figure 4 summaries goals, key process areas and
assessment questionnaires for AMM maturity level 5.
Figure 4 Goal, Key process area and assessment questionnaires for AMM
Level 5
15
Agile Maturity Model (AMM) Patel and Ramachandran
3- SOFTWARE PROCESS IMPROVEMENT ROADMAP FOR AGILE
SOFTWARE DVELOPMENT PRACTICES
The process improvement roadmap for agile software development is summa-
rised in figure 5.
Figure 5 Process improvement roadmap for Agile practices.
The key features of the process are as:
Adaptability and suitability assessment is carried out by the agile team
members which are any like developers, coach, testers with collabo-
ration of on-site customer. This is found to be a useful process during
the AMM implementation. The purpose of involving this process is to
ensure or to identify the organization is an agile software development
organization or not. If not then this adaptability and suitability recom-
Not
Adaptable
Agile Adaptability
and Suitability
Assessment
Recommendation for
Adaptability
Agile practices
assessment based
on the value and
principles
Identification of
KPAs / Area of
Improvement
Planning For
Improvement
Mapping with best
Knowledge based
Agile Practices
Implementation
Maturity Level
Assessment
Adaptable
Agile
Team
16
Int.J. of Software Engineering, IJSE Vol.2 No.1 January 2009
mends what they needs to do be an agile software development or-
ganization.
Early in the AMM programme the business objectives or business
goal are defined by the agile team. The goals drive much of the sub-
sequent activity, especially the selection of KPAs or maturity level and
prioritisation of the area for improvements.
A tailored version of the AMM assessment (similar like CMMI model
but the key process areas and goals are entirely different than CMMI)
is carried out by the agile team, to identify area for improvement. This
is also indicating the maturity level of the software process.
The plan for the improvement is identified based on the inputs pro-
vided to the assessment questionnaires for each maturity level key
process areas. In this plan, practices should be identified to support
the implementation of the prioritised area for improvements.
After the identification of the KPAs for each maturity level, a guide
based approach was designed to capture the best practices in order
to improve the prioritised area for improvement. This guide based
practices approach is found on the agile software development litera-
ture like extreme programming practices [3].
3-1 The Adaptability and suitability assessment
Adaptability framework is based on the questionnaires, like the determining
the main problems in the existing software development process or software
development methodology used or intend to use during the next project, exist-
ing knowledge on traditional and agile software development methodology,
customer relationship with development team, customer availability during the
project, developers attitude or characteristic towards the working patterns,
their quality of work individually and in group, project size and lastly man-
ager’s attitude towards team and by assessing their knowledge of project by
using traditional and agile methods.
An adaptability questionnaire, which is showed in the table2, is actually di-
vided in the following five sectio ns.
Software development methods used or intend to use.
Problem identification during the software development and Solution
adopted or trying to adopt to solve problems
Customer availability and relationship
Developers and Managers knowledge on Agile methods and working
quality in group
Project size (Usually agile methods are suitable for SMEs)
17
Agile Maturity Model (AMM) Patel and Ramachandran
Table 2 Adaptability questionnaires
Adaptability Questions
Possible options
Which one are the most difficult
software development problems
you had or are you trying to
solve?
Customer availability
Customer relationship
Deliver software on time with all features
Variable requirements
Requirement change
Schedule slips
Project cancelled
System goes sour
Defect rate
False feature rich
Staff turnover
Lack of quality staff
Excessive documentation of requirements
High turn over of employee
Which development life cycle
(process) is used or intends to
use on pilot project?
Incremental software development
Sequential process (Water Fall Mode)
Prototyping software development method
Evolutionary process
Reuse Process
Which factor do you want to op-
timise during the pilot project?
Productivity
Minimum budget
Efficient burn rate
On-time delivery
Beating the estimate
Following the plan
Working with incomplete knowledge
Handling emergent requirements
How often you got customer
available at project location?
On-site customer
Fixed contract
Visit once a week
Priced contract
Visit when needed
Not available at all
What is the primary problem you
face with customer or which
problems are you trying to
solve?
Availability
Variable requirements(Different voice)
Request to deliver product quickly
Customer’s category towards
domain
Domain expert
Business expertise
Business analyst
Novice
Which method used to present
requirements or going to use on
pilot project?
Detailed documentation
User story(Story cards)
Use case
Other
18
Int.J. of Software Engineering, IJSE Vol.2 No.1 January 2009
Estimation is done by?
Developer
Project manager
Project tracker
Testing team
Quality assurance team
Estimation technique used or
planning to use?
Past estimation
Function point
COCOMO model
Other
What do you consider about
customer relationship ?
Not satisfied
Satisfied
Really impressed
Do you do or planning to do up-
front project design
Yes or No
What is developers most impor-
tant working quality
Ability to work in group(Pair programming)
High individual ability(Solo programming)
Do your management team con-
sider to do simplest thing that
could possibly work?
Yes or No
Do manager offers sustainable
pace (40 hours work)
Yes or No
What is manager’s view or atti-
tude towards responsibility
Responsibility is assigned or given to team
Responsibility accepted by team
How often managers do meeting
or ready to do?
Daily stand up meeting
Weekly meeting
Do when needed
Not at all
What is the size of the pilot pro-
ject?
Small
Medium
Large
Our adaptability assessment brings three result based on the answers sup-
plied on the adaptability Model. Those results are as following
1. Recommended to adopt agile methodology on you pilot project.
2. Ready to adopt an agile methodology but needs an improvement or
needs to pay attention or focus on the recommended area.
3. Pilot project is not suitable for agile methodology, but they can still apply
agility after adopting agile software development knowledge
The following figure shows an adaptability framework process. Where developer
(Any member of development team) passes through the assessment question-
naires and end of the assessment result is retrieved. These questionnaires re-
quire an extensive knowledge of project development life cycle and project soft-
ware development experience as well. This adaptability just not cover one aspect
of the development life cycle it covers all aspect of the software development life
cycle and it puts people in the centre of the assessment instead of process itself.
19
Agile Maturity Model (AMM) Patel and Ramachandran
3-2 Agile Practices Assessment method and identification of KPAs for
improvement
The purpose of the assessment method is to assess the current agile software
development practices. Process assessment consists of the knowledge on
agile software development practices and business case workshop, Which
focus on process improvement and provides a roadmap for process improve-
ment. The AMM assessment model is based on an agile software develop-
ment practices, modified and customisable version of the SW-CMM assess-
ment questionnaires. Emphasis placed on the agile practices, developers and
on-site customers. This process is expected to enhance the communication
and understanding; in particular it is expected to clarify the actual issues of the
people involved in the process improvement actions. AMM recommended
having a shared vision of the process improvement and any one can control
process improvement activities at any stage. The following figure 6 shows
how to identify the areas for process improvement. We identify area of im-
provement through the questionnaires which are discussed into the agile ma-
turity model section.
Figure 6 Areas for improvement assessment framework
SW-CMM provides a guideline for good management and engineering prac-
tices, with a strong emphasis on management, communication, and co-
ordination for development and maintenance of the software process. But as
can be seen earlier SW-CMM does not suitable or acceptable for the agile
software development practices or methodology.
The AMM model’s main objective is to tailor the software process improve-
ments programme for the agile environments; therefore identifying the matur-
ity level of the agile practices is a crucial activity in the AMM model.
Assessment of the current Agile
software practices
Identify areas for Improvement
Assessment Method
20
Int.J. of Software Engineering, IJSE Vol.2 No.1 January 2009
The main objective from the SW-CMM assessment is to assess the capability
of an organization and identify the key process area as opportunities for proc-
ess improvement. The main objective of the AMM assessment is to identify
the areas for improvement. This approach is achieved by the AMM trough its
own assessment questionnaires based on the agile software development
practices, principles and values. In AMM the KPA identifies the issues that
must be addressed to achieve a maturity level in AMM maturity model. Each
KPA identifies the cluster of goals considered important for enhancing process
capability. These related activities are called the key practices. An automated
tool has been built to facilitate the work of the AMM method.
The AMM assessment in this project is tailored to suit agile software develop-
ment environments, their needs and objectives such as eliminating the prac-
tices which are not necessary for them and adding new practices which di-
rectly related to agile software development. Thus the AMM assessment
method is flexible and does not involves any unnecessary KPAs or question-
naires.
Self assessment is the most common way of performing software process
assessment [14]. The popularity for self assessment lies in its low cost, good
accessibility and ownership of the result [14]. We are going to follow the self
assessment for the software process assessment. Automated assessment
also considered for this approach.
AMM assessment questionnaires responses are: Yes, Partially, No, Not Appli-
cable (N/A). this assessment response are very similar to SW-CMM response
Yes, No, N/A and Don’t Know. In our approach response partially permits the
assumption that part of the process or work may have been performed or if
performed then not fully addressed. N/A is selected when the practice is not
possible to implement. If the answer is Yes than the practice is fully imple-
mented and well addressed in the project. If No then it’s not addressed at all.
In AMM assessment area of improvement is identified if the answer of the
questionnaires is as Partially, No or N/A. Using these criteria the percentage
for each KPAs can be calculated as follows:
! (Yn) + " ! (Pn) * 100
! (Tn) - !(NAn) (1)
Where Yn = Number of Yes answers
Pn = Number of Partially answers
Tn = Total Number of the questions
NAn = Number of N/A answers.
The following table 2 shows the general idea of analysing the questionnaires.
21
Agile Maturity Model (AMM) Patel and Ramachandran
Table 3 General idea of analysing the questionnaires
Answers
No of An-
swers
Total Ques-
tions
Total of An-
swers Except
N/A
KPA rating
Yes
3
Partially
2
No
1
N/A
1
7
6
83.33 %
From table 2 the figure 83.33 in the KPA rating is representing the capability
level of the assessed KPA. The interpretation of this as following
Fully Achieved: 86% to 100% there is evidence of a complete and
systematic approach to and full achievement of the defined key prac-
tices in the assessed KPA. No significant weaknesses exist across
the defined organization unit.
Largely Achieved: 51% to 85% there is evidence of sound systematic
approach to and significant achievement of the defined key practices
in the assessed KPA. Performance of the key practices may vary in
some areas.
Partially Achieved: 16% to 50% there is evidence of sound system-
atic approach to and achievement of the defined key practices in the
assessed KPA. Some aspect of achievement may be unpredictable.
Not Achieved: 51% to 85% there is little or no evidence of achieve-
ment of the defined key practices in the assessed KPA.
3-3 Mapping the Area of Improvement with knowledge based Best
Agile Practices
Current software process improvement models or CMM models are not com-
patible or difficult to identify the area of improvement for the agile software
development practices. Therefore we suggested using the knowledge of the
best agile software development practices that have proven successful in
solving problems. Consider the following figure 7, which shows how the identi-
fied area of improvements are mapped with the knowledge based best agile
software development practices.
22
Int.J. of Software Engineering, IJSE Vol.2 No.1 January 2009
Figure 7 Capturing and mapping are of improvement with Agile best Practices
The figure 7 is the conceptual framework and it is mainly concerned with cap-
turing and enhancing the knowledge of agile software development practices
(Agile Practices). The primary concern of the framework is how the process
improvement knowledge is captured or identified, how this knowledge is being
stored, and how this knowledge of existing agile practices maps to the identi-
fied area of improvement. This guide is mainly concerned with the solving par-
ticular problems covered during the agile software development practices as-
sessment, and enhances those related agile practices.
Table 4 Example of mapping process improvement best agile practices to
area of improvement
KPA
Areas for
Improvements
Release Planning
Acceptance Testing
Planning Game
Small Releases
Metaphor
Simple Design
Test Driven Development
Refactoring
Pair Programming
Collective Ownership
Continuous integration
40 hours Week
On-Site Customer
Coding Standard
2.1.1 The Planning
game is used to
create project plan.
2.1.2 Estimate the
Scope of the Pro-
ject.
2.1 Project
Planning
2.1.3 Release Plan-
ning Creates the
Schedules.
Identified Areas of
Improvement
from Assessment
Map the identified are
of improvement to the
knowledge based best
agile practices
Select/Define Knowledge
Based Best Agile Practices
Knowledge
based Best
Agile Practices
Store
23
Agile Maturity Model (AMM) Patel and Ramachandran
3.4.1 All code is
pair programmed
3.4.2 Story cards
are written by the
collaboration of
on-site customer
and developers
3.4 Mutual
Interaction
3.4.3 Communi-
cates result
through accep-
tance testing
4.2.1 No overtime
4.2.2 Manager
team offers sus-
tainable pace
4.2 Sustain-
able pace
4.2.3 Responsibili-
ties are accepted
not given
In table 3 example cells shaded in grey means corresponds practices in the
header of the highlighted cell is mapped to the identified area of improvement
within the row of the highlighted cell. That means the identified area of im-
provement takes the shaded correspondent practices as suggested by the
agile team to be suitable to improve the identified area of improvement
We have developed a tool, agile maturity model for measuring the success of
Agile software development methodology and also its impact on software
process improvement models like CMM (Capability Maturity Model). The pur-
pose of this form is to enable people with little or even no knowledge of agile
software development practices, to estimate quickly easily whether agile soft-
ware development methodology will fulfil their needs and requirements. The
program consists of a form containing a handful of simple questions. The an-
swers from these questions will provide immediate feedback on whether agile
practices are appropriate for the person who answered the question.
The form will ask questions about the critical areas surrounding agile prac-
tices. We need to identify with as few questions as possible whether agi le
practices are, or are not appropriate. The following aspects have been identi-
fied as critical for agile software development practices:
team size
client on site
team location
In order to provide a somewhat more subtle analysis, the following (less criti-
cal) aspects have also been selected:
requirements volatility
facilities strategy
24
Int.J. of Software Engineering, IJSE Vol.2 No.1 January 2009
Figure 8 Automated Tool Support
Figure 8 is the illustration of our tool support which provides a web interface
and online assessment forms to assess suitability for introducing agile soft-
ware development practices into any organization. The interface has been
made simple thus allowing a first time user to fill in the form right away and
getting a result within a few minutes. The results will be colour coded to help
result interpretation and a summarised result will also be available. We have
developed a web based tool which provides an assessment and analysis for
migrating to Agile.
4- RESULTS
We discussed our approach with three different organizations. The following
table 3 summarize the participating companies.
Table 3 Participating companies
Type of com-
pany
Business
Area
Total number
of employees
Number of
software
developers
Company A
Independent
Flyer Design
28
11
Company B
Independent
Software
House
23
9
Company C
Independent
Web devel-
opment and
hosting
19
12
Web Enabled
Database
SPI tool
Agile
Software
Engi-
neers
Improvement
Agile Best
Practices
Guidelines
Recommendation
for Improvements
Assessment
Result
Suitability
Assessment
Adaptability
Assessment
Recommendation
for Adaptability
Project Knowledge
25
Agile Maturity Model (AMM) Patel and Ramachandran
We are still at an early stage of this project, so conclusions are necessarily
tentative, and based on informal observation and discussion. All of the techni-
cal managers were very supportive of the idea of process improvement
framework for agile software development means Agile Maturity Model (AMM)
were found in all the companies. Business managers tended to be somewhat
more sceptical, and will require evidence of payback before becoming fully
convinced of the usefulness of this approach. There was general acceptance
and enthusiasm for a more quantitative approach. Company A is now well into
the implementation phase of their AMM programme, and already report im-
provements in project planning and Agile requirements engineering process.
However more analysis will be needed to determine if this is in fact a direct
result of the improvements initiated as part of the AMM programme. It is im-
portant that improvements are applied in key process areas that will provide
visible payback within a fairly short period. Certainly there should be measur-
able benefits visible with about a year from the outset, or else confidence and
support for the AMM programme will be eroded. In all companies baseline
measurements are being put in place that will allow us to measure the return
on investment, and this will be the principal means by which we will evaluate
the effectiveness of our approach.
5- CONCLUSION
The capability maturity models for software and process improvement were
applicable to the agile methods or not, this is a still challenging issue in the
field of the software engineering. In this paper we describe why and how we
have adapted the process improvement framework and agile maturity model
to focus on agile software development practices. We demonstrate an im-
provement methodology through a series of models that focus on the adapt-
ability, suitability and improvement process of agile practices. Here we dem-
onstrate how organization can switch into agile organization. In this paper we
also developed questionnaires for each level (e.g. figure 2, table 1, figure 3
and figure 4) which will identify the key process area for improvement and
which best knowledge based agile practice need to be considered to improve
that KPAs by mapping the Area of Improvement with knowledge based Best
Agile Practices. This paper will provide a foundation for future development in
the area Agile software development process improvement.
6- FUTURE WORK
A validation study of our AMM model is going to carry out with a group of ex-
perts in both research and industry. Future work includes creating a more
flexible and an automated tool for an assessment to identify the KPAs or area
of improvement for agile practices. Verification and evaluation is still required,
and future work includes testing the model in an industrial setting.
26
Int.J. of Software Engineering, IJSE Vol.2 No.1 January 2009
REFERENCES
[1] Agile Manifesto, (2006) Manifesto for Agile Software Development.
[internet], <http://agilemanifesto.org> [Accessed last 01-03-2006]
[2] Ahern, D. M., Clouse, A. and Turner, R. (2003) CMMI Distilled: A
Practical Introduction to integrated Process Improvement 2nd ed. UK
Addison Wesley.
[3] Beck, K., (2000) Extreme Programming Explained: Embrace
Change, Addison- Wesley Press.
[4] Beecham, S., Hall, T. and Rainer, A. (2003), Defining a Require-
ments Process Improvement Model.. Software Quality Journal Vo-
lume 13 Number 13 septembre 2005, Springer, pp.247-279.
[5] Boehm, B. (2003), Value-Based Software Engineering ACM SIG-
SOFT Software Engineering Notes, 28(2) March 2003, pp 3-15
[6] Boehm, B., Port, D., Jain, A., and Basili, V. (2002), Achieving CMMI
Level 5 Improvements with MBASE and the CeBASE Method. [In-
ternet] Cross Talk Journal, Available from :
<http://www.stsc.hill.af.mil/CrossTalk/2002/may/boehm.asp> [Ac-
cessed 11-10-2007]
[7] Brodman, J. and Johnson, D (1997), A Software Process Improve-
ment Approach for small organisation and small projects. Proceed-
ings of the 19th International Conference in Software Engineering,
19th may 1997, Boston- MA, ACM Press, pp661-662.
[8] Casey, V. and Richardson, I. (2002), A Practical Application of Ideal
Model. Product Focused Software Process Improvement, 4th Inter-
national Conference (PROFES), December 9-11, Rovaniemi Fin-
land, Springer, pp.172-184.
[9] Chrissis, M. B., Konrad, M. and Shrun, S. (2003) CMMI: Guidelines
for Process Integration and Product Improvement, UK, Addison
Wesley.
[10] Chrissis, M. B., Wemyss, G., Goldenson, D., Konrad, M., Smith, K.
and Svolou, A. (2003) CMMI Interpretive Guidance Project : Prelimi-
nary Report [Internet], Software Engineering Institute, Available
from :
<http://www.sei.cmu.edu/pub/documents/03.reports/pdf/03sr007-
body-revised.pdf> [Accessed 01-06-2004].
[11] Christie, A. M. (1999), Simulation in support of CMM-based process
improvement. Journal of Systems and Software, (46): 107-112.
27
Agile Maturity Model (AMM) Patel and Ramachandran
[12] Cockburn, A., (2004) Crystal Clear A Human-Powered Methodology
for Small Teams, and it Addison- Wesley Press.
[13] Dangle, K., Larsen, P. and Shaw, M. (2005) software process im-
provement in small organisation: A case study, IEEE Software No-
vember/December 22(6) pp 68-75.
[14] Dutta, S., Lee, M. and Wassenhove, L. K. (1999) Software Enginee-
ring in Europe : A study of best practices, IEEE Software Volume
(16), Issue(3).
[15] Dyba, T. (2003), Factoes of Software Process Improvement Suc-
cess in Small and Large Organizations: An Empirical Study in the
Scandinavian Context. Proceedings of the 9th European Software
Engineering Conference held jointly with 10th ACM ACM SIGSOFT
International symposium on foundations of software Engineering,
September 2003, Helsinki – Finland, ACM Press, pp.148-157.
[16] Glib, T. (2003), Software Project Management Adding Stakeholder
Metrics to Agile Projects. The European Journal for the Informatics
Professional, IV(4) August 2003, pp.5-9
[17] Herbsleb, J. D. and Goldenson, D. R. (1996), A Systematic Survey
of CMM experience and results. Proceedings of the 18th interna-
tional conference on Software Engineering, May 1996, Berlin, Ger-
many, IEEE Computer Society, pp.323-330.
[18] Highsmith, J., (2004) Agile Project Management, Creating innovative
products, Addison- Wesley.
[19] Ihme, T. and Abrahamsson, P., (2005) The Use of Architectural Pat-
terns in the Agile Software Development of Mobile Applications,
International Journal of Agile Manufacturing, Vol. 8, issue 2, 97-112.
[20] Johnson, J., Boucher, K. D., Connors, K. and Robinson, J. (2001),
Collaborating on Project Success. [Internet], Software Magazine,
Available from :
<http://www.softwaremag.com/l.cfm?Doc=archive/2001feb/collabora
tiveMgt.html> [Accessed 20-jan-2008]
[21] Li, E., Chen, H. and Lee., T. (2002), Software Process Improvement
of Top Companies in Taiwan:a comparative study. Total Quality Man-
agement 13(5) March 2002, pp701-703.
[22] Lyard, A. and Orci , T. (2000), Dynamic CMM for Small organisations.
Proceedings ASSE 2000, the first Argentine Symposium on Soft-
ware Engineering, September 2000, Tandil- Argentina, pp.133-149.
28
Int.J. of Software Engineering, IJSE Vol.2 No.1 January 2009
[23] Nawrocki, J., Walter, B. and Wojciechowski, A. (2001), Towards the
maturity model for extreme programming, 27th Euromicro Proceed-
ings 4-6 September 2001, pp.233-239
[24] Paulk, M. C. (2001) Extreme Programming from a CMM Perspective
IEEE Software 18(6) November/December 2001, pp 19-26
[25] Paulk, M. C., Weber, C. V., Curtis, B. and Chrissis, M. B. (1995) The
Capability Maturity Model for Software : Guidelines for Improving the
Software Process (SEI). USA, Addison Wesley.
[26] Paulk, M., Curtis, M., and Weber, C.,(1993) Software Process Ma-
turity Questionnaire : Capability Model version 1.1. [internet], Car-
negie Mellon-Software Engineering Institute, Available from
<http://www.sei.cmu.edu/publications/documents/93.reports/93.tr.02
4.html> [Accessed 11-01-2007]
[27] Paulk, M., Weber, C. and Curtis, M.(1999), The Capability Maturity
Model for Software. In K. Emam & N. Madhavji (Eds.), Elements of
software process Assessment and Improvement. IEEE Computer
Society Press, PP.3-22.
[28] Paulk, M.C. (1998), Using the Software CMM in Small Organisa-
tions. The Joint 1998 Proceedings of the Pacific Northwest Software
Quality Conference and the Eighth International Conference on
Software Quality, 13-14 October 1998, Portland, USA, Software En-
gineering Institute, PP.350-361.
[29] Persse, J. R. (2001) Implementing the Capability Maturity Model,
USA, John Wiley & Sons Inc.
[30] Pikkarainen, M. and Mantyniemi, A., (2006) An Approach for Using
CMMI in Agile Software Development Assessments: Experiences
from Three Case Studies, SPICE 2006 conference, Luxemburg.
[31] Raynu s, J. (1999) Software process improvement with CMM, Lon-
don, Artech House
[32] Schwaber, S. and Beedle, M., (2002) Agile Software Development
With Scrum, Prentice Hall.
[33] Tim, K. (2004) Practical insight into the CMMI, USA Artech house
[34] Turner, R. and Jain, A. (2002) Agile meets CMMI: Culture clash or
common cause XP/Agile universe 2002, LNCS 2418 pp. 60-69.
[35] Zaharan, S. (1998) Software Process Improvement: Practical Guide-
lines for Business Success, 1st. USA, Addision-Wesley.
... The contributions of this study for academics is the confirmation of the maturity model developed by Patel and Ramachandran (2009a). This study also shows the association between the individual activities within the maturity levels as well as the maturity levels and the perceived project success, addressing a gap in literature relating these concepts. ...
... To that effect, this study has explored the concept of an agile principle-based maturity model. Patel and Ramachandran (2009a) propose an Agile Maturity Model (AMM), which is based on agile principles. The AMM proposes a five-level model of increasing maturity, with key agile process focus areas at each level. ...
... Without an empirically validated agile maturity model (Gren et al., 2015), there is limited guidance for practitioners to reference which agile processes in the AMM will increase the project success rate. Though Patel and Ramachandran (2009a) propose an agile principle-based maturity model, research has not yet been conducted to investigate whether higher AMM maturity relates to improved perceived project success. ...
Conference Paper
Aim/Purpose: Given the underlying philosophy of the agile manifesto, this study investigates whether an increase in agile maturity is associated with improved perceived project success. Background: The underlying philosophy of the agile manifesto is embodied in principle one which promotes the continuous delivery of software that is deemed valuable by the customer, while principle twelve encourages continual improvement of the delivery process. This constant improvement, or maturity, is not a concept unique to agile methods and is commonly referred to as a maturity model. The most common of maturity model is the Capability Maturity Model Integrated (CMMI). However, research consensus indicates CMMI might not fully be compatible with agile implementation, specifically at higher levels of maturity without sacrificing agility. Agile maturity models (AMM), which are aligned to agile principles encourage continuous improvement while maintaining agility. Methodology: The study employs a conceptual model based on an existing agile maturity model that is related to perceived project success. Using an objectivist perspective, a quantitative method was employed to analyze the results of an online survey of agile practitioners. Contribution: The significant contribution from this research is the validation of the conceptual model relating the activities and maturity levels of the AMM as the independent variables to the dependent variable of perceived project success. Findings: The data analysis found that a significant positive correlation exists between maturity levels and perceived project success. The strongest correlation was found at the highest maturity level, with relatively weaker correlation at the lower levels of maturity. It can thus be concluded that a higher level of maturity in the AMM is positively associated with perceived project success. Recommendations for Practitioners: The study has practical implications in highlighting that performance management, requirements management, regular delivery and customer availability are key areas to focus on to establish and continually improve the success of agile implementations. This study further assists practitioners in systematically identifying the critical agile activities, such as the use of story cards, continuous delivery and the presence of a knowledgeable customer. Recommendation for Researchers: The contributions of this study for academics is the confirmation of the maturity model developed by Patel and Ramachandran (2009a). This study also shows the association between the individual activities within the maturity levels as well as the maturity levels and the perceived project success, addressing a gap in literature relating these concepts. Future Research: It would be useful to replicate this study whilst following a qualitative approach. The study could also be replicated with a sample consisting of agile project customers.
... The Agile maturity level [13] in an organisation is considered as one factor that could effect on the accuracy level of the estimation as mentioned in [9]; however, other effective factors have been observed and discussed in this study. ...
... Moreover, the most used estimation techniques in Agile, Planning Poker, need to be examined more in the context of mobile app development in order to validate its suitability in the Agile process for mobile app development. The Agile maturity level [13] has not applied in this case study to measure its relevant and effectiveness to the effort estimation; however, it could be in a future work. ...
Conference Paper
Effort estimation plays a vital role in the software development process in order to ensure that development tasks are delivered within the planned time. The characteristics of the mobile app environment make it different in terms of development from other traditional software. This paper presents a case study in an IT company, which examined their current estimation techniques, planning poker and expert judgment techniques, and its process in agile, and it provides and has validated a proposed estimation technique in order to enhance the accuracy of the existing technique. Moreover, this study presents the effectiveness of estimation factors/predictors in supporting the development team to manage, estimate and create subtasks for their user stories.
... Agile Maturity Model (AMM) was developed by Patel and Ramachandran in 2009. The AMM model is designed to enhance and upgrade agile software development processes and encourage agile principles and goals, such as lower costs, customer satisfaction, software quality, etc. [21]. AMM has the same structure as CMMI. ...
... Organizations at the fifth level of maturity continuously improve their processes through quantitative feedback from the processes on the basis of which they form innovative ideas. This level of AMM solves customers and teams satisfaction [21]. ...
... One of the reasons when an organization decides to do so is the implementation of Scrum. The Scrum Surveys at Yahoo!, in which 71% of its workers took part, revealed that after the implementa tion of Scrum almost all respondents had positive feel ings ( Fig. 1) [4]. S witching to Agile from Waterfall is based on the maturity models. ...
Article
Full-text available
The purpose of the article is the development of recommendations for the business maturity determination and measurement in the implementation of the agile approach for high-tech companies. Methods of analysis of documents, observation, personal and in-depth interviews, case studies have been used in the research. The findings of the research: Business Agility Journey has been suggested for defining the state of the maturity of the company and conducting express diagnostics of agility. Agile Project Management Journey has been developed for the identification of weaknesses by the companies in the path to agility, as well as for the determination of events for the transition from the traditional to the agile approach. Personal Agility Checklist has been designed for testing the soft skills of employees for the presence of the agile mindset. Research limitations include the study of the maturity of companies in the IT industry. Practical implications are based on the use of suggested Agility Journeys in defining the state of maturity and main problems on the transition path. Also, Personal Agility Checklist will help to check the agility of the future employees. The originality of the article is based on the uniqueness of the Agility Journey that has been developed for the first time. Further research on this topic should be focused on the development of an agile mindset as a prerequisite for the provision of agility in the company.
... Among the different tools that agile coaches can use to support the improvement process, they can employ one of the existing agile maturity models (e.g., AMM [11], SAMI [15]). These tools might be useful for discovering problems in their projects, as they prescribe sets of guidelines related to the proper usage of practices in agile projects. ...
Chapter
Context: Requirements Engineering (RE) is one of the key processes in software development. With the advent of agile software development methods, new challenges have emerged for traditional, prescriptive maturity models aiming to support the improvement of RE process. One of the main problems is that frequently the guidelines prescribed by agile approaches have to be adapted to a project’s context to provide benefits. Therefore, it might be naive to believe that it is possible to propose a prescriptive method of RE process improvement that will suit all agile projects without any alteration. Objective: The aim of the paper is to evaluate a hybrid approach to assessing the maturity of agile RE (REMMA), which combines elements of prescriptive and problem-oriented improvement methods. Method: The usefulness, ease of use, and cost-effectiveness of REMMA were investigated through a case study performed in one of the biggest software houses in Central Europe. Results: The results of the case study suggest that the method seems easy to use, affordable, and is perceived as a useful tool to support the process of improving RE practices in agile projects. Its feature of taking into account the dependencies between practices and the necessity to adapt them to a certain project context was regarded as well suited for the agile context. Conclusions: REMMA, which includes two main components: a maturity model for agile RE (a set of state-of-the-art agile RE practices) and an assessment method that makes it possible to evaluate how well the agile RE practices are implemented, seems to be a useful tool supporting improvement of RE in agile projects.
... Ziel des SLRs war es, bestehende Ansätze zur Durchführung und Messung der agilen Transformation herauszustellen. In dem SLR wurden sieben Reifegradmodelle (Agile Adoption Framework [11], Agile Adoption and Improvement Model [12], Agile Maturity Map [13], Agile Maturity Model [14], Benefield's Model [15], Scrum Maturity Model [16] und Progressive Outcomes Framework [17]) und zwei Fragebögen (Perceptive Agile Measurement [18] und Validierung des Agile Adoption Framework nach Gren et al. [19]) identifiziert, die als konkretes Modell für die agile Transformation bei der Entwicklung digitaler Produkte bezeichnet werden können. ...
... Ziel des SLRs war es, bestehende Ansätze zur Durchführung und Messung der agilen Transformation herauszustellen. In dem SLR wurden sieben Reifegradmodelle (Agile Adoption Framework [11], Agile Adoption and Improvement Model [12], Agile Maturity Map [13], Agile Maturity Model [14], Benefield's Model [15], Scrum Maturity Model [16] und Progressive Outcomes Framework [17]) und zwei Fragebögen (Perceptive Agile Measurement [18] und Validierung des Agile Adoption Framework nach Gren et al. [19]) identifiziert, die als konkretes Modell für die agile Transformation bei der Entwicklung digitaler Produkte bezeichnet werden können. ...
Article
Full-text available
Die Nutzerzentrierung stellt im Kontext der öffentlichen Verwaltung aufgrund der Diversität der Zielgruppe einen zentralen Aspekt bei der Entwicklung digitaler Produkte dar. Das agile Paradigma unterstützt hierbei eine hohe Nutzerzentrierung durch seinen Fokus auf den Menschen und das Produkt. In diesem Artikel wird ein Ansatz zur Erreichung einer hohen Nutzerzentrierung durch die agile Transformation im Kontext der öffentlichen Verwaltung vorgestellt. Ziel ist es, auf Basis der Ergebnisse einer bereits durchgeführten Bestandsaufnahme zur Agilität in öffentlichen Verwaltungen, die Herausforderungen in der agilen Transformation zu erarbeiten. Anschließend wird ein bestehendes Screening-Instrument an diesen Kontext angepasst, sodass es zur Fortschri%sermi%lung und-steigerung der agilen Transformation in öffentlichen Verwaltungen eingesetzt werden kann. Die Herausforderungen werden den sechs Dimensionen des Screening-Instruments, Kommunikativ, Änderungsaffin, Iterativ, Teamzentriert, Produktgetrieben und Verbesserungsorientiert zugeordnet. Bezugnehmend auf die Herausforderungen werden Handlungsempfehlungen zu den Dimensionen der Agilität gegeben, aus denen sich die Relevanz der Dimensionen für die öffentlichen Verwaltungen ergibt. Die Anpassung des Screening-Instruments erfolgt auf Basis der Gewichtung der Dimensionen hinsichtlich der Relevanz. Durch Anpassung an den Kontext kann das Screening-Instrument in öffentlichen Verwaltungen zur Fortschri%sermi%lung und-steigerung der agilen Transformation angewendet werden. Auf diese Weise wird eine Steigerung der Nutzerzentrierung bei der Entwicklung digitaler Produkte ermöglicht.
Article
Full-text available
One of the most widely used product developments now is Agile Development Method. In Agile Development there are several frameworks, one of them is Scrum. This research examines the maturity level of software development project management that applies Scrum framework. The research was conducted using quantitative research methodologies using Scrum Maturity Model. Data was collected by distributing questionnaires to employees at a company that works as a Scrum Master. In addition to the data obtained from the questionnaire, interviews were also conducted to confirm answers from respondents. The interview aims to ensure the answers given by respondents are consistent with documentary evidence carried out through the research of project documents. Then the data analysis is done by assessing the level of maturity of each process in the Scrum framework using Agile Maturity Model (AMM) approach. The results from the analysis of Maturity Level Project Management of Software Development are used to provide recommendations for improvement to achieve a higher level of maturity.
Article
Full-text available
Digitalization and internet penetration force telecommunication companies to perform a transformation to survive, to face competitions, and to gain opportunities. PT XYZ is a telecommunication company that has introduced a new leaner and agile working method for digital transformation. The organization is undergoing a transformation to implements an agile approach using a scrum framework. There are two divisions that use scrum that currently plagued with time estimation difficulties and inability to create an agile backlog due to the old change request mechanism. Scrum Maturity Assessment (SMM) is used to measure current scrum practice maturity. The data is retrieved using a questionnaire that was given to two Scrum Master from two divisions which have been implementing Scrum. There are 83 questions derived from SMM assessment questions. SMM assessment indicated the scrum practice is Level 1 (Initial). There are 31.76% of scrum practices in IT division and 36.25% of scrum practices in CS division need to be improved to achieve Level 5 Optimizing. In order to achieve Level 5, we proposed 38 steps and six recommendations which will guide the scrum practice improvement process.
Chapter
Context: Agile software development is widely used by small teams. Companies want to check their implementation of Agile for different reasons. Many Agile Maturity Models (AMM) exist that support practitioners in assessing and improving their agility. However, practitioners need to be able to make informed decisions on which one to use. Objective: The aim of this work is to enable the comparison of existing AMMs. Method: We identified 14 AMMs in a non-systematic literature review, considering non-scientific sources as well. We propose criteria for their comparison based on our experience and our understanding of practitioners’ needs. Results: We present twelve comparison criteria and show how the identified AMMs differ along those criteria. Conclusion: Practitioners get an overview of existing models and can select a suitable one with the help of the comparison criteria.
Article
A number of agile methods are described that try to simplify project management and systems implementation. Evolutionary project management (Evo) uses quantified feedback about critical goals and budgets. It also insists that early, frequent, small, high-stakeholder value deliveries be made to real users. This allows stronger focus, better measurement of progress and more flexibility to change.
Article
Architectural design patterns capture skilled designers' proven solutions for many recurring design problems. These patterns, however, may lead to large solutions and overengineering, which are considered alarm signals from the viewpoint of agility. This paper reports the results of two case studies focusing on the adoption of architectural design patterns in agile development of mobile applications for real markets. An XP-based agile method called Mobile-D™ and the agile architecting process of the Agile Architecture Line approach were used in the case studies. Based on the experience gained from the first case project, more emphasis was laid on capturing the current architectural knowledge about the patterns and solutions proven useful and effective in similar applications running on the used platform. The patterns are augmented before production with suitable supporting information, so as to enable them to help inexperienced designers to improve the quality of mobile applications developed in nine-week agile projects in concordance with agile values. This paper demonstrates empirically that architectural design patterns can help to develop viable software architectures and to document them in a useful way, as applied in a challenging context involving tough time-to-market demands, the mobile development environment and the J2ME platform. This paper further shows that the pattern-based rationale of design decisions and architectural components can provide a key success factor in designing mobile software and improving its quality. The empirical results of this paper are presented in a manner enabling practitioners to utilize the proposed solutions in similar projects.
Conference Paper
Full-text available
The focus of this research is to outline the experience of a small-to-medium-sized European-based software development organization, utilizing the IDEALSM model while implementing a tailored Capability Maturity Model® (CMM®) software process improvement (SPI) program.[CMM is registered in the US Patent and Trademark Office by Carnegie Mellon University.] The goal of the approach undertaken was to achieve process improvement rather than a specific CMM® maturity level. In doing this, the IDEALSM model was extensively researched and employed. The benefits and limitations of the use of the IDEALSM model are presented as experienced. Research was carried out on a number of software process improvement paradigms prior to the final selection of the CMM®. The approach employed as far as possible remained true to the spirit of the CMM®. A key element of this strategy was to see the requirements of the organization as paramount and immediate. It was deemed important for the organization to achieve specific Key Process Areas regardless of their position in the CMM®. The approach provided the organization with the flexibility to invest in the achievement of specific maturity levels at some future date and thereby capitalize on their current process improvement work. Copyright
Article
Full-text available
In today's business environment, information technology (IT) is an indispensable tool for any corporation. One of the largest IT investments goes to software-related products and activities such as development, maintenance and enhancement. In order to reduce the cost of software activities and improve the quality of software products, e˛ ectively managing the software development process is an important topic in the IT ® eld. Since the early 1990s, there has been rapidly growing interest in the capability maturity model (CMM) in software organizations. With the aid of CMM guidelines, a software organization can continually improve its software process. This research discusses the essence of CMM guidelines and surveys the IT organizations of the top 1000 business companies in Taiwan. It explores the status of software process management in these companies and compares the ® ndings with Japanese and US data reported in the literature.