Location:
PMKI > IT
& Construction Industries > Software
& IT projects.
- IT Project Management Overview
- Agile Approaches to Development
- Agile
Overview
- Estimating
for Agile
- Controlling
and Governing Agile
- Calculating status
and completion
- Administering Agile
Contracts
- Agile resources
- Traditional Approaches to Software
Development
- Waterfall
- Useful External Web-links &
Resources.
Other related sections of the PMKI:
- Product Development
- Project management
software
Art:
The Insidious Effect of Technical Debt - The
concept of technical debt refers to the costs of having to
go back and resolve problems that arise because an earlier
decision was made to take an easy option, instead of the
best one.
PP: The Paradox of Project Control in a Matrix Organisation. This paper explores the hypothesis that, within complex matrix organizations, the ‘zone’ between the strategic vision set by senior management and the projects created to fulfil it, is a highly complex and dynamic organism that's reaction to stimuli cannot be predicted. Succeeding in this environment needs a different management paradigm from that developed for management in traditional project industries. The characteristics of a complex matrix organization include: multiple/competing lines of authority, virtual and partial/part time teams, divergent objectives, and many competing levels and types of authority. This paper describes the paradigm shift in management thinking needed to succeed in managing projects across this ‘zone’. To succeed, managers need to combine vigilance and agility to identify and capitalize on unexpected gains and deal with unexpected problems.
Note: A comprehensive list of software suitable
for managing ICT projects can be found at
Project Team
Management & Collaboration software.
Agile
is a general term, derived from the Manifesto for Agile Software
Development which states:
We are uncovering better ways
of developing software by doing it and helping others do
it. Through this work we have come to value:
Individuals and interactions over processes 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 the items on the right,
we value the items on the left more.
This statement is supported by twelve principles that define a way of developing software and other ‘soft products’ focused on flexibility and adapting to changing user or customer requirements to maximize value. The agile approach (or philosophy) is, with a few word changes, applicable to most projects most of the time. Whereas the specific methodologies created for software project management such as Scrum have a significantly more limited sphere of application.
We are not experts in any of the various and evolving agile methodologies, the most prominent seem to be Scrum as the method of working, with Disciplined Agile (DA) and SAFe® (Scaled Agile Framework) as the overall management approach, where DA can be used to create context-sensitive options that optimize SAFe practices and ensure the delivery of business solutions. The papers in this section are written from a business and governance perspective, not a technical agile perspective, for up to date technical resources see the 'agile resource links' below.
The history of developing software using agile concepts predates the Agile Manifesto by many years, this is discussed in A Brief History of Agile, part of our History of Agile, Lean, and Allied Concepts page.
This topic looks at the practical application of Agile in a business environment. Click through to see more on Product Development & Maintenance.
Agile Overview
DP: Thoughts on Agile. Agile is a way of developing software and other ‘soft products’ focused on flexibility and adapting to changing user or customer requirements to maximize value. This paper looks at the implication of managing an agile approach to product development.
Art: There’s Agile and there’s Agile, understand the difference! This article defines three very different business environments where 'Agile' approaches can deliver real benefits and identifies the differences in management approach needed to maximize value for the organization.
Art: De-Projectizing IT Maintenance. Not everything in IT needs to be a project – by de-projectizing maintenance work major improvements in delivery are possible.
Art: Processes -v- People. You can get the best of both worlds by embedding organizational agility into your procedures, methodologies and management.
Blg: What is Agile? The Agile Manifesto sets out a philosophy not a methodology and change the term ‘software’ used in the manifesto to product (or output), it is a generally applicable philosophy.
Estimating for Agile
Planning poker, also called Scrum poker, is a consensus-based, gamified technique for estimating, mostly used to estimate effort or relative size of development goals in software development. In planning poker, members of the group make estimates by playing numbered cards face-down to the table, instead of speaking them aloud. The cards are revealed, and the estimates are then discussed. By hiding the figures in this way, the group can avoid the cognitive bias of anchoring, where the first number spoken aloud sets a precedent for subsequent estimates.
Click through for a list of estimating tools.
Controlling and Governing Agile
Prs: Controlling Agile. A review of the decisions, questions and options for effectively integrating project controls with an 'agile' product delivery methodology.
Prs: Governing Agile – the changing role of project controls in an ‘agile’ environment. The challenges of governing and managing an 'agile' environment are significant. This presentation suggests an appropriate framework for the overall governance of agile projects (including the role of a steering committee) and outline the controls framework needed to support both the management and the governance of the project.
Art: How should the different types of project management be described ?. This article looks at the challenges of categorizing projects based on the 2024 PMI classification process of Predictive - Hybrid - Agile and the consequential consigning of waterfall to history.The key finding is getting the right balance between Agile and Predictive drives project success.
PP:
Scheduling Challenges in Agile & Distributed
Projects. The focus of this paper is to define
the challenge and look at practical options for managing
work efficiently in a wide range of projects where the CPM
paradigm does not apply. Including those using various
agile and lean approaches, other soft projects, and
distributed projects. The paper:
• Briefly defines the management assumptions that support
the use of CPM scheduling, its origins,
and limitations
• Develops a classification framework of project
characteristics to help define the potential usefulness of
CPM scheduling across different project types
• Briefly describes some of the management approaches
currently used in non-CPM projects including
agile and lean, their benefits and
limitations
• Considers the application of the framework discussed
above applied to a typical wind farm project, and
• Develops general recommendations for the management of
non-CPM projects focused on optimizing
the efficient use of resources in agile
(soft) projects and distributed projects.
There may be a high level ‘road map’ outlining the
desired route to completion and/or specific constraints on
parts of the work in both soft and distributed projects,
but there remains a lot of flexibility in the way the work
is accomplished. And, in many cases there is a deliberate
management intent not to follow a predetermined sequence
of activities defined in a CPM schedule! The focus of this
paper is to define the challenge and look at practical
options for managing the work efficiently.
Download the original PMWJ version of this paper.
For more on the challenges of scheduling and controlling Agile projects see: Schedule control in Agile and Distributed projects and Project Controls 3.0.
The
core elements of an agile approach are the project team
and stakeholders develop a backlog of work to be done to
achieve the desired objective, and then at regular
intervals the project team selects the next items to do
from the backlog. The underlying assumption is a committed
and skilled team actively involved in the work are the
best people to decide what should be done next, and the
best way to do it. However this agility introduces a range
of controls challenges, in particular assessing the
current status from a time perspective, and calculating an
expected completion date.
PP: Calculating Completion. Tools used for assessing status, and predicting the completion of projects include: Bar Charts, Burndown Charts, Kanban Boards, Velocity, CPM, EVM + ES, and Work Performance Management (WPM). This paper considers each of these options against a highly simplified project, with a focus on the subjective and objective information available from each tool and how they compare.
Prs: Controlling agile and distributed projects A new Paradigm for Success. This presentation defines the characteristics of projects that are not suited to CPM, including agile, adaptive, and distributed projects and describes an approach for managing this type of project based on agile and lean, while recognizing there are likely to be some mandatory sequences that must be followed. It suggests a rigorous framework using WPM for identifying progress and predicting the project completion date based on the quantity of work achieved compared to the quantity planned to be accomplished.
Art: WPM for Agile Projects. This article identifies the cause of the gap in Agile project management, the inability of current tools to accurately predict completion and demonstrates how WPM will effectively close this gap. Most project sponsors and clients need to know when the project they are funding will finish, other people are dependent on the project's outputs to achieve their objectives. WPM provides this answer based on consistent, repeatable, and defensible calculations.
WPM works within than Agile paradigm to assess progress
and predict completion based on comparing the work
achieved to the work planned to be achieved up to a point
in time.
See more on
Work Performance Management (WPM).
The law of contracts requires the project to comply with the agreed contract obligations and for it to be administered in accordance with the terms of contract. The penalties for failing to comply with the terms of the contract can be severe. Using a agile methodology to accomplish the work does not change this fundamental set of legal requirements! The contract may be adapted to facilitate the use of agile, but ultimately the terms of the contract set out the agreement between the parties.
Blg: Commercializing Agile. Choosing to use Agile as a project delivery methodology will not change the laws of contract, which means organizations using the agile methodology will need to become more commercial and adapt their processes. This post looks at some of the issues involved in administering contract claims when agile methodologies are being used to deliver the project output.
PP:
Assessing Delays in Agile & Distributed
Projects. This paper focuses on assessing
delay and disruption in projects where there is no CPM
schedule, other agile or adaptive approaches are being
used to manage some or all of the work. This paper offers
a practical solution to the challenge of assessing delay
and disruption in this type of agile and
distributed project, where the traditional
concept of a ‘critical path’ simply does not exist and the
effect of intervening events has to be considered in terms
of loss of resource efficiency.
Download the PowerPoint: P215 Assessing Delays In Agile &
Distributed Projects PPT
Click through to see more on assessing
delay and disruption.
Blg: Software sales hype and the law. This post looks at the problem of over promising and under performing in software delivery. The software has to be fit for its intended purpose or the vendor is likely to be held liable for the clients losses.
Blg:
IT Business Sued for US$300 million+.
Construction and engineering companies have been used to
litigation over the non-delivery of contractual
obligations for well over 100 years. Following the 2010,
BSkyB v EDS judgement, the IT industry is now firmly in
the same boat!
Note: Broadcaster BSkyB was paid a total of £318
million as a final settlement of this dispute.
The
Easy WPM Workbook,
is a practical spreadsheet that performs the calculations
needed to implement Work Performance Management (WPM) on
agile projects to calculate the status and anticipated
completion dates based on the work performed vs the amount
of work planned to be achieved at a point in time. Any
convenient metric can be used, ideally one that is already
part of the project management systems such as story
points, function points or development hours.
To download sample files and see how the tool works see Easy WPM Workbook
GAO
Agile Assessment Guide discusses best
practices that can be used for Agile adoption, execution,
and program monitoring and control. Use of these best
practices should enable organizations to better transition
to, and manage, their Agile programs.
Download
the Guide.
Agile Alliance - the home of the 'Agile Manifesto' - https://www.agilealliance.org/
Best Management Practice products, UK Government
(formally OGC, now Axelos) - the umbrella site dedicated
to making access to information quick and easy:
https://www.axelos.com/
- PRINCE2 Agile - a complete agile project
management solution:
https://www.axelos.com/best-practice-solutions/prince2-agile
Disciplined Agile (DA) tool kit from PMI - https://www.pmi.org/disciplined-agile
SAFe Scaled Agile Framework a system for implementing Agile, Lean, and DevOps practices at scale - https://scaledagile.com/what-is-safe/
Agile Business Consortium - A not-for-profit organization, that pioneered Agile and has unrivaled expertise in the field: https://www.agilebusiness.org/
Scrum AllianceⓇ - a nonprofit organization that is guiding individuals, leaders, and organizations with agile practices, principles, and values: https://www.scrumalliance.org/
SCRUMstudy - Global Accreditation Body for Scrum and Agile Certifications (owned by VMEdu): https://www.scrumstudy.com/
The software development industry started in 1953 with the SAGE project, this was the first time a well defined software development methodology was needed to implement a program on a computer. Before this time initially the programming function was integral to the development of the physical computer, and later was done in the machine's operating code. At this time software engineering was assumed to be similar to other engineering disciplines and the management of software developments used the same approach, you created the plan for the work and then built to the plan. This approach is essential for most engineering projects such as construction, shipbuilding, aircraft manufacture, etc., it was soon found to be sub-optimal for software projects.
By the 1970s, various iterative and incremental development approaches to the development of large software projects started to emerge. The 1970 paper by Dr. Winston Royce 'Managing the development of large software systems' was one of the first to argue the need for an iterative approach to software development with prototyping.
This tend continued through the 1980s and 90s. Techniques such as 'Spiral', RAD, and Scrum appeared.
The Agile Manifesto (discussed above) published in 2001 consolidated these different methodologies into a common concept 'Agile' and has provided the foundation for the continued development of iterative and adaptive approaches to software development.
Prs: The Effective Management of Time in Complex Projects. An ICT Perspective. The IT industry’s inability to effectively manage time has been widely documented. Other industries are no better, if the Burj Khalifa in Dubai had been built at the same speed as the Empire State Building (completed in 1931) it would have opened two years earlier! Research by the CIOB undertaken in 2007 found most complex/mega projects failed to adequately mange time, most finished late and the situation was getting worse over time. Interestingly, the degree of failure seems to be the same regardless of the size of the penalties imposed for late completion and regardless of the form of contract used.
The Waterfall approach to software development was formulated in DOD-STD-2167A published by the US Department of Defense in 1988. The waterfall model, requires the following phases to be followed in order:
The waterfall model from the 1980s is based on the premise that the project should only move to a new phase when its preceding phase is reviewed and verified. However, waterfall can include slight or major variations on this process, including returning to the previous phase after flaws are found downstream, or returning all the way to the design phase if downstream phases identify major deficiencies.
The combination of a rigid framework, lack of senior
management understanding of IT, poor management practices
leading to over documentation, and long development
cycles, created a situation where 'waterfall' became
synonymous with bad management and poor project delivery.
This poor reputation has been used by agile advocates to
promote a better way of developing software and sell their
services, a trend that is continuing. However, it is
important to note:
1. Waterfall was a relatively late development -
there were other agile software development methodologies
in use before 'waterfall' and
before the Agile Manifesto.
2. The waterfall concept only applied to software
development projects. Other engineering project
require design to precede the
building process and cannot go back and change 'built'
work without
incurring massive costs.
The development of agile and the brief history of waterfall are detailed in A Brief History of Agile, part of our History of Agile, Lean, and Allied Concepts page.
Care is needed to ensure everyone understands the project strategy. Download our White Paper on Project Strategy.
Blg: The Problem with Waterfall. This post provides a brief history of Waterfall from inception to its abandonment in the 1990s, and argues the use of the term 'waterfall' in the 21st century is meaningless, no one is using waterfall, and no one know what the term is supposed to mean in a modern context.
Download DOD-STD-2176A
Defense System Software Development (1988).
Download Software Requirements are they really a
problem, T.E. Bell and T.A. Thayer (1976).
Download Managing the development of large
software systems, Dr Winston W. Royce (1970).
Australian Computer Society (ACS) - Computer industry professionals: https://www.acs.org.au/
International
Software Benchmarking Standards Group - The mission
of the ISBSG is to improve the management of IT projects
through the use of public repositories of software
engineering knowledge and metrics: https://www.isbsg.org/
For papers on Agile presented at the PGCS
Annual Symposium see:
