11/9/2021

Digital Product and Project Management

Agile: Values, Principles and Practices

Atanu Ghosh
[email protected]

The Fundamental Question

Is managing a Software Project

fundamentally different from
managing other types of projects?

We will try to answer this question in this session.

While doing this we will talk with reference to software used for
business process applications. However, most of these principles also
apply to managing other types of software like system software or
developing software products, etc.

1
 11/9/2021

Software – Early Days and

Challenges of “Growing Up”
• Early software were primarily used for research and scientific applications and
subsequently in defence applications.

• They were created and used by a specialised few. Software were like a precious craft
built by skilful craftsmen for consumption of the elite.

• Hence, there was little need to manage the process of creation and use of software.
Management is required when things are done at scale.

• Challenge came when software started to be used to automate and re-engineer

business processes of industries.

• Now software needed to be created by an army of programmers (because of the vast

range of application) and used by a large and diverse group of “users” who has little
or no acquaintance with computers.

• Need to “manage” the process of creation, deployment and maintenance of software

emerged.

• Challenge deepened during Y2K for large scale changes required on existing
programs.
3

Software – Early Days and

Challenges of “Growing Up”

• Software engineers looked at models adopted primarily by two industries to manage

the “process” of creation, deployment and maintenance of software projects -
Manufacturing (including Defence Manufacturing) and Construction. These were the
industries where projects were being executed in scale.

• Many software project managers in those days (and it continues these days also in some
cases) were those who had successfully managed large projects in defence,
manufacturing and construction sectors, and were not necessarily from software
industry.

• Management models adopted by some other industries like Healthcare, Education,

Media and Entertainment were not considered. Probably because
• The scale of operations in these industries were perceived to be smaller compared
to the rapidly scaling software industry.
• These industries were not considered as benchmark in terms of modern
management principles and practices which can be adopted for the emerging
software industry.

• Was this a “historic blunder”? We will explore…

2
 11/9/2021

Software Project Management –

Fundamental Differences

What do you think are the fundamental differences

between Software Project Management and other
types of Project Management?

Software Project Management –

Fundamental Difference

1. Invisibility
2. Indefinability
3. Orthogonality (lack of)
4. Replicability (lack of)
5. Modularity (lack of)
6. Measurability (lack of)
7. Predictability (lack of)
8. Maintainability (lack of)
9. Flexibility
10.Complexity

3
 11/9/2021

Waterfall Model

Source: Wikipedia
7

Waterfall Model –
History and Characteristics
1. Linear sequential approach to software development.

2. Originated from manufacturing and construction industry where change

becomes prohibitively expensive very soon in development cycle.
Software industry adapted this model presumably because of lack of any
viable alternative.

3. Known to be used since 1956.

4. However, first formally cited by Winston W Royce (1929-1995, Computer

Scientist, Director of Lockheed Software Technology Centre) in 1970 in an
article in connection with a US Defence project named “SAGE”.

5. The model gained popularity when US Department of Defense used this

model to work with its software contractors.

6. Royce did not use the term “waterfall”. Royce presented it as a flawed
model. The term was first formally used by Bell and Thayer c. 1976.

7. BDUF (Big Design Upfront) vs RDUF (Rough Design Upfront)

8

4
 11/9/2021

Agile: Definition

Agile is a software development philosophy

where requirements and solutions evolve
through a collaborative effort of self organising
and cross-functional teams consisting of
developers and customers/ users.

Note: Agile by itself is not a software development method. It supports

methods based on agile values and principles.

Evolution of Agile

Transformation
Unsuitability of from IT to Digital
Software Inclusion
manufacturing Productisation Economy
Dev in Scale (“stakeholder BPR
model “2 Speed IT”
win condition)

Waterfall SSDAM IID Spiral RAD ERD Agile

(1970) (c.1975) (c.1980) (1986) (c. 1990) (c. 2000) (c. 2001)

Character: Character: Character: Character: Character: Character: Character:

Structure Extreme Flexibility Prototype JAD Reusable Extreme
Structure templates Flexibility

10

5
 11/9/2021

Agile Value #1

Individuals and Interactions

over Processes and Tools

11

Agile Value #1

Individuals and Interactions over Processes and Tools

