Dan Stelian Roman

Agile Product
Development
A Product Manager’s Guide -
Product vs Project
DAN STELIAN ROMAN

AGILE PRODUCT
DEVELOPMENT
A PRODUCT MANAGER’S
GUIDE - PRODUCT VS PROJECT

2
Agile Product Development: A Product Manager’s Guide - Product vs Project
1st edition
© 2021 Dan Stelian Roman & bookboon.com
ISBN 978-87-403-3913-0
A warm thank you to Daniel I. Roman MBA, for the review of the content of this document.

3
AGILE PRODUCT DEVELOPMENT Contents

CONTENTS
About the author 5

Introduction 6

1 Scaling up Projects 8
1.1 Agile delivery, from Team to Organisation 8
1.2 (Agile) Project Manager; what is it and why do we need it 10
1.3 Is “Waterfall” non-Agile? 11
1.4 Product vs Project 12

2 Project challenges 15
2.1 All projects are challenged 15
2.2 What can impact a successful delivery 15

3 Project Attributes 16
3.1 Business Domain 16
3.2 Size 17
3.3 Complexity 18
3.4 Level of Change introduced 19

4 Choosing a delivery strategy 20

4.1 Highest probability of success 20
4.2 Limited impact on organisation 21
4.3 Organization Alignment 21

5 Focus on practices 23
5.1 Why not frameworks? 23
5.2 Stay Lean 24
5.3 Become Agile 24

6 Case Studies 25
6.1 Taking advantage of Agile 25
6.2 Scaling Agile, Back to Planning 29

7 Conclusion 32

End Notes 34

4
AGILE PRODUCT DEVELOPMENT About the author

ABOUT THE AUTHOR

Dan is an experienced Project Manager with over 35 years commercial experience in a broad
range of business areas, organization structures and cultural environments. Dan started
his career as a specialist in Computer Aided Design and Manufacturing (CAD/CAM)
following his involvement in research during university studies. During a successful career
in research, he developed process improvement strategies, Finite Analysis Method software,
forms recognition algorithms for robots and software for computer assisted design used by
manufacturing enterprises. In 1990s Dan published articles and books on various topics
such as process improvement CAD/CAM manufacturing processes computer simulation,
c/c++. Later he moved to software consulting, delivering projects in Romania, Bahrain,
France, Australia and other countries. After managing large development teams Dan moved
to Project Management and is now specialized in Business Transformations Projects.

Dan has extensive hands-on experience with formal Project Methodologies (PMBOK,
PRINCE2) and Agile frameworks like Scrum, Extreme Programming (XP), SAFe and
Disciplined Agile and he is also a Lean Six Sigma Black Belt. He studied Risk Management
at University of New South Wales, Sydney Australia.

Dan is an active volunteer for the Project Management Institute (PMI®) as a Subject
Matter Expert in Agile, Traditional and Hybrid project delivery and Risk Management.
He was awarded the 2021 volunteer of the year for his contribution to the development
of PMP, ACP, DASSM certifications and Hybrid and Risk Management micro-credentials.
He is the author of “The Agile Enterprise” series of webinars on www.projectmanagemen.
com, the knowledge sharing website of the Project Management Institute, a series of over
50 webinars watched by more than 500,000 people.

https://www.linkedin.com/in/dansroman/
https://www.projectmanagement.com/profile/StelianROMAN

5
AGILE PRODUCT DEVELOPMENT Introduction

INTRODUCTION
Since the publication of the Manifesto for Agile Software Development in 2001 adaptive
approaches to project delivery gained momentum challenging the traditional predictive
delivery, especially for software development projects. Quite successful for small software
development teams, the success rate for Agile frameworks in large and complex projects
is much lower. Figure 1 is a summary of the CHAOS reports, published by the Standish
Group1.

Undoubtable, Agile adoption is certainly growing and if Agile has a much higher rate of
success we would’ve expected an increase in the overall success rate. However, the overall
success rate didn’t change significant between 2005 and 2020. It is interesting to notice
that project rather than failing are classified as ‘challenged’ but Agile didn’t push ‘challenged
‘projects in the ‘successful’ category.

IT Projects Success Rate

56 55
53 52
50 51 50
49 49
46
44

35
32 31 31
29 29 29 30
28 27 28
23 24
22
18 19 19 19 19 19
17 17

2000 2004 2006 2009 2011 2012 2013 2014 2015 2017 2020

Challenged Failed Successful

Figure 1- Impact of Agile on Project Success

Success is measured also by ‘on budget’, but because none of the popular frameworks include
a way to track the budget, at least from the cost point of view it is hard to obtain the true
figure of successful or failed Agile projects.

Based on the CHAOS reports, Project Management Institute - PMI’s pulse of profession
and State of Agile reports it is evident that statistically speaking the rise of Agile didn’t
bring the much anticipated an expected benefits. Roughly 20% of the projects still fail. This
contradicts the perception that Agile projects are more successful. If the conclusion of most
Agile surveys indicating that Agile is used in more than 50% of the projects is correct and
Agile projects are more successful we should’ve seen a drop in failure rate.

6
AGILE PRODUCT DEVELOPMENT Introduction

However, we should not conclude that Agile didn’t had a significant impact, taking it out of
the global context. Life changed significantly since 2001 and maybe Agile helped us coping
with a much higher level of change and to adapt project delivery to a much dynamic market,
with technology savvy customers and increased customer influence to product development.

Not all projects can or should be delivered in an Agile way. Based on our experience with
Agile Transformations we believe that most initial attempts to use Agile will, and should,
fail. A quintessential characteristic of Agile is learning from failure, therefore ‘success’ needs
to analysed based on the overall impact of a portfolio of projects on the bottom line of
the organization.

A project is defined by cost, time and scope to deliver an output. That output may or may
not become an outcome and increase the profit or the likelihood of achieving the goals of
the organization. Whilst everyone agrees that greater Agility is essential to adapt the outcome
of the project to changes in customer needs, when looking at ‘successes’ from a project
delivery point of view we need to accept that Agile comes at a cost and apart from better
alignment of the scope with customer’s needs, a fast delivery timeframe is essential for a
‘successful’ project. The cost should justify the benefits, rather than becoming the focus of
the project delivery or a process improvement goal.

