Agile Project Management Explained for Compfest 13

1. AGILE SOFTWARE DEVELOPMENT
COMPFEST 13

3. ABOUT ME
Panji Gautama
SVP Engineering at Mekari
panji@mekari.com
🧑🧑💻 ex-CTO@Kudo, HoE@Grab & VPEng@OVO
👾 ex-Game Programmer for Mobile & Playstation
🎮 avid console gamer PSN @ pgautama
🇯🇵 proud wibu
🔖 scrum master certified 2012

4. Cloud-based Business Platform that Serves
The Best HR, Accounting, and Online Tax Software

5. AGENDA
SDLC
Refreshment
Agile
Frameworks
On Being
Agile
👨
🧑
💼
🏃
🧑
♂️
🧑

6. SOFTWARE DEVELOPMENT LIFE CYCLE
a structured approach to the development workflow with
continuous product improvement in mind

7. TRADITIONAL
SDLC

8. Software Development Life Cycle
1 2
4
3

9. Software Development Life Cycle
5

10. AGILE
SDLC

11. 1st Attempt
● (SAIC) won the bid and created a classic waterfall project
○ $400 Million + $78 Million Additional Funding
○ 300 person team for Requirements + 6 months = 600 pages of listed
requirements
○ 700,000 lines of program code
● 4 Years with no Result
2nd Attempt
● Lockheed Martin wins the new ‘Sentinel’ system a.k.a project 3 years 2006 to 2009.
The total project budget was $425M.
a) $305M was budgeted for Lockheed Martin.
b) $120M was allocated for the FBI to run a massive program office to carry out
detailed and prescriptive oversight of the work
● Abandoned after 3 years
3rd Attempt
● FBI CIO took over, hire Scrum Expert (Jeff Johnson)
● 220 person team reduced to 40
● $20M
● 18 months completed
FBI VCF (Virtual Case File)

12. FBI VCF (Virtual Case File) - LESSON LEARNED
Agile SDLC gets things done.
incremental approach would be faster because
functionality would be developed, and adjustments
made, in two-week "sprints."
he FBI learned that lesson the hard way in October
when the system, during a four-hour test involving
743 users, suffered two outages. The agency made
the mistake of running the test on legacy hardware.
Don't deploy new software on old
hardware
Sentinel came in under its $451 million budget. The
caveat is that the FBI's original cost estimate for
Sentinel was $425 million, it stayed under budget
when changed to Scrum.
Agile SDLC is relatively cheaper
Initially start with custom coding and systems
integration involved. Couple of services changed to
EMC's Documentum document management
software, Oracle databases, IBM's WebSphere
middleware, Microsoft's SharePoint, and Entrust's
PKI technology.
Commercial software plays an
important role

13. TRADITIONAL vs AGILE SDLC
Incremental vs Iterative
Incremental development is a development approach
that slices the product into fully working slices that
are called increments.
Iterative development is when teams gradually build
up the features and functions but don’t wait until
each of these is complete before releasing.
Traditional phase requires different amounts of time
and the involvement of different people. The time
needed will depend on the project, but you will never
see a balanced amount of time spent on each phase.
The agile interpretation of SDLC uses a different unit
of work: Sprints. A sprint is a time-box for completing
a body of work. It has a consistent duration
regardless of the work.
Sprints vs Phases
A traditional view of SDLC isn’t flexible. During the
development process, new findings don’t get
incorporated into previous steps.
The more agile view of SDLC, however, is flexible.
With frequent change anticipated, you can introduce
a brand new body of work in the next sprint that
bears no relation to the previous sprint’s work.
Change is less expensive.
Flexibility
Tracking a project managed with waterfall is
relatively straightforward. Any given project will be in
one of seven phases at any given time.
Agile doesn’t use the term project in the same way.
With this approach, a single team is generally
working on a specific product or a service, but might
have several projects on their plate at the same time.
Project Tracking

15. AGENDA
SDLC
Refreshment
On Being
Agile
👨
🧑
💼
🏃
🧑
♂️
Agile
Frameworks
🧑

17. AGILE
is NOT
SCRUM

18. AGILE MANIFESTO / VALUES
https://agilemanifesto.org/
That is, while there is value in the items on
the right, we value the items on the left more.