• Tools and processes are necessary but not sufficient in

development of software.

• It is more important to have competent and trusted people

working on the tools and processes.

• Good processes managed by incompetent and/or untrusted

people lead to compromised and/or manipulated processes and
hence suboptimal or even negative end result

12

6
 11/9/2021

Agile Value #2

Working Software over

Comprehensive Documentation

13

Agile Value #2

Working Software over Comprehensive Documentation

1. Good document is useful. But the main objective of a software project is to

create software, not documents.

2. Thus, progress of a software project must be measured in terms of

progress of software developed and not that of documents produced.

3. Documentation does not mean paper documentation only. Documentation

is a record. Working prototypes, audio and video recordings of
discussions, screenshots and recording are all valid documentation.

4. Document everything that is happening in the process of software

development on real-time basis (through audio, video, screenshot, etc.) so
that documentation is always updated and separate effort required for
documentation is minimised.

14

7
 11/9/2021

Agile Value #3

Customer Collaboration over

Contract Negotiation

15

Agile Value #3

Customer Collaboration over Contract Negotiation

1. Contract is important, but cannot substitute close working together.

2. Contract is meant for managing scope of work and differences at

macro level e.g. for which plants the software will be implemented,
what happens if there is a fire in the plant, how will the intellectual
property of the client and the service provider be protected, etc.
Such macro issues are rare and accidental. Hence contract is meant
to be used in rare occasions, most cases never to be used.

3. Day to day issues at micro level like making a modification to a

report, how to manage when a critical resource leaves before go-
live, delay in payment by a month, etc. cannot be managed through
contracts. It requires trust and collaboration to manage such day to
day issues.
16

8
 11/9/2021

Agile Value #4

Responding to Change over

Following a Plan

17

Agile Value #4

Responding to Change over Following a Plan

1. A project plan is important. But stakeholder’s priorities and

adapting to change in technical environment is above the plan.

2. In a VUCA environment make strategic plans long term and

operational plans short term (2 to 4 week horizon)

“Keep breaking your time frames down into smaller chunks. Instead of
one twelve-week project, structure it as twelve one-week projects. Instead
of guesstimating at tasks that take thirty hours or more, break them down
into more realistic six-to-ten-hour chunks. Then go one step at a time.”

From the book Rework by

Jason Fried and David Hansson (founder of Ruby on Rails)

18

9
 11/9/2021

12 Principles of Agile Software Development

The Agile Manifesto has outlined 12

Principles of Agile Software Development

19

Principle #1

Customer satisfaction by early and

continuous delivery of valuable software

Challenges: Paper documentation

20

10
 11/9/2021

Principle #2

Welcome changing requirements, even

in late development

Challenges: Waterfall model

21

Principle #3

Working software is delivered frequently

(in weeks rather than in months)

Challenges: Detailed long term plans

22

11
 11/9/2021

Principle #4

Close, daily cooperation between

business people and developers

Challenges: Formal communications over

mails as primary mode of communication

23

Principle #5

Projects are built around motivated

individuals, who should be trusted

Challenges: Notion of process over people

24

12
 11/9/2021

Principle #6

Face to face conversation and

co-location is the best method of
ensuring communication

Challenges: Offshore delivery

25

Principle #7

Working software is the primary

measure of progress

Challenges: Review through project

plans (e.g. MS-Project plans) on paper

26

13
 11/9/2021

Principle #8

Sustainable development, ability to

maintain constant pace

Challenges: Resource sharing across

multiple projects

27

Principle #9

Continuous attention to technical

excellence and good design

Challenges: Importance of process

knowledge over technical know-how

28

14
 11/9/2021

Principle #10

Simplicity, the art of maximising

the amount of work not (to be)
done, is essential

Challenges: Fixed scope

29

Principle #11

Best architecture, requirements and

design emerge from self-
organising teams

Challenges: Manufacturing industry

inspired project management structure

30

15
 11/9/2021

Principle #12

Regularly, the team reflects how to

become more effective and adjusts
accordingly

Challenges: Classical estimation method

31

Software Development Methods

based on Agile Values

Many software development methods have evolved based

on Agile values and principles.

1. Dynamic Systems Development Method (DSDM)