This book is a Project Manager’s analysis on how the delivery approach, predictive or
adaptive, can address some of the current market challenges, how project management and
product development knowledge can be combined to ensure success.

7
AGILE PRODUCT DEVELOPMENT Scaling up Projects

1 SCALING UP PROJECTS

1.1 AGILE DELIVERY, FROM TEAM TO ORGANISATION

Unknown by many practitioners using Agile frameworks in software development, Agile
originated in Manufacturing in the last decades of the 20th Century, when the manufacturing
industry realised that, in their quest for near perfect quality, they lost the ability to respond
fast and efficient to changes in demand. Agile, or mass customization was their response
to continuous and significant change in customer demands. At the same time software
development teams were looking for a more structured delivery approach, after attempts
to build Software Factories using manufacturing practices failed. None of the two Agile
approaches, the one that started in Manufacturing in 20th Century or the version made
popular by the 2001 Manifesto for Software Development, are project oriented. Although
most Agile frameworks developed in the last decade pretend to be or are perceived as Project
Management methodologies none of them can be used to manage all the 3 fundamental
aspects of a project: Scope, Time and Cost. Whilst the Agile Manufacturing concept is
process oriented, built on process improvement principles, using Lean Six Sigma metrics
to ensure that fast change is done efficient. the software specific Agile frameworks are all
product development approaches, most of them limited to small software development teams.

Enterprise Board

Core
Business

Shared
Services
era ss
Bu jects

ns
Op sine
Pro

tio
sin

IT Projects IT Operations
ess

Bu

Software Software
Development Maintenance

Figure 2 - Softare Agile Frameworks

Figure 2 illustrate the limited area that software Agile frameworks can cover. The frameworks
that inspired the Manifesto for Agile Software Development were created based on author’s
experience with small software development teams. Scrum, the framework that is used
by most Agile teams recommends a team of 5-9 “developers” Even the so-called ‘scaled’

8
AGILE PRODUCT DEVELOPMENT Scaling up Projects

Agile frameworks emerged in the last decade are still software development oriented and,
although built on Lean principles and practices, can’t be used for a project, especially when
IT department is not responsible for delivery.

The scope of a projects can focus on product, process or both, and unlike the product
development process it has a well-defined duration and budget. In predictive approaches
locking down two of three components of the “iron triangle”, usually budget and time, will
trigger a clear a defined scope. Agile, doesn’t and should not lock down the scope, letting
the customer choose what is more important for them and in the process saving a lot of
time that in a predictive approach is allocated to finalising upfront the whole project scope.
This paradigm shift has not only the benefit of easy change in priorities but also a much
faster market delivery to what the market needs.

It is important to note that unlike in a software development start-up or a software development

team that can be lost somewhere in a large Information Technology department or even
outsourced to a partner, in a large organisation a project can be initiated anywhere and
may or may not have a software deliverable. A manufacturing company may not have any
software developer in the IT Department. Either because the Applications Maintenance and
Support is outsourced or because the company uses Software as a Service. In many large
organizations the Information Technology unit (IT) is responsible mainly for supporting
the infrastructure and managing vendors. Projects that need software development will hire
independent contractors or vendors that will deliver the software components.

Frequently the software component in a project is limited to configuration and customization

of a commercial off the shelf (COTS) software system, rather than new development.
Most projects will be focused on the core business, and may or may not have a technology
component. Other projects can focus on process improvement like marketing, sales or support
maintenance and support activities for the product or service provided to the customers.

Nowadays, most programs, initiatives and projects are Business Transformations focused on
Process Improvement, alignment of the organisation structure with market segmentation. From
the predictive/adaptive point of view the first factor that will determine optimal approach
is the customer/market behaviour. In a stable and conservative market, like infrastructure
(roads) or agriculture it is unlikely that Agile practices will be needed as much as in highly
volatile domains like social media.

The life of any product and service has 4 stages (Introduction, growth, maturity and
decline), each stage with his own particulars from the project perspective. For example, while
introducing a new product on the market Agile may look like the preferred choice. In reality

9
AGILE PRODUCT DEVELOPMENT Scaling up Projects

this is perhaps the phase that require a lot of planning. Using timeboxing may seem to be
a very good risk mitigation strategy but in absence of a good planning and monitoring the
product may be discontinued just before passing the critical point to growth phase. The
growth phase is perhaps the most suitable for Agile, adapting the product to the feedback
from the market. Looking at the history and the development of the Project Management
science it is obvious that the need for project management become a necessity when the
product is successful and the organisation needs to grow.

Introduction Growth Maturity Decline

Figure 3 - The Product Lifecycle

At the end of the day customers will pay as much as they can afford for what they perceive
as a necessity for that moment. It’s the duty of the Project Manager to align customer’s
demands with the project delivery schedule and budget.

1.2 (AGILE) PROJECT MANAGER; WHAT IS

IT AND WHY DO WE NEED IT
Planned approach, also referred as “waterfall” is perceived as a rigid project management
methodology that does not meet the needs of modern organisations and should be replaced
by adaptive project delivery approaches, like Agile frameworks. Most Agile framework like
Scrum and its derivates, don’t have a Project Manager role and are defined for product
development not for project delivery. Most developers believe that Project Management is
limited to managing timeGrowth
and budgetMaturity
and because Agile Decline
frameworks are product centred
there is no need for a Project Manager.
Introduction

10
AGILE PRODUCT DEVELOPMENT Scaling up Projects

However, Project Management doesn’t mean preparing monthly report, signing timesheets or
setting unrealistic targets for the development team members. Financial Management is vital
for the project success as are Risk Management, Procurement and/or Change Management
but more than anything else People management, from project team members to internal
and external stakeholders.

Project Managers are responsible for the successful delivery and they should have the authority
to choose and use various practices and tools as they see fit in a certain context. One size
(framework) can’t fit all project; balancing of adaptive, aka Agile and predictive or more
planned practices depends on the context and require deep knowledge with all the delivery
practices as well as experience.