19. AGILE PRINCIPLES
https://agilemanifesto.org/principles.html
1 Our highest priority is to satisfy the
customer through early and continuous
delivery of valuable software.
2 Welcome changing requirements, even
late in development. Agile processes harness
change for the customer's competitive
advantage.
3 Deliver working software frequently,
from a couple of weeks to a couple of months,
with a preference to the shorter timescale.
4 Business people and developers must work
together daily throughout the project.
5 Build projects around motivated
individuals. Give them the environment and
support they need, and trust them to get the
job done.
6 The most efficient and effective method of
conveying information to and within a
development team is face-to-face
conversation.
7 Working software is the primary measure
of progress.
8 Agile processes promote sustainable
development. The sponsors, developers, and
users should be able to maintain a constant
pace indefinitely.
9 Continuous attention to technical
excellence and good design enhances agility.
10 Simplicity -- the art of maximizing the
amount of work not done--is essential.
11 The best architectures, requirements,
and designs emerge from self-organizing
teams.
12 At regular intervals, the team reflects
on how to become more effective, then tunes
and adjusts its behavior accordingly.

20. Agile generally promote a
disciplined project
management process that
encourages frequent
inspection and adaptation.
scrum is only one of ragile
framework.

21. Assign the role of
Product Owner
Schedule frequent
meetings
Hold regular
reviews
Small Is Best - Time,
Scope and Team
The project was
deliberately kept
small, both in terms
of scope and the
number of people
involved.
Scope was fixed and
relatively small and
was kept this way
higher chance of
success.
a person in team who
will look after the
particular
requirements of
product users but
also the business
needs.
Apply the necessary
changes in the
workflow or even the
product.
Short frequent
meetings to discuss
goals & update the
team about all the
important things they
need to keep in mind
while completing
other tasks.
It’s smart to meet up
at the end of every
week to show what
each team member
has done and review
all the the things
delivered.
BEING AGILE WITHOUT SCRUM

22. AGENDA
SDLC
Refreshment
On Being
Agile
👨
🧑
💼
🏃
🧑
♂️
Agile
Frameworks
🧑

24. POPULAR AGILE FRAMEWORKS
SCRUM
fairly structured process that
involves self-organized teams
who commit to specific
deliverables, meet daily and
break their work into iterations.
Extreme Programming
goal-oriented; you set a goal for
the team, they work until that goal
is completed, and you iterate on
the results.
Kanban
adaptation of lean manufacturing
principles, and primarily focuses
on limiting the amount of work-in-
progress to facilitate high-quality
work.

25. SCRUM 101
https://scrumguides.org/
2 recognised Scrum training organisations
Scrum.org & Scrum Alliance

27. SCRUM ROLES
Development Team
development team can be comprised of all kinds of people including designers, writers,
programmers, etc.
responsibilities:
● Delivering the work through the sprint.
● To ensure transparency during the sprint they meet daily at the daily scrum
Product Owner
The business is represented by the product owner who tells the development what is
important to deliver.
responsibilities:
● Managing the scrum backlog
● Release management
● Stakeholder management
gluing everything together and ensuring that scrum is being done well.
responsibilities:
● Transparency
● Empiricism
● Self Organization
● Values
Scrum Master

28. SCRUM ARTIFACTS
Product Backlog
The product backlog is a list of
new features, enhancements, bug
fixes, tasks, or work requirements
needed to build a product.
It’s compiled from input sources
like customer support, competitor
analysis, market demands, and
general business analysis.
Sprint Backlog
The sprint backlog is a set of
product backlog tasks that have
been promoted to be developed
during the next product
increment.
Sprint backlogs are created by
the development teams to plan
deliverables for future increments
and detail the work required to
create the increment.
Product Increment
A product increment is the
customer deliverables that were
produced by completing product
backlog tasks during a sprint. It
also includes the increments of all
previous sprints.

31. SPRINT
PLANNING
● Attendees: Development team, scrum master, product owner
● When: At the beginning of a sprint.
● Duration: Usually up to two hours per week of iteration. e.g. a two-week sprint kicks off with a four-hour
planning meeting.
● Purpose: Sprint planning sets up the entire team for success throughout the sprint.
○ Coming into the meeting, the product owner will have a prioritized product backlog. Use the sprint
planning meeting to flesh out intimate details of the work that needs to get done.
○ Encourage team members to sketch out tasks for all stories, bugs, and tasks that come into the sprint.
SCRUM CEREMONIES
DAILY
SCRUM
● Attendees: Development team, scrum master, product owner
● When: Once per day, typically in the morning.
● Duration: No more than 15 minutes.
○ Don't book a conference room and conduct the stand up sitting down.
○ Standing up helps keep the meeting short!
● Purpose: Stand-up is designed to quickly inform everyone of what's going on across the team. It's not a
detailed status meeting.
○ What did I complete yesterday?
○ What will I work on today?
○ Am I blocked by anything?