2. Scrum
3. Extreme Programming (XP)
4. Feature Driven Development (FDD)
5. Lean Software Development
6. Kanban
7. Scrumban

32

16
 11/9/2021

Agile at Scale

One of the common criticisms about Agile is that it works

well for small incremental non mission critical projects.
However, methods based on Agile values fail to deliver for
large enterprise level projects.

To counter this critique in recent years few software

development methods have evolved. They focus on
deploying methods based on Agile values at scale.

1. Scaled Agile Framework (SAFe)

2. Disciplined Agile Delivery (DAD)
3. Large Scale Scrum (LeSS)
4. Scrum at Scale
5. Enterprise Scrum
33

Agile Practices

Different software development methods based on Agile

values and principles use different Agile Practices.

We will discuss some of the popular ones which are used

in most methods.

34

17
 11/9/2021

Agile Practice # 1

User Stories

35

User Stories

• User Stories are description of one or more features of a software written from an end user
perspective in an informal natural language.

• User Stories must not be confused with System Requirement. System requirements are formal
description of user needs. User stories are informal narrative by a user of software features.

• User Stories are also not Use Cases, though there are some similarities. While both may be written
in narratives, Use Cases are formal detailed documents describing a sequence of events that a
system may encounter depending on various business inputs. User Stories are informal and not
detailed. Details evolve from discussions around User Stories.

• The term “User Stories” was first used by Alistair Cockburn (one of the founding members of The
Agile Manifesto) in Chrysler C3 Project (1998): “A user story is a promise for conversation”

• Subsequently, Ron Jeffries proposed the 3C Formula for User Story creation:

• The Card: A physical durable token (often a Post-It Note) to hold the user stories

• The Conversation: Some documented, but mostly verbal, between the stakeholders i.e.
users, developers and testers

• The Confirmation: To ensure that the objectives of the conversation are met

36

18
 11/9/2021

Connextra Format for User Stories

1. There are many formats for creating User Stories. Connextra is

one of the most popular ones.

2. Connextra Format is based on 3 Rs. 3rd R is optional.

• Role
• Requirement (Feature)
• Reason

3. Format:

As a ________________ (role), I want __________________

(requirement/ feature/ output), so ___________________ (reason)

37

User Stories Using Connextra Format

Example:

As a Faculty, I want to have a Chat Box so that I can answer queries

from students, individually and collectively.

Quiz:

Assume that you and your team are entrusted with developing an
online grocery portal similar to Salt n Soap (saltnsoap.com). Can you
create a simple User Story for the portal?

38

19
 11/9/2021

User Stories Using Connextra Format

User Story 1: As a shopper, I want to search products by category and

brand.

User Story 2: As a shopper, I want to find the products on deal fast so that I
can save on my grocery bill.

User Story 3: As a shopper, I want to add many products in the cart without
opening multiple pages of the website so that I can save time on creating the
shopping cart.

User Story 4: As a shopper, I want to see the content of my shopping cart

anytime including the products, number of units, per unit price and total
price, grand total price, shipping cost and any other cost so that I can make a
decision whether to purchase any more product, add or reduce quantities or
remove any product from the shopping cart.

User Story 5: As a category manager, I want to add new products with their
prices and discount, if any, so that they can be discovered by shoppers.
39

Epic

• Epic is a big user story.

• Example (for Salt n Soap):

As a shopper I want to buy my grocery online to

save time and reduce hassle.

40

20
 11/9/2021

Task

• Tasks are steps to implement User Stories.

• Example (for Salt n Soap):

• User Story: As a shopper, I want to search

products by category and brand.

• Task: Create a Wireframe on Photoshop to

show how a user will search for product by
category and brand

41

Agile Practice # 2

Time Box-ing

42

21
 11/9/2021

Time Box-ing

1. Time Box-ing is a planning activity for software projects delivered on

agile values.

2. In this method time (deadline) is fixed for a particular set of activities.

3. This is in sharp contrast to traditional SDLC where there is a attempt

towards a “fixed scope” project. Any change to the fixed scope defined at
early stages of the project has to go through a change control board.

4. What happens if a set of activities cannot be completed within the

timebox?
• Drop the requirements which has lower impact
• On the other hand, in a fixed scope scenario either the deadline will
slip or additional resources will be put in to finish the activities. The
latter may not result in finishing the activities within the deadline or
quality may be compromised (refer to The Mythical Man-Month)