Agile Project Management is more of a marketing gimmick to sell certifications and make
laggard organizations believe that they become Agile. In real life it is hard to implement
a pure adaptive or pure predictive framework, most, if not all, delivery approaches are
hybrid with predictive and adaptive practices being mixed. Adaptive or predictive suitability
depends on the company culture, project size and complexity or the skills and experience
of the project team members.

A good project Mmanager should be able to identify and use any pactice, tool or method
that will ensure a successful delivery in a given context.

1.3 IS “WATERFALL” NON-AGILE?

Contrary to general perception the method called “waterfall is not a non-Agile approach. At
the time of its publication Dr. Royce’s article2 was a revolution and remains more Agile than
some ‘scaled’ Agile frameworks that originated as Lean or brought a lot of Lean practices in
attempt to make Agile more efficient. To understand any methodology the approach should
be analysed in context. The “waterfall” method, although the word is never mentioned in
the article, is not as rigid as it is usually presented by Agile Trainers and Agile Coaches.
The method developed in 1970 is based on author’s experience with large and complex
software system development and inspired the predictive approach to project delivery in
many industries, becoming a de facto standard for predictive project delivery, aka using a
plan to deliver the project.

The “waterfall” method describes a process that covers the entire product build life cycle. The
design, build and testing prior to launching to the marked or delivery to the internal users.

11
AGILE PRODUCT DEVELOPMENT Scaling up Projects

Dr. Royce’s article introduces few concepts that are fundamentally Agile:

Feedback Loops. The article has a lot of feedback loop, recommending that feedback
is provided not only between successive build phase but also to all the anterior
phases. For example, feedback during testing can be used to revise the design of
some of the product features.

Prototyping. Described in the article as “do it twice” prototyping is used to validate

the design in close to real conditions and improve the product or the delivery
process based on learnings

End User involvement. This is one of the most important success factors in any
Agile framework and it should be noted that it was recommended 30 years before
the Manifesto for Software Development was published.

The “waterfall method”, although developed for software, is widely implemented as the
Execution phase in Project Management. It starts with requirements definition, and follows
activities done in the initiation phase of a project, like Business Case and securing the
budget to commence the project. For projects that are delivering a product or service it is
important to know that a project doesn’t start with Execution and there are other activities
that comprise the full Project lifecycle.

Understanding the difference between product and project is important. The product Lifecyle
is covered by many projects, not all of them delivering the actual product or service. Some
of the projects will deliver only the build process and tools, some will create the distribution
channels. After the ‘production line’ and the distribution logistics are finalised other projects
will focus on the implementation of the product or service.

In the following sub-chapter the difference between product and project will be explained
in more details, presenting the kind of projects that are initiated during the entire lifecycle
of a product or service.

1.4 PRODUCT VS PROJECT

As mentioned before, project and a product are not the same thing, and each concept has
his own lifecycle, stages and components. Whilst a Project Manager should understand the
processes that are involved in the product development, their responsibility is limited to
the scope of their project.

12
AGILE PRODUCT DEVELOPMENT Scaling up Projects

In Figure 4 is a combination of the 3 key elements related to a product lifecycle, from an

Enterprise point of view.

Project 2
Build
Version 1
Project 3 Project 4 Project 6
Establish Version 2 Product
Market Retirement
Introduction

Introduction

Introduction
Maturity

Maturity

Maturity
Decline

Decline

Decline
Growth

Growth

Growth
Project 1 Project 5 Project 7
Build Process Improve Process Process Decommissioning

Figure 4 - Product vs Project(s)

1. Product – something that is created to address a specific need, usually to be

sold to another organization. A “product” is not limited to a material form
(goods) that changes ownership from the manufacturer to consumer (user). It
can be a service, a non-material action resulting in a measurable change of state
for the purchaser caused by the provider or an idea, like intellectual property.
In Fig 4, “product” is associated to a good or service.
2. Process - a series of actions or steps taken in order to achieve a particular end.
In this instance, actions and steps related to a product lifecycle.
3. Project – a temporary effort to create value through a unique product, service
or result. A project has a defined start and end, a schedule, a budget, and a set
of expectations the need to be met on the end date.

The above definitions are not exhaustive, they are provided to illustrate the relation between
product, process and project For any Agile practitioner, especially the ones leading the
delivery as a Product Owner, Product Manager/Director, or Project Manager understanding
the distinction between product and project delivery is essential for success. Using a product
delivery framework, like Scrum, to manage projects is risky because the focus is not on
delivery on time efficient but on product attributes. Rework is waste from financial and
time perspective and not only that will impact the price but it may result in missing the
launch in the window of opportunity.

13
AGILE PRODUCT DEVELOPMENT Scaling up Projects

Below is a brief description of the relation between product, process and projects illustrated
in Figure 4. Every product start with market research, either as a result of a request from a
customer or an idea. Why the product started is very important. A new product may require
one or more new processes or significant change. A new product is risky, at least in the
initial phase. A product will usually span multiple versions and trigger the following projects

1. Build the process. Any new product will need a process, either adapted or
newly defined that will describe not only the activities but also the required
skills, tools and logistics needed to produce, deliver to users and maintain it.
Even a new software solution may need a new set of libraries, training for
developers or the provisioning of new environments.
2. Version 1 - A new product is usually created as a result of a project. The first
version will meet basic requirements with the main objective to enter the
market. First version will prove not only the readiness for the market but also
will determine how much the organisation should invest later. This kind of
projects may not bring any financial benefit.
3. Establish Market – This project may be the first one that delivers profit. It
is also the project where the organisation can decide to discontinue the first
version, plan a better version or even abandon the product line
4. Version n - Successful products that proved their market viability there will be
more version releases, each likely to be a separate project with work on various
versions being done in parallel
5. Improve build process – Once it is certain that the market wants the
product and there is a need for growth there should be a project with a sole
objective to make the process(es) more efficient and/or more flexible. Process
Improvement projects are very specialised and need very good understanding of
Lean and Agile principles. Agile and Lean are opposing mindsets and Lean can
significantly reduce Agility.
6. Product sunset – Discontinuing a product is not as easy as stop producing it.
Lack of support can damage manufacturer’s reputation in the market or even
incur litigation costs.
7. Decommission infrastructure The infrastructure, tools and processes put in
place at the beginning of the lifecycle need also to be decommissioned. It is
not only the documentation, like process maps, that need to be updated and/or
archived but also the tools and re-allocation of the resources used to build the
product/service.