32. SPRINT
REVIEW
● Attendees: Development team, scrum master, product owner, Product Stakeholders (optional)
● When: At the end of a sprint or milestone.
● Duration: Typically 60 minutes per week of iteration-e.g. a two-hour review following a two-week sprint.
● Purpose: Sprint review is a time to showcase the work of the team.
○ time for the team to celebrate their accomplishments
○ demonstrate work finished within the iteration
○ get immediate feedback from project stakeholders
SCRUM CEREMONIES
SPRINT
RETRO
● Attendees: Development team, scrum master, product owner
● When: At the end of an iteration.
● Duration: Typically 45 minutes per week of iteration-e.g. a 90-minute retrospective after a two-week sprint.
● Purpose: Agile is about getting rapid feedback to make the product and development culture better.
Retrospectives help the team understand what worked well–and what didn't.

33. Epic & User
Story
Story Points Burn Down Velocity &
Capacity
DOR & DOD
It is a short and clear
description of feature, that
will give user (minimal)
real value.
Story point is a tool for
relative estimation.
It estimates the effort to
make a task done from 3
points: time, complexity
and uncertainty.
DOR or Definition of
ready and DOD or
Definition of Done are
the checklists useful for
understanding the work
direction.
a line chart drawn
between remaining work
and time.
average & future team
performance in story
points
SCRUM IMPORTANT CONCEPTS
🧑 🧑 📋 📈 🧑
🧑

34. USER STORY EPIC
have a lifespan of multiple sprints and cannot be considered
complete until all stories based on them are also complete.
As a: content-contributor
I want to: categorize the content I create
So I can: ensure that readers can easily locate it
It is a short and clear description of feature, that will
give user (minimal) real value.
USER STORY
most granular description of functionality. Stories describe
deliverables that can be completed in a single sprint.
As a: experienced-end-user
I want to: Save my work using a command-key sequence
So I can: Quickly save my work without multiple clicks
SAGA

35. STORY POINTS Measurement
Typical be done in Fibonacci sequence 1, 2, 3, 5, 8 or in T-
Shirt sizes S, M, L, XL
Story point is a tool for relative estimation. It estimates
the effort to make a task done from 3 points: time,
complexity and uncertainty.
Story points vs Mandays
● Relative Story Point estimates are quicker and easier to do.
Estimating directly in man-days often leads us to get into
too much detailed thinking.
● The team often cannot agree on them because they depend
upon the speed with which people will do the work
● If the team changes the way that they are working (for
example, perhaps they are going to start automating their
testing) then if they have estimated in man-days, they will
have to re-estimate every item

36. 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.
SCRUM POKER

37. https://www.parabol.co/blog/agile-estimation-techniques

38. Backlog Refinement
In backlog refinement the team looks one or two sprints out to see what is coming up and prepares
these stories to be brought into a sprint. Estimation is a common thing to happen here because the
act of trying to estimate the story often brings out details about the story.
Release Planning
This is a planning that takes a high-level look at the next few months and I've worked with many
teams that take a first-guess estimate at all stories in the release planning. It is understood in these
teams that these estimates are rough guesses used for general planning purposes and they usually
revisit the estimates in a Backlog Refinement closer to actually working the item.
Sprint Planning
It isn't common practice anymore to estimate right at sprint planning, but it still happens sometimes.
Usually, this happens with stories that emerge right before the sprint (maybe a gap discovered in the
last Sprint Review). This estimate is usually done at this time in order to weigh the cost/value benefit
before deciding to bring it into the sprint.
WHEN TO ASSIGN STORY POINT ?

39. DoR Sample
● The conditions of satisfaction have been fully identified
for the story.
● The story has been estimated and is under a certain
size. For example, if the team is using story points, a
team might pick a number of points and only allow
stories of that size or smaller into the iteration. Often this
maximum size is around half of the team’s velocity.
● The team’s user interface designer has mocked up, or
even fully designed, any screens affected by the story.
● All external dependencies have been resolved, whether
the dependency was on another team or on an outside
vendor.
Definition of ready a set of agreements that lets
everyone know when something is ready to pick up,
e.g., when a user story is ready to be taken into a sprint