43

Agile Practice # 3

Pair Programming

44

22
 11/9/2021

Pair Programming

1. Two programmers work together on the same piece of work at the same
workstation.

2. At any point of time one programmer is a driver who writes the code while the
other programmer is a observer or reviewer who reviews every piece of code as
it is typed in.

3. The two programmers are expected to switch roles frequently.

4. Because Pair Programming takes code review to an “extreme” level of seriousness,

Pair Programming is an integral part of Extreme Programming (XP) method.

5. Pair Programming increases the man-hours required to deliver a code compared

to programmers working individually. However, Pair Programming is still
considered advantageous because of

• Reduced defects and hence significantly reduced cost of rework

• Reduced risk on account of attrition as two programmer are always aware of
the code at any point of time

45

Pair Programming

Types of Pair Programming

• Expert – Expert – Apparently the most obvious choice, expected

to give the highest productivity; but can increase cost, also has the
risk of conflicts and lack of innovation or new approach

• Expert – Novice – Balanced pairing, lower cost, creates

opportunity for expert to mentor the novice thus reducing the risk
of attrition, but can become ineffective if the novice gets
intimidated or is lazy and falls into the trap of “watch the master”

• Novice – Novice (University Hires) – Lowest cost, can provide

innovative and new approach; but has the risk of under-delivery
and low quality

46

23
 11/9/2021

Agile Practice # 4

Sprint

47

Sprint

• Sprint is a unit of iteration.

• Unlike “phases” of classical SDLC, Sprints occur in a

shorter timeframe – maximum 4 weeks, usually 2 weeks.

• Sprints are time boxed.

• Sprints start with Sprint Planning

• Sprints end with Sprint Review and Sprint

Retrospective

48

24
 11/9/2021

Sprint Planning

• Usually a 4 hour time-boxed meeting for a 2 week Sprint. For shorter

or longer sprints, the planning meeting is on pro-rata basis

• First half – selection of Sprint Backlog from Product Backlog by all

team members (developers, scrum master and product owners)

• Second Half – identification of tasks to complete the Sprint Backlog.

Estimation done by Planning Poker (or Story Points)

• In case time is up before selecting (in first half) or confirming (in

second half) all the backlogs, only the backlogs discussed are taken
in the Sprint and the rest are left as backlogs to be dropped or taken
up in next sprint.

49

Sprint Closure

• Sprint Closure is done through 2 activities – Sprint Review and

Sprint Retrospective

• Sprint Review

• Recommended duration – 2 hour for a 2 week sprint.

• Demo of work completed. Incomplete work cannot be put up
for demo
• Work in “Done” state confirmed
• Planned but not completed work moved to “To Do” state

• Sprint Retrospective

• Recommended duration – 1.5 hour for a 2 week sprint

• Identification of continuous process improvement actions

50

25
 11/9/2021

Agile Practice # 5

Product

51

Product

• Product is the software to be delivered.

• Agile philosophy propounds managing software development is

akin to a new product development rather a mass manufacturing
process.

• Thus Agile philosophy embraces “fuzziness” and change during

SDLC just like new product development stage.

• It also acknowledges that every software is a new product and

should be developed as such.

• In projects managed on Agile values, the user group is represented

by Product Owner instead of Project Sponsor.

52

26
 11/9/2021

Agile Practice # 6

Story Point

53

Story Point

• Story Point is consensus based abstract estimation of Backlogs on a relative scale often
implemented through gamified techniques like using Poker Cards.

• Story Point is defined in terms of numbers usually organised in Fibonacci sequence (0, 1,
1, 2, 3, 5, 8, 13, 21, 34, 55, 89, …).

• Reason for using Fibonacci sequence for Story Point is the inherent uncertainty in
estimating larger items.

• In Sprint Planning stage all members collectively agree the number of story points that
can be covered during the Sprint. Over a period of time this can get standardised for a
sprint of a specific time box (say, 2 weeks).

• Then the members select the Product Backlog Items (PBIs) in order of priority till the
story points add up to that can be completed during the Sprint. This is aligned to time
box-ing technique where time is fixed and scope is adjusted according to time available.