14
AGILE PRODUCT DEVELOPMENT Project challenges

2 PROJECT CHALLENGES

2.1 ALL PROJECTS ARE CHALLENGED

Although based on the data presented in from Figure 1, we may believe that only one
third of the projects are challenged in reality the percentage of project that are challenged
is much higher, if not 100%. First, we have to accept that failed projects had challenges
but, unlike the rest of the projects, where the Project manager and the project team found
a way to address them, a failed project is a sign that challenges couldn’t been overcome.
Similarly, a successful project doesn’t mean that it wasn’t challenged but that the Project
manager and the project Team found ways to address challenges. It is not uncommon that
a successful project is successful because the budget/time was changed using the Change
Control process and the new baseline was met. Some projects are reported as ‘successful’
for political reasons only, although in reality they failed.

Agile projects are very hard to be classified as “unchallenged” because the Agile delivery is
a challenge in itself. Embracing change means embracing risk and risk can lead to failure.
However, unlike in the predictive approach where there is a correlation between time,
scope and budget, in Agile where the budget is fixed and the project team is delivering ‘as
much as possible’, it is very hard to say if a project was successful, if it delivered what the
customer needed or wanted.

2.2 WHAT CAN IMPACT A SUCCESSFUL DELIVERY

According to Murphy’s law if anything can go wrong, it will and projects are the best way
to confirm it. Change, means unknown and, despite a very good marketing, Agile is not a
silver bullet. Change introduces risk and if risk is not managed it can have led to failure.
Agile, praise itself for user involvement, but that’s neither new nor specific to Agile. The
so-called waterfall method recommended continuous user involvement in 1970, the Standish
reports identified since 1994 that user involvement is one of the three major reasons that a
project will succeed or fail, along with executive management support and a clear statement
of requirements. And yet, nothing has changed significantly since.

Agile may, and should, help in addressing changes in user requirements but, apart from a
simplistic statement that individuals and interactions are more important than processes
and tools it doesn’t offer a real solution for end user involvement, other than more formal
processes supported by collaboration software. In most Agile implementation that follow
the Manifesto for Agile Software Development values and principles, there is less Executive
Management Support because the Agile frameworks used in software development are
designed for small teams and usually management averse.

15
AGILE PRODUCT DEVELOPMENT Project Attributes

3 PROJECT ATTRIBUTES

3.1 BUSINESS DOMAIN

The Business domain, or area of implementation, is a very important factor in selecting the
delivery approach. Each business area has approaches that historically work and following
a pattern may be a better option than trying a new way.

Not every project can or should be delivered using an adaptive approach. There are many
business domains where there were similar projects done successfully for hundreds of years.
Building a road, a bridge or even a data centre is not a very variable process and although
new ideas can be tried and may bring benefits it is very unlikely that the project plans
can’t be reused.

Technology start-ups, software in particular have a high rate of failure, although they are the
ones using adaptive approaches. Unlike accounting or constructions, where the failure rate
is much lower and despite the myth that Agile minimise the risk, using adaptive delivery
methods in breakthrough projects is not recommended.

Only for internal employees

16
AGILE PRODUCT DEVELOPMENT Project Attributes

When adopting and Agile way of working the organization needs to accept the risk of
complete failure. Not only that Agile is not a silver bullet for any business but failure, learning
for it is a core principle of Agile product development. As easy as it may sound, learning
needs individual commitment and support from the management and those conditions are
sometimes hard to be met.

Before jumping into the Agile boat an organization must do a bit of homework and find
out if any other organization in their industry, especially competitors, use Agile practices.
The frameworks that generated the Manifesto for Agile Software Development were built
in a specific context (software development projects delivering new products) and for a
specific mindset: developers that can ‘refactor’ their code and fix defects without impacting
the bottom line. The ‘fixing’ doesn’t mean that there is no cost involved or that Agile works
for any software system build.

3.2 SIZE
Scrum, the building block of most Agile frameworks was defined for a team of 5-9 developers.
This is by no means an Agile “discovery”. Like in the case of Team dynamics (form, storm,
norm, perform) it is part of standard management theory.

Moreover, for large teams of very small teams (2-3) any framework can be counterproductive,
especially when it is based on adaptive practices. For large teams is obvious that coordination
become a challenge while for very small teams there is no need of coordination and the
PM will be in most cases the technical SME that drives the scope.

The “waterfall” scarecrow used by Trainers and Coaches to promote Agile, is a method
developed in 1970 for large and complex software systems. For the kind of software
application developed by a small team it recommended two steps only: design and code.
It has feedback loops, reccomends prototyping and continuous user involvement. Iterative
and incremental delivery is not what Agile is about.

Iterative and incremental is how software development was done since the beginning of this
industry. Its use was documented first in 1970s in a large military project. Any system that
survived in the market after the first deployment to the users was continuously changed
until it was retired.

Although there are attempts to define ‘scaled’ Agile practices it is still unclear for example,
how the “Scrum of Scrums” works in a project world. In most ‘scaled’ Agile frameworks
integration is addressed using traditional predictive practices, like schedule alignment,
common milestones or Program Management.

17
AGILE PRODUCT DEVELOPMENT Project Attributes

A significant danger for Agility is bringing Lean practices, like Kanban, out of context for which
they were developed and used in manufacturing. “Scaled” Agile is, for the moment, a return
to Lean, focus on waste elimination, flow cycle time and other metrics used in manufacturing.

The very practices that led to the apparition of Agile Manufacturing as a solution for the lack
of capability to adapt to market changes are used now to ‘scale’ Agile in software development.
Large scale product development requires more efficient approaches, process and tools but
not by putting in danger Agility, the capacity to change fast to meet market demands.

3.3 COMPLEXITY
In theory, the more unknown is the scope of the project, the best it is suited for an Agile
or adaptive delivery approach. Many believe that the situation presented in Figure 5 is how
Agile should look: a Project Manager working for 3 independent Scrum Teams working on
3 different products. Most developers believe that the PM doesn’t need to do much: only
some “paperwork” like the schedule for the Program Manager, some “stuff” for the PMO
and to approve the timesheets.