41. DoD
Definition of Done is an agreed-upon set of items that
must be completed before a project or user story can
be considered complete.
Sample
● Code is peer-reviewed
● Code is deployed to test environment
● Code/feature passes regression testing
● Code/feature passes smoke testing
● Code is documented
● Help documentation is updated
● Feature is OK’d by stakeholders

42. Burndown BENEFIT
● provides an updated status report on the progress of the
project
● visual representation of this most important data keeps
everyone on the same page
● encourages the team to deal with issues before they
become problems.
● relies on good estimates & discipline
a graphical representation of work left to do versus
time. The outstanding work (or backlog) is often on the
vertical axis, with time along the horizontal.
TIPS
● If you notice that the team consistently finishes work early,
this might be a sign that they aren't committing to enough
work during sprint planning.
● If they consistently miss their forecast, this might be a
sign that they've committed to too much work.
● If the burndown chart shows a sharp drop during the
sprint, this might be a sign that work has not been
estimated accurately, or broken down properly.

43. BURNDOWN ANTI-PATTERN
https://age-of-product.com/burn-down-charts/

44. 1. Epic menu: Select which epic to view data
for.
2. Work added: The dark blue segment shows
the amount of work added to the epic in each
sprint. In this example, work is measured in
story points.
3. Work remaining: The light blue segment
shows the amount of work remaining in the
epic.
4. Work completed: The green segment
represents how much work is completed for
the epic in each sprint.
5. Projected completion: The report projects
how many sprints it will take to complete the
epic, based on the team's velocity.
EPIC BURNDOWN

45. Velocity & Capacity
Velocity is an average team performance in story
points based on previous sprints statistics.
Capacity is future team performance in story points
based on the team’s availability — there may be an extra
holiday next sprint or someone will go on vacation.

49. SCRUM LEGO GAME
https://www.agile42.com/en/agile-teams/scrum-lego-city/

50. KANBAN 101
https://www.atlassian.com/agile/kanban

52. Visual Signals Columns Commitment
Points
Delivery Points
WIP Limits
visual cards (stickies,
tickets, or otherwise).
Kanban teams write all of
their projects and work
items onto cards, usually
one per card.
For agile teams, each
card could encapsulate
one user story.
Each column represents a
specific activity that
together compose a
“workflow”.
Cards flow through the
workflow until completion.
Workflows can be as
simple as “To Do,” “In
Progress,” “Complete,” or
much more complex.
maximum number of
cards that can be in one
column at any given time.
A column with a WIP limit
of three cannot have
more than three cards in
it.
The commitment point is
the moment when an idea
is picked up by the team
and work starts on the
project.
Delivery point is when the
product or service is in
the hands of the
customer.
KANBAN 5 COMPONENTS

53. KANBAN CARDS
VIEW IMPORTANT DETAILS AT A
GLANCE
Each kanban card typically features a brief description of a
work item, along with its owner, due date, and status. The card
can include other information, like pointers to source
documentation or a list of issues blocking the item's progress.
kanban card represents a single work item as it moves
through various stages of completion which are
represented onkanban board.
HAND OFF DELIVERABLES
SMOOTHLY AND EFFICIENTLY
Kanban cards encourage teams to establish clear and
consistent expectations for each functional area.
IMPROVE EFFICIENCY
Kanban cards make it easy to keep track of lead time, which is
the time it takes for a work item to go from start to finish.
Kanban cards, together with a kanban board, can help teams
identify bottlenecks in their workflow and streamline their
process

58. KANBAN VS SCRUM

59. SCRUMBAN 101

60. KANBAN VS SCRUM VS SCRUMBAN

61. TOOLS
JIRA TRELLO

62. TOOLS
TAIGA.io OPENPROJECT.org

63. THREE STAGES OF TEAM
🃏 Generalists 🧑 Platforms 🧑 Products

64. SPOTIFY MODEL

67. THANK YOU
Follow us on Instagram @lifeatmekari and LinkedIn “Mekari” for info on our next events and
updated job vacancy (monthly)
Visit our career page at mekari.com/careers to explore more opportunities with Mekari