• Note: By legitimising Story Point estimation technique Agile inherently accepts the
inability to estimate software development work in terms of man months. This was the
same sentiment expressed in The Mythical Man Month.

54

27
 11/9/2021

Story Point: Exercise

Let us take the following User Stories. Let us consider a 2 week Sprint when the Task of creating a
wireframe for each User Story is taken up. Assume total Story Points that can be taken up in the Sprint
is 100. Estimate the Story Point for the Task taken up in the Sprint for each User Story.

User Story 1: As a shopper, I want to search products by category and brand.

Story Point: ?

User Story 2: As a shopper, I want to find the products on deal fast so that I can save on my grocery
bill.
Story Point: ?

User Story 3: As a shopper, I want to add many products in the cart without opening multiple pages of
the website so that I can save time on creating the shopping cart.
Story Point: ?

User Story 4: As a shopper, I want to see the content of my shopping cart anytime including the
products, number of units, per unit price and total price, grand total price, shipping cost and any other
cost so that I can make a decision whether to purchase any more product, add or reduce quantities or
remove any product from the shopping cart.
Story Point: ?

User Story 5: As a category manager, I want to add new products with their prices and discount, if any,
so that they can be discovered by shoppers.
Story Point: ?
55

Planning Poker: Eliminating Bias

1. Cognitive Bias of Anchoring is a problem in Story Point

method of estimation. CBA arises when rest of the team
follows the estimate of the person who gave the first
estimate.
2. To eliminate the bias, members of the group estimate by
placing a poker car containing his/ her estimate of story
point upside down.
3. Everyone calls their cards simultaneously by turning them
over.
4. Outliers (members with exceptionally high or low
estimates) are given a soap box to explain their estimate.
5. The process is repeated till a consensus is reached. The
developer who is likely to own the task may have a larger
portion of consensus vote.
6. One member plays the role of a Moderator. Moderator does
not play.
7. To timebox each round the Moderator may turn over the
egg timer to indicate start of next round.
8. For geographically distributed teams digital artefacts like
mobile apps can be used instead of physical artefacts.

56

28
 11/9/2021

Agile Practice # 7

Backlog

57

Backlog
• Backlog is an ordered list of incomplete (not done) user stories.

• Backlog list is ordered based on priority to complete.

• MoSCoW Principle of allocating priority to Backlogs

• Must Have
• Should Have
• Can Have
• Won’t Have

• Priority to complete can be based on value, urgency, size, risk.

Responsibility of prioritisation is with Product Owner.

• Product Backlog is what will be delivered, ordered into sequence in which

it should be delivered.

• User Stories in a Product Backlog that is planned to be done in one Sprint

is called a Sprint Backlog.
58

29
 11/9/2021

Sprint Backlog

• Sprint Backlog is prepared by selecting Product Backlog Items

(PBIs) in order of priority from top of the list one by one until there
is enough work to fill the Sprint.

• Note how time is made the independent variable and scope the
dependent variable in Agile value in sharp contrast to traditional
SDLC where scope is the independent variable and time is
estimated based on scope by using different estimating
techniques.

• Estimation of time required for Backlog is done through Planning

Poker or Story Point method.

• By using the term Backlog, Agile legitimises the fact that all work
may not be completed in a timeboxed Sprint and will be carried
forward in the next Sprint as “backlogs.”

59

Backlog Refinement

• Backlog Refinement is the process of reviewing Product Backlogs

so that they are appropriately defined and prioritised before they
enter into Sprint Backlog

• This ensures the quality of User Stories defined and any change in
User Stories that might need to be accommodated before they
become Sprint Backlog on whom developers will work.

• Backlog Refinement includes paying off Technical Debt (also called

Design Debt or Code Debt)

• Technical Debt is the rework that might be required later due to

deliberately choice of an easy solution or a workaround because
the better solution will take more time or effort or the path to the
better solution is not exactly known at this point

60

30
 11/9/2021

Agile Practice # 8

Daily Scrum/ Stand Up

61

Scrum in Rugby

• Scrum is a short form of scrummage which means searching through junk