PM

Scrum Team Scrum Team

Scrum Team
Figure 5 - Project and Scrum Teams

In reality, things are not that easy. The method that proposed for the first time using
the rugby practice for software development and later inspired the development of the
Scrum framework warned that the approach won’t work in any situation, even in software
development because it has built in limitations.

18
AGILE PRODUCT DEVELOPMENT Project Attributes

Transformation
Program
HR ERM

PMO

Tablets

Training Uniforms

Procurement

IT
Change
Management MDM
Mobiles

Operations
Data Feed

Figure 6 - The Project

Those limitations especially visible in case of large and complex systems. In the above
example, the perceived, from the team level, simple project delivery was in reality part of
a very complex Business transformation initiative that involved interactions with many
business units, significant effort from the infrastructure and operational teams and a very
costly and detailed Organisational Change Management plan.

3.4 LEVEL OF CHANGE INTRODUCED

Agile in itself is a disruptive change. It challenges organizational culture, and management
styles. It requires trust and delegation of decision power to lower levels. Unfortunately,
although simple frameworks like Scrum can embed other practices, none of the software
oriented Agile frameworks recognize the need for Organization Change Management.
More change in top of the change introduced by the project itself is a huge risk and many
failed Business Transformations, Agile included, can be attributed to underestimating the
importance of Change Management and resistance to change at the Enterprise scale.

19
AGILE PRODUCT DEVELOPMENT Choosing a delivery strategy

4 CHOOSING A DELIVERY
STRATEGY
Looking at the history of project management, it is obvious that neither predictive nor
adaptive delivery approaches are silver bullets. They are not generic delivery frameworks even
in a specific domain, like software development. A good project management methodology
should combine adaptive and predictive practices and the supporting tools and provide
guidance for the Project Managers on selecting the delivery approach. The PMO of the
future is a Centre of Excellence that can support the project delivery at the organisation
level and provide guidance not only to the project managers but to the entire project team
and the internal stakeholders.

Although it is hard to have a one-size-fits all delivery approach, there are few rules of thumb
that can be used to choose between adaptive and predictive delivery practices. Project delivery
is within the organisation and for the organisation. The organisation should benefit from
the project outcome and the delivery of the project should not create unnecessary tension.
It is ‘normal’ to use a pilot Agile project as a starting point for the adoption of Agile at
the organisational level. With this trend, the selection of the first project to be delivered
using Agile, is very crucial.

Following are few recommendations for organisations with a mature planned delivery
framework wanting to implement adaptive delivery practices.

4.1 HIGHEST PROBABILITY OF SUCCESS

Especially in a risk averse culture or organization, it is better to start with a project that has
a high likelihood of success regardless the delivery approach. The road to Agile doesn’t have
shortcuts nor is easy and without enemies. A failed Agile delivery can work against Agile
Transformation even when Agile is a trend. “It’s nothing new, we tried it before “, “it is
not good for us” are normal comments when Agile is introduced in an organization. They
will become “I told you and” and “what a waste of time and resources” and a significant
impediment for a future attempt to use Agile approaches. Even the supporters will be
cautious for a while.

More important than the reputation risk is the fact that choosing a difficult project will
make the learning difficult. A challenged project won’t leave room for experimentation and
tunning. Agile requires inspection and adaptation base on feedback and empiricism.

20
AGILE PRODUCT DEVELOPMENT Choosing a delivery strategy

4.2 LIMITED IMPACT ON ORGANISATION

Implementing an ERP rollout as the first Agile project is not recommended. Something like
a mobile application to provide alerts for the existing customers may be more appropriate.

4.3 ORGANIZATION ALIGNMENT

4.3.1 RISK APPETITE

One of the most debatable myths of Agile is that, by delivering in small increments it
minimises the risk. Understandably from a developer’s perspective it is not aligned with
the science and practice of Risk Management. Not only that Agile, by embracing change,
introduces more risk due to frequent and sometimes significant changes but the main reason
for Agile transition is to allow and benefit positive risks aka opportunities.

At the team level, the organisation risk appetite may not be very important but any Project
Manager should be aware and make sure that the planning is done in alignment with
organisation’s risk appetite. Delivery of the project would need to be closely monitored
with tight controls in place. Accept that failure is an option but put controls in place to
minimise the impact.

4.3.2 CULTURE

It is important to build trust with the project team right from the start. Begin by consulting
them and then incrementally give them the authority to take decisions. In a conservative
organisation with very rigid governance, using an Agile framework for the first time should
not be an option for politically important, complex or large projects. Agile needs collaboration,
courage, openness and involvement from all the participants, at all organization levels.

4.3.3 MATURITY

Another aspect that requires discussion is how should an organization adapt when growing.
An Agile framework developed for a small team worked for them in the past, but it may not
work hen the organization has grown in size. For example, a software start-up that grows to
a real organization level, with specialised teams or departments like Finance, Procurement
and HR. Decisions are no longer taken by the “Scrum Team” and some level of governance
needs to be adhered to. The leadership needs to figure out if the Agile practices that worked
for a small and cohesive team will work for the new organization, for larger, more complex
products and projects and last but not least how Agile mindset should be extended beyond
technology projects.

21
AGILE PRODUCT DEVELOPMENT Choosing a delivery strategy

“Scaled” Agile frameworks like Disciplined Agile or SAFe may be an option, but not
necessarily the best one. There will always be projects that must be done using a planned
approach and coaching and mentoring the Scrum Master in Project Management maybe a
better alternative, providing a career progression in a role where he can add value by bringing
their Agile experience to other teams and become Agile Champions at the Organization level

In conclusion, as illustrated in Figure 7, the balance between adaptive and predictive

practices is vital to ensure successful delivery of products and projects, when the team
become an organization. There are many factors that should be taken into consideration
but the following are the most important in our opinion:

1. Change -where there is no change there is no need for Agility. If the path to
delivery is very well known Agile will create confusion and instead of bringing
benefits will introduce waste. Too much change can lead to chaos.
2. Culture – To be successful the Agile approach needs a supportive culture
that encourage individuals to be innovative, learn and contribute to decision
making process
3. Complexity – The more complex the products are, the more complex the
impacted processes will be. Agile doesn’t mean chaos and the Agile frameworks
developed for small teams must be augmented with knowledge and practices
from Lean, Risk Management and the impact of changes monitored using
statistical methods
4. Size – The larger the size of the project the higher the risk. Starting small,
learning and then scaling up what works in a specific context is a good option
to benefit from Agile but too complex or too simple projects and products
won’t benefit from Agile

Size Complexity Culture

Agile
Low Change

Conservative Low Low

Figure 7- Adaptive (Agile) vs Predictive

22
AGILE PRODUCT DEVELOPMENT Focus on practices

5 FOCUS ON PRACTICES
When an organisation must choose between adaptive and predictive delivery, the focus
should be on practices rather than frameworks. Every framework was developed for a certain
project, environment and team. Just because it worked for them, does not mean that it will
work for you. Project Managers are responsible for coaching the team and the organisation
in project management, the same way the Scrum Masters are coaching the organisation in
how to use Scrum. Agile is much more than Scrum and using the Scrum framework doesn’t
always make a team Agile. The Scrum Master’s coaching is limited to the Scrum framework
and, although in the guide is one of the 3 levels of coaching, a Scrum Master that was a
Developer just a couple of months ago won’t have the skills, knowledge and experience to
lead an Enterprise Transformation. It is much easier for Project Managers that use Agile
practices to deliver in a certain context, to identify what works and what doesn’t work.
To accomplish this mission, project managers must learn and understand a broad range of
practices Agile or not.

5.1 WHY NOT FRAMEWORKS?

Many Agile Coaches are in fact trainers. They will sell and implement a certain framework
that they are certified to train and receive support from the certification organization. In
their desire to fast-track Agility and catch-up with what they perceive as trendy or the
norm, individuals and organization will aim for an “Agile” certification. When the goal
is to get certified or “be Agile” the end result won’t be that you are using Agile. Most
of the signatories of the Manifesto for Agile Software Development had their own Agile
Framework and he simple fact that they couldn’t define a single Agile framework should
be enough to prove that Agile can’t be limited to a framework. It can’t be limited even to
Agile practices and the fact that ‘scaled’ Agile is in fact Lean with practices like Kanban and
DevOps focusing on flow and eliminating waste rather than responsiveness to change. Each
framework has built in limitations introduced by the context in which it was developed,
the level of knowledge and experience of the authors and last but not least with the level
of empiricism of the framework. Some frameworks originated as books, the authors having
very little practical experience.

23
AGILE PRODUCT DEVELOPMENT Focus on practices

5.2 STAY LEAN

One of the most frequent mistakes of an Agile Transformation is to reject upfront all previous
practices used in that organization. They may not be perfect, they may not be Agile but they
are usually the result of an evolution and some of them will continue to have value when/if
the organization become Agile. Lean Six Sigma has something that all the Agile framework
misses, a very effective Process Improvement process: the Define, Measure, Analyse, Improve
Control (DMAIC). Although many Agile Coaches pretend to be also Lean experts the reality
is that Lean Six Sigma require a lot of experience and a mathematical background that needs
years to achieve. Moreover, the Lean mindset is completely opposed to the Agile mindset.
Instead of embracing change even late in the process like Agile, the Lean mindset’s focus is
reducing, if possible, elimination of process variability. Lean practices can be a significant
impediment to Agile adoption and should be very carefully analysed to avoid impact on
Agility. Although keeping processes efficient (Lean) is good, especially in short term, from
the strategic point of view Agile is a better option than Lean.

Balancing agile and Lean is not easy and require skills and experience, especially from the
leadership team. One way to fine tune the balance is the Six Sigma, the statistical process
control of the Lean Six Sigma. Any Agile Transformation should star with defining the
problem that Agile may solve. Agile in itself doesn’t pay off. Once the goals are defined the
Analyse phase should identify who and what process needs Agility and how much. That’s
when the existing process must be baselined and then, once Agile is implemented, compared
with the outcome of the Agile change.

5.3 BECOME AGILE

Agile is a must, especially when processes are the close to the near perfect Six Sigma. Agile
is neither a method nor existing knowledge. Individuals, teams and organization become
Agile by doing it. The first stem is to challenge the status quo and introduce change. An
Agile organization is evolving continuously but, unlike aiming to near perfect quality
and cost reduction its focus is on capacity to change rapid to be able to deliver what the
market wants, to react fast and efficient to any market changes, especially to the ones that
are impossible to foresee.

24
AGILE PRODUCT DEVELOPMENT Case Studies

6 CASE STUDIES

6.1 TAKING ADVANTAGE OF AGILE

The first case study is a project delivered in early 2000s, when Agile frameworks were still
a new way of developing software applications. I managed a small development team that
was mandated to modernise a legacy application developed in FoxPro. The original goal was
a slow transition with new modules in .Net, a technology that was still new and unknown
added to the legacy platform.

Initiation Closure

Backlog

Culture
As in any small company, the culture was very friendly with the entire development team
sitting in an open space. The good aspect of a ‘family like’ environment was initially a
good factor but once the transition to a new way of working started it became a challenge.
People were afraid to take personal responsibility and accountability. One of the hardest
personal changes that I had to do transitioning from the Development Manager to Scrum
Master, was to keep quiet and let the team fail. Most Scrum Masters that I worked with,
come from a development background. The Scrum Master role was a recognition of their
technical excellence and a way for the company to promote them to a higher position,
rather than understanding what a Scrum Master does

25
AGILE PRODUCT DEVELOPMENT Case Studies

People
The company had a very “interesting” policy of using students and fresh graduates in a
mix of support and development role. The promise was that it starts with 30% support
and gradually they will be full time developers. That never happened and the morale was
very low, the retention rate was very poor with many employees leaving in one year or less.

Process
There was no process. Basically, the entire process was reactive, working on issues reported
by clients. Everybody in the “team” was a support person, most of the time covering the
end to end process, from answering the customer’s call to developing, testing and deploying
a new version of the product for that client.

The approach
I was coming from a similar environment where we used Extreme Programming to modernise
a FoxPro application. In my previous role I was the new kid on the block that got the
‘easy’ task to develop the first c# module. One of the main lessons learned was that mixing
legacy with traditional is just a way to make bad things worst.