in an organised manner.
• Scrum is extensively used in Rugby.
• Scrum in Rugby means a method to restart the game where the players
of both sides huddle with heads down and attempt possession of the
ball.
• One of the players a tad outside the pack introduces the ball in the pack
62

31
 11/9/2021

Daily Scrum or Stand Up

• Daily Scrum is a daily time boxed meeting at a

fixed time and fixed place for the entire
duration of the Sprint.

• All members are expected to attend standing

up to ensure meetings are not lengthened.
Hence they are also called Daily Stand Ups.

• Daily Scrums are usually time boxed to 15 mins

• Do not confuse Daily Scrum with Scrum. The

latter is a methodology on Agile values.

• Each team member is expected to answer 3

questions
1. What did I complete yesterday?
2. What do I plan to do today?
3. Do I see any impediment?
63

Agile Practice # 9

Kanban

64

32
 11/9/2021

Kanban in Manufacturing Industry

• Kanban (看板) (meaning signboard or billboard in Japanese) is a lean manufacturing technique

based on just in time principle.

• First introduced by Taiichi Ohno in Toyota.

• Kanban ensures unhindered flow of materials and minimum inventory build up through supply
chain by ensuring that materials move downstream only a signal is received from downstream that
there is available capacity to process the material for the next stage.

• Since in this process materials arrive “just in time” when the manufacturing facility is released for
production of next lot, Kanban is a method to facilitate Just in Time.

• Upstream facility understands whether the capacity of downstream facility is available or full to
process the next lot by visual cards (Kanban) displayed on each workstation and visible from a
distance. Hence the name of this technique is Kanban. Now, of course, such signals are passed on
through computerized systems.

• Kanban thus works on pull from downstream entity rather than push from upstream entity.

• Any inventory build-up, if at all, is pushed upstream thereby ensuring that the value locked in the
inventory is lower.

• Kanban is applied for both internal and external supply chain.

65

Kanban in Manufacturing

66

33
 11/9/2021

Kanban in Manufacturing

67

Kanban in Software Development

68

34
 11/9/2021

Kanban in Software Development

69

Roles

Software Projects delivered on Agile values have a

different set of roles for team members compared to
that in traditional software delivery.

70

35
 11/9/2021

Product Owner

• Product Owner represents the products stakeholders and is the “voice of

the customer”.

• Product Owner roughly maps into Project Sponsor role in traditional

software project management method. However, unlike Project Sponsor,
Product Owner is a part of the team and in most cases is a full time role.

• There is only one Product Owner

• Some of the responsibilities of Product Owner includes

• Demonstrating solution to key stakeholders

• Defining and announcing releases
• Communicating team status
• Organising milestone reviews
• Educating stakeholders in development process
• Negotiating priorities, scope, funding and schedule
• Ensuring that product backlog is visible, transparent and clear

71

Scrum Master

• A Scrum is facilitated by a Scrum Master

• Scrum Master’s primary role is to remove impediments in the ability of

the development team to deliver as per sprint plan

• Thus a Scrum Master is NOT a Team Leader or a Project Manager in

traditional software delivery. A Scrum Master is a buffer between the
team and any distracting influence.

• Some of the usual responsibilities of a Scrum Master

• Helping the team to remove or avoid impediments
• Assisting the Product Owner to maintain Product Backlog
• Helping the team to create the Definition of Done (DoD) for the
product with input from key stakeholders
• Promoting self organising and cross functionality within the team

• Do you see the shift of governance model of software delivery from

manufacturing/ construction industry to other types of industry whose
governance models we discussed in last class?
72

36
 11/9/2021

Developers

• Team of software engineers responsible for delivery of sprint backlogs

• Developers may perform different tasks like coding, testing, etc. but they
are collectively called developers

• Development team is self organising

• Usually a development team consists of 3 to 9 members

• Can you list some of the key differences in roles with traditional software
project governance structure?

73

Roles: Differences with Traditional

Software Projects

• No Project Manager/s. Only Product Owner

• There can be a Project Management Office (PMO) to provide

facilities and resources to developers

• Scrum Master is not the Project Manager. Developers do not

report into Scrum Master. Scrum Master is at best a “servant
leader”

• No Team Leaders

• No other Roles apart from Developers like no role as Quality

Assurance Manager, Tester, etc.

74

37
 11/9/2021

Thank You

38