In the new role I convinced the owners to change the slow approach with a disruptive
redesign of the whole solution as a pure .Net solution. That decision paid off and in little
over one year we had a new solution. We used ‘Scrum But’, an customised version of the
Scrum framework, based on my previous experience with XP where ‘by the book’ didn’t
work. We didn’t hold daily stand-ups but I was always available to answer questions. Against
perceived Scrum philosophy that there is a single Developer role that does everything,
I assigned the accountability of the design to one ‘architect’. The product was split in
modules, each module having an owner. It was a very effective way to improve morale, and
personal accountability as well as increasing the productivity. Everybody wanted to show
their commitment and to contribute to the team’s success. Having visibility on individual
contribution and recognising it resulted in a positive and healthy competition.

Agile is based on learning from mistakes and this case is a good illustration of this principle.
We started with Extreme programming (XP) because I knew it from my previous job. When
the company decided to use the framework the whole development team attended formal
training. Using it was an opportunity for us to discover some challenges of the framework.
We found out how hard is to justify to the management refactoring, test driven development
and prototyping. For us (development team) these techniques were very valuable and exciting
but the project manager was tracking weekly progress on a Gantt chart.

26
AGILE PRODUCT DEVELOPMENT Case Studies

Therefore, after discussing my previous experience with the new team we decided to try
Scrum, a framework that looked simpler and with less ‘overhead’.

From the ‘pure’ Scrum’ framework perspective we had almost everything:

• Product Backlog; came pretty natural in the form of a wish list from our
customers the backlog grooming was a good opportunity to learn; we built our
own backlog management tool using the new c# language;
• Sprint Planning. We had weekly planning meetings to set some ‘epic’ objectives
in terms of functionality areas that we will work on; Each module owner
described in this meeting his ‘plan’ and we discussed dependencies
• Product Owner; as the Dev Manager I was the de facto Product Owner. The
prioritisation was indeed done based on “business priorities”. The highest priority
was assigned to changes requested by a customer that was ready to pay for them.
• Scrum Master; combined with the PO role. As a Scrum Master my focus was
on removing blockers and coaching the team and our customers on the values of
Scrum and Agile.
• Sprint Reviews; were probable the best implemented practice. We had at least
one demo per week, mostly on a customer site, where the feature was requested
and deployed first, before becoming a standard feature
• Sprint Retrospective; was also used as a team building exercise in the form of
a long Friday lunch In our case an informal discussion was more effective than
a structured meeting. The focus was on what can we try next rather than what
works and we should keep doing.

What went well

The motivation in the team went through the roof. Not only that we were learning a new
and very exciting technology, rather than fixing bugs in a dying technology but assigning
ownership and accountability was a very good motivator. The team spirit was fantastic.
Everybody wanted to contribute and no one was afraid to talk. As a team we had no fear
of failure because there was no ‘blame game’. We knew that any mistake can be fixed.

A very important lesson learned was the importance of having a process, discipline and
common understanding. Acting as a facilitator rather than ‘The Manager’, holding my
thoughts when I knew that the team will fail was hard but the best way to let the team
achieve self-organising. Failure was always an option and we did fail. It was ‘our’ failure as
a team but it gave us the confidence to try new things. When the developers saw that there
is no punishment for involuntary failure, they started bringing new ideas and working hard
to prove that their idea is the best one.

27
AGILE PRODUCT DEVELOPMENT Contents

What could’ve been done different

We underestimated the willingness of our clients to take the jump with us in a new delivery
approach. Most clients were reticent to embrace a collaborative approach move to a completely
new version of the solution. The old version was in use for almost 10 years and there were
a lot of painful memories from major versions upgrades. The initial marketing campaign
of new and modern solution morphed in “an improved version”.

As any technology company we tried to find allies in the IT department because there were
a lot of technology benefits, starting with a much simpler deployment. We should’ve speak
more with the Business and adapt the roll-out timeframe based on their readiness to use
the new version.

The most important thing that we learned is that the design of a software system should be
driven by the people using it and should solve a real business problem or need. We were
too focused on the excitement of a new technology and we assumed that we know what
the clients need. We spent a lot of time adding features that were never used because the
customer or person that asked for that feature was no longer using the system

Only for internal employees

28
AGILE PRODUCT DEVELOPMENT Contents

6.2 SCALING AGILE, BACK TO PLANNING

Approval Planning Build Close

Cost Management

Risk Management PIR

Stakeholders Management

Scope Management

PB Quality Management PB

Human Resources Management

In the second decade of 2000, when Agile become very popular in small software companies
I managed a multimillion-dollar project for a large Government organisation. The scope of
the project was a completely new system used to manage the reporting metadata.

Culture
Like any large Government organisation, the culture was extremely rigid, with very formal
Governance processes and very politically savvy staff. Change resistance was silent but very
strong. Officially the whole PMO embarked in new ways of project delivery, embraced
change and risk but in reality, every small process change had to be justified and formally
approved before being even considered for implementation.

People
The project team was a sort of ‘rainbow’ team. We had people that were in the organisation
for decades, they didn’t know anything else, neither from the business domain point of
view nor from the process point of view. For them Agile never passed the FrAgile phase.
Fr-Agile phase denote an Agile ‘adoption’ in an organisation that has no confidence that
Agile works and it will continuously focus on the perceived negative aspects to revert to a
planned approach. Any small failure, like missing a milestone, will be used to ‘demonstrate’
that Agile is not a robust delivery approach, hence the term ‘fragile’. The ‘fragile’ perception

29
AGILE PRODUCT DEVELOPMENT Contents

was unfortunately starting from the top, the Delivery Manager perceiving Agile as a risk to
his job. The development team was external, all from a single consultancy. Each consultant
very good from the technical point of view but with no experience as a team and very vague
understanding of the Agile approach to software development. To be successful, Agile needs
a collaborative culture and strong leadership. In this instance neither the development team
nor the management were ready for Agile.

Process
The organisation had a very formal project delivery approach based on PMBOK but
implemented so rigid that even projects that in normal circumstances can benefit from
a predictive approach struggled. Over detailed and too frequent reporting, lengthy and
difficult approval process. They had no choice but to accept Agile because of the very
positive Agile market perception. Because the project was new and the PMO wanted to
be seen as embracing Agile we got an exception to use Scrum. We passed the Governance
challenge but unfortunately, the development team members had no experience with the
Scrum framework. The lead developer assumed the Scrum Master role, because he had
leadership skills but not because he had any knowledge or experience as a Sacrum Master.

The approach
The project was running for more than 2 years in which time the whole team and approach
changed 3 times. The first 2 attempts failed because the project tried to comply with a very
formal delivery approach and produced a lot of documentation that, due to its size and
complexity, was never signed off and the build phase couldn’t start.

The new “Agile” team started building based on their assumptions rather that Business
validated requirements, at times bullying the end users to accept their view. On the surface
everything was going almost well; individual functionality was working satisfactorily and
the feedback from the testers was good.

The issues surfaced when we tried to do a demonstration of an end to end process. The
result was a disaster. The functionality was not coherent, some steps that were assumed part
of an automatic workflow required manual intervention and the Business Manager refused
to continue with the development until there he was confident that the project will deliver
what they need and there is a clear plan of action to put the project back on track.

30
AGILE PRODUCT DEVELOPMENT Contents

This was a good example of what could happen when users are not involved. Although there
were a lot of managers involved in workshops the actual end users were called when most
modules were developed. In the absence of a familiar process and documented artefacts,
the failure of the demonstration resulted in lack of confidence. Going back to a project
schedule with defined activities, milestones, roles and responsibilities as well as developing
a Solution design document, was the solution agreed by the business, PMO and vendor.

What went well

The presence of a good Project Delivery framework that was used before and in which
the users had confidence was a good starting point. Retaining the end users in the project
as Subject Matter Experts ensured that the milestone delivery met their expectations and
reduced the ‘noise’ generated by the escalation to PMO and senior management.

What could’ve been done different

There was no Agile training, neither for the development team nor for the end users. The
other major stakeholder that was partially responsible for the failure was the PMO. They
tolerated the Agile adoption to be seen as “Agile, rather than understanding that it could be
a solution for solving the issues generated by a too formal framework. Instead of assessing
the pros and cons and understanding the limitations of an Agile delivery and the cultural
changes that are required to enable Agility they blindly agreed to use Scrum, with a silent
hope that it will fail. In the absence of a proper understanding of what Scrum and Agile
are, the lead developer drove the project from a pure technological point of view, in the
process missing the business objective.

31
AGILE PRODUCT DEVELOPMENT Conclusion

7 CONCLUSION
Choosing between adaptive and predictive delivery approaches is a process that depends on
many factors and there is no ‘one size fits all’. The choice is not between frameworks but
a combination of various practices.

It is the duty of the Project Manager to recommend and use the most suitable practices
and tools in a specific context. To undertake these task Project managers must be aware of
existing and emergent practices, attend focus groups and professional forums and when it
is necessary to gather deeper knowledge, attend formal training courses.

Culture
The culture is the most important factor because it can prevent the implementation of
the project output, therefore fail a project that delivered successfully its scope. The project
team culture must be aligned with the organisation vision and culture to avoid or minimise
conflict. Agile needs a certain cultural environment and, despite general perception, more
discipline, knowledge and planning than a predictive approach.

The following figure illustrate how the same goal can be achieved using either predictive or
adaptive delivery. Change is possible in either approach; the difference is that adaptive (Agile)
frameworks care ready for change and have less formal processes. Change readiness and
the risk appetite in the organisation will determine if a certain approach is suitable or not.

Scope Change

Adaptive
Planned

1 2 3 4 5 6 7 8 9 10 11 12
Figure 8 - Scope change: adaptive vs predictive

32
AGILE PRODUCT DEVELOPMENT Conclusion

People
The outcome of the project is dependent first and foremost on the people involved and
without leadership and skilled team members, the project will fail. Team cohesion and
collaboration are very important. Each approach has his own particulars but regardless the
processes and tools it is recommended that teams complete all the stages of team formation:
form, storm, norm, perform. Avoiding a bit of ‘storm’ at the beginning can have catastrophic
impact on project. ‘Self-organising’ doesn’t mean lack of discipline but more self-discipline,
from individual learning, like self-study or at least asking for formal training to finances
management as a team. If the team members can’t organise their own tasks and don’t have
the skills, knowledge and experience to complete their tasks it is hard to believe that a team
using an adaptive approach will be successful.

Process
Process is always useful but it should be aligned with the organisation culture and team
maturity. The process should be as formal as needed but more importantly it has to be
understood and accepted, preferably agreed by the team. It is very important, regardless the
adaptive or predictive choice to understand the importance of having a process and choosing
the project delivery approach that is right for you. Agile frameworks were developed, and
worked, in a certain context decades ago. It is unlikely that the success will be repeated in a
different context, like a larger organisation, different business domain or a new technology.
Agile doesn’t have well defined processes for a very good reason: Agile is about embracing
change and while there are recommended practices, the delivery team has the responsibility
and the authority to adapt them. Agile is neither rigid nor dogmatic. There is no ‘you should
do it like this!’. When the existing process works, for example in building a road, a data
centre or relocating an office, it may be better to limit the amount of process change. Not
every project can be delivered in an incremental and iterative manner. Project Managers
should use their skills and experience to recommend the process that has the Abstract

Since the publication of the Manifesto for Agile Software Development in 2001 adaptive
approaches to project delivery gained momentum challenging the traditional predictive,
especially for software development projects. Quite successful for small software development
teams, Agile frameworks caught the attention of Project Managers as a way to improve
the likelihood of a successful delivery. As side but interesting note, Project Managers were
always interested in Agile, since 2006 at least one in 5 respondents of the State of Agile
survey was a Project Manager, a significant and consistent percentage of the respondents,
and in most years even larger than software developers.

However, although Agile is presented as THE solution for today’s rapidly and constant
changing project environment, using Agile practices to manage projects, especially for large
and complex non-technical projects in conservative environments like government and highly
regulated business domains remains a challenge.

33
AGILE PRODUCT DEVELOPMENT End Notes

END NOTES
1
https://www.standishgroup.com/
2
Royce W. (1970) - Managing the Development of Large Software Systems

34