Agile Fundamentals

04 January 2023 17:40

When there is need of rapid delivery and customer requirement changes

Frequently then we should go for agile.

We get the frequent version of agile.

Agile methodology :
we see every product as unique and we do the development customised way.
When customer is confused. So in every product developed In iterative way in iterative way
In every phase there need to check use requirement analysis.

More focused in initial stages.

There are so many agile methodology :

agile Page 1
Scrum is used for soft development
In this it divides the develop. into short cycles called sprint
Cycles.
duration of Sprint Cycle would be 2-4 weeks.
Each day of sprint cycle starts with meeting discussed about the progress
Scrum team is composed of :
Product owner :
client / customer
Scrum master:
communication and collaboration between leadership and team players to ensure a successful outcome.
coordinating the meeting every process and remove barrier.
Team member :
programmer , designer , tester , architect.

Daily scrum :
Is meeting discuss about their progress.
Product backlog:
contains all the business requirement which is prioritized by client.
Sprint backlog :
the req. the requirement that need to be complete during Sprint cycle contained in sprint backlog.

Output of sprint backlog is called finished product that can be delivered to customer.

Limitation of scrum :
needs Very large amount cost and amount of time to complete a task. If customer is confused
it need experience and well knowledge on developers.
Useful for small project.

agile Page 2
Dynamic sys. Development method dsdm.

Agile method.
First req resouces of project allocated
Time frame is firxed.
Then analyasis the task should be completed witin these constriants
It is iterative and incremental
User involment threoughout the project.

Feasibility study defines what we are going to solve

Also cost time resources feasibility.

Business study defines the business requirement and who is going

To use the product and what may they expect.
Functional model : refines the business model into functional model
Design & build iteration :
Designing and develop done in iterative way.
Implementation : deliver the tested sys along with documentation to end user.

agile Page 3
Es : most senior project role.
Visionary : gathered the needs of client and communicate it team member.
Ambassador : provides business related information.
Au:
the role of testing to broaden the end user involvement and acceptance of what is being developed

Pm : all aspect of delivery of solution and in charge of all project.

Technical coordinator : ensures that develop. Team working in consistent way

Team leader : reports to pm as team are working well

Developer : build the business req into deployment product

Tester : do testing

Scribe facilitator : analysis the stakeholder req and prioritized of req

Specialist roles : it can added to development team by team leader and
Project manager.

agile Page 4
Advantage :
Active user involvement , basic functionality of soft is given to customer and
Additional functionalities will be delivered regular interval.

Drawback.
it requires training both for developer and user. So therefore it is costlier.
it is new model so it is difficult to understand easily.

Crystal methodology :

Crystal here is for degree of hardness and different colours of methodology.

The colour is about the heaviness of project

Light colour : less people on project
Darker colour : more resources req. for project.
Based on crystal clear 7 differ colours are :
1. Clear
2. Yellow
3. Orange
4. Orange web
5. Red
6. Magenta
7. Blue.

Seven properties of crystal methodology :

• Frequent releases of the increment

• Developers spend enough time to improve the development process. They also conduct reflective workshops to
identify the processes that are working and not working
• Natural and seamless communication
• Personal Safety by having rights to everyone to speak out their ideas and thoughts in the group
• Focus
• Easy Access to Expert Users
• Technical Environment with Automated Tests, Configuration Management, and Frequent Integration

Feature driven development :'

- Agile methodology for soft develop.
- A short iteration framework
- It focuses on object model, build feature list plan by feature design by feature and build by feature.
- Give importance[emphasizes] quality at each step
- Delivers frequent , tangible[ which is clear / stable] , working result
- Provides accurate project progress tracking
- Combines many of best practices other agile models.
- Focuses less on early stages and focuses point where new features can be added.
Various phases are :

agile Page 5
Develop an overall model : a team is formed , understand the scope and domain of sys based on it model is developed
Build features list :
The team then develops a list of features and groups these features into feature sets.
During the Plan by Feature phase :
The team then decides, which feature sets will be have to be developed, which Programmers are responsible for which
feature sets, and which Class Owners are responsible for each class.
And during the last two phase i.e. Design by Feature and Build by Feature:
The team design, build, and test features in two-weeks' time.
Last two phases is repeated until no more features exist.

Lean soft development :

Principles of lean software development are

- Eliminate waste ,Waste is something that does not add value. Example could be a unnecessary work.
- Build in quality Quality assurance should be integrated throughout the project development.
- Create knowledge Learn and share knowledge to others and empower self
- Defer commitment
- Make decisions at the last responsible moment
- Deliver fast Deliver smaller increments of the product in short intervals
- Respect people Respect colleagues, let people decide what and how to do it in order to meet goals
- Optimize the whole, Optimize the whole value chain from customer request to complete product.

Advantage :

agile Page 6
Limitations :

Extreme programming (xp):

Gives more importance to coding , programmers

Development should be simple as possible.

Courage to tell what's possible to build and what's not :

agile Page 7
Courage to tell what's possible to build and what's not :

1) Allows the developers to concentrate on coding by avoiding unnecessary meetings and formalities.
2) Increases learning opportunities for developers.
3) Allows the team to quickly adapt to changing business environment with less cost.
4) A small release of tested software is available at the end of each iteration.
5) This methodology starts with the simplest solution.
6) Due to constant feedback, flaws in the system are detected at an early stage.
7) Pair programming reduces risks related to coding and also improves employee satisfaction. The dependency on a
single person is reduced.

agile Page 8
===============================================================

Kent beck created Xp

- Short development cycle

- Frequent releases
- Customer req changes done easily

agile Page 9
Agile is used for development that uses four values[agile Manifesto ] and twelve Principle to organize projects
Agile manifesto : its document that shows the key values and principles
Behind the agile philosophy which will help development team to work
More efficiently.
It has 4 values and 12 principal :

agile works in on going sprints of project planning and execution.

It is done in iterative way [ which need increment development and delivery product to customer ]
Customer involvement is very high
We can run agile project using differ. Frameworks

agile Page 10
Why do we need xp ?
It works in iterative way and recurrent software releases throughout
The project.

Advantages :
Fast : few months
Visible : everyone can talk freely and open communication within learn.
Reduces costs :changes are done here throughout the development
Teamwork :

Small teams : it should not exceed more than 12 people.

Class responsibilities collaboration cards are used for oops design in the software
Using spike solution on complex program can help in reducing risk.

agile Page 11
Mvp == minimum viable product is early release of software which has only the required core functionality

agile Page 12
Without changing the op if we want to optimized the internal struct. Is called refactoring.

Roles and responsibility :

agile Page 13
feedback Loop :
Customer , manager , developer is part of single team.
As customer and manager are fully connected with during development
There will be continuous feedback and

Feedback loop should be shorten

Different type of feedback we can apply :
Unit test :
Its first feedback loop should be apply on any project.
It gives feedback on work in secs.

agile Page 14
It gives feedback on work in secs.
We can get this feedback every time if we save the code or we push into
Version control system.
If we are getting too much time or difficulties in writing test cases then our
Code is too complex then we need to simplify.

Continuous process :

Continuous Integration:
Developers should be integrating and committing code into the code repository every few hours, whenever possible.
In any case never hold onto changes for more than a day.
Continuous integration often avoids diverging or fragmented development efforts.
Continuous integration avoids or detects compatibility problems early.
This practice enhances the developer's productivity and helps to release versions quickly and easily.

Refactoring:
Refactoring is a practice of software development that allows you to improve the code without changing or breaking its
functionality.
It is aimed at simplification.
The code should be as simple as possible to find all the bugs.
If the client wants to change something in the final product, the team should make these changes as fast as it is possible.
XP code refactoring allows you to achieve this goal.
Releases :
Instead of having a big release at the end of a long development cycle, we try to release very often.
Small releases are essential for XP, as they show the accuracy of your team towards the project.
Extreme Programming promotes small Releases through continuous integration(CI) and other extreme programming
practices.
Small Releases helps to deliver a small working increment in a few weeks

Extreme Programming Versus Kanban:

In Kanban the workflow is visualized. The work is broken down into small, discrete items and written on a card that is
stuck to a board. The board has different columns and as the work progresses through different stages, the card is
moved accordingly. In Kanban the number of items that can be in progress at any one time is strictly limited.
Extreme Programming is successful because it stresses customer satisfaction. Instead of delivering everything you could
possibly want on some date far in the future, XP delivers the software you need, as you need it. Extreme Programming
empowers developers to confidently respond to changing customer requirements, even late in the life cycle. Extreme
Programming emphasizes teamwork.

Extreme Programming versus DSDM:

In Extreme Programming, customer assisted by the team assigns requirements to timeboxes based on the size of team
and estimates. In DSDM, a restriction is added to the timebox based on the Moscow priority scheme with some low
priority items.
Extreme Programming has less clearly defined roles like Customer, Tracker. DSDM has more clearly defined roles like
Team leader, Executive Sponsor, Technical Co-ordinator, Facilitator and so on.
Extreme Programming has “Iteration Planning Meeting” where customer explains stories. DSDM has an “Objective

agile Page 15
Extreme Programming has “Iteration Planning Meeting” where customer explains stories. DSDM has an “Objective
Setting Meeting” at the start of a timebox.
In XP, the team lists tasks and programmers sign up for tasks. In DSDM, the user reassesses the priorities and the team
agrees on a minimum that can be delivered

==========================================================================
DSDM :
Dsdm came in 1994.
Focus on full project life cycle.
Early delivery
Strategic goals and benefits to business.
8 princples :

Dsdm uses incremental protyping and buld product dynamically.

agile Page 16
Dsdm uses incremental protyping and buld product dynamically.

In dsdm analysys , design development phases can be overlapped.

Its agile framewrok

- Deleivers project quickly
- It is flexible and meet changing business requirement
- It also has government mechanisms and project management.
- It is iterative and incremenatal therefore its dynamic.
- Whatver req is known desined and incorated into sys.
- It has good guidance , budget friendly
- It is applicable for any sector and all kind of complexity product.

- In 1990 rad was popular

- With rad it has property of give solution quickly and easily
- Developer wanted to build product more under governor guideline and strict policies
- Dsd was introduced for these problem which was included of traditional control system and also good communication from
RAD.

Its used in both it and non it

It use tight time constraints.
ISO CMI are examples.
They build project so the existing project improves.

agile Page 17
the development work is being completed in the iteration that includes demonstration, feedback, and consultation from the
stakeholders

From <https://staragile.com/blog/dsdm-agile>

Traditional vs dsdm approach .

agile Page 18
Project level roles :
The Business Sponsor provides the overall strategic direction and controls the funding/budget for the project.
The Business Visionary and the Technical Coordinator hold the business and technical visions
The Project Manager ensures that project funds are used effectively to create the envisaged solution within the agreed
timescale. They have authority of project.
Solution development role :
Each member of the Solution Development Team is an empowered individual who takes personal ownership for their area of
responsibility and represents the interests of their peers.

agile Page 19
Supporting role:
The Advisor roles may be filled by one or more subject matter experts, as necessary. The Advisor roles are not the
empowered decision-makers – that is the responsibility of the roles within the Solution Development Team – but they advise
the Solution Development Team in areas where specialist expertise is needed (e.g. legal and compliance matters, technical
knowledge, business-specific rules and regulations). The supporting roles engage with the project as and when necessary. For
example, a Business or Technical Advisor will be actively involved during Foundations and then for the particular Timeboxes
where their expertise is needed to properly shape the Evolving Solution.

One person may carry out the responsibilities both of the Project Manager and the Team Leader.

There can be more than one project manager one from business side one from tech side.

agile Page 20
Pre-Project.
• Ensure only right projects started.
• Setup up correctly based on clearly defined objective:
○ High level definition and over-arching business driver defined + top-level objectives.
• No PM yet, generally. Done by leadership team.
• Short!
Feasibility.
• Estiblish if project success likely - technical & cost-effective (business) perspectives.
• Just enough effort to decide if foundations phase is justified. Plan to resource the foundations phase.
○ Few days or week max.
• Creates 1 to 10 EPICS. EPIC is placeholder for set of user stories.
• The visionary owns the business process so s/he approves the feasability phase. Is the project

agile Page 21
 • The visionary owns the business process so s/he approves the feasability phase. Is the project
feasible from a business/technical perspective and cost?
• What are the business requirements and EPICS. EPICS are the feature or functionality originating
from the business - placeholders for more granular requirements generated later.
Foundations.
• Preliminary investigation: fundamental, not detailed, undestanding of business need.
• High-level business solution proposition.
• How development and delivery will be managed.
• Avoid low-level detail - avoid contraining evolutionary phase!
• Drill down into user stories with more detailed acceptance criteria and the priorities.
• Flesh out the 6 docs created in feasability phase.
• Could be weeks. 3 - 4 weeks planning workshops. Flexible not rule.
• No development. This is just readiness and planning, understanding the MoSCoW's. Do people
understand the standards? Is the tool access there? Etc.
○ User stories are not technical tasks
○ Detailed acceptance requirements. How many time boxes to complete ev dev for stage 1?
○ Timeboxes and length decided for first iteration.
• Product Roles - RACI (Responsible/Accountable/Consulted/Informed) defined.
• SDT added here. Create 100's or user stories.
• Milestone Output: Foundations summary.
• For some project it is merged with feasblity process.

1. Deployment.
1. Assemble.
▪ Make sure deliverable is coherent. E.g. gather supporting information.
2. Review.
▪ Approval to deploy.
▪ SDT does retrospective for incrment.
▪ Retrospective + formal feview feedback into project review report to help guide next increment.
3. Deploy.
▪ Solution deployed into active use.
▪ Final end-to-end testing during Deployment allows for the testing of back-out procedures.
▪ Milestone Output: Project review report.

2. Deployment.
1. Assemble.
▪ Make sure deliverable is coherent. E.g. gather supporting information.
2. Review.
▪ Approval to deploy.
▪ SDT does retrospective for incrment.
Retrospective + formal feview feedback into project review report to help guide next increment.

agile Page 22
 ▪ Retrospective + formal feview feedback into project review report to help guide next increment.
3. Deploy.
▪ Solution deployed into active use.
▪ Final end-to-end testing during Deployment allows for the testing of back-out procedures.
▪ Milestone Output: Project review report.

3. Post-Project.
○ Checks how well the expected business benefits have been met
▪ Immediate and over a pre-defined period of live use.
○ Milestone Output: Benefits assesment.

Terms of ref.

Business case :

agile Page 23
Prioritized requirement list :

Solution architecture definition :

agile Page 24
 Devlopmemt approcah defintion :

delivery plan :

Management approach definition :

• Evolutionary product
• Defines how:
project organised/planned,

agile Page 25
 ○ project organised/planned,
○ stakeholders engaged,
○ how progress demonstrated/reported.
• Outlined in feasability and beaslined at ehd of foundations.
○ Generally not modified after.
• CREATED BY: PM
• FOR: all project participants/stakeholders
• APPROVED BY: BS
Fessibility assement :
• Milestone.
• Snapshot of solution and products at end of phase.
○ Either executive summary or baselined collection of products.
○ Each product mature enough to allow decision to continue to foundations.
• BY: PM
• FOR: Project governance authority
• APPROVED BY: BS

Evolutionary solution :
• Evolutionary
• Components of final solution + intermediate deliverables exploring detail of reqs/solution
○ Components can be complete/baseline/work-in-progress
○ Can include: models, prototypes, supporting materials, test/review artefacts etc.
• At end of each increment solution deployed into live use.
• BY: SDT
• FOR: BS, Solution participants
• APPROVED BY: BV, TC

Project review report :

• Milestone.
• Updated at end of each increment.
• Purpose:
○ Capture review of solution feedback.
○ Confirm what's delivered and what is not.
○ Capture learning points from retros.
○ Describe business benefits that should now accrue.
• At end of project review report informs the project closure retrospective.
• BY: PM
• FOR: All project participants/stakeholders.
• APPROVED BY: BV, TC, T
Benefits assessment :
• Milestone
• Describes how benefits actually accrued following period of live use.
• BY: BV, BA
• FOR: Governance authority
• APPROVED BY: BS

Moscow prioritization :
Also called moscow method or moscow analysis
Four catogeries :
Must have
Should have
Could have

agile Page 26
Could have
Wont have

Must have = MUST = Minimum Usable SubseT...

^ ^ ^ ^
Without no point in project - customer will reject project.
PM or BA may challenge less obvious must haves
- Can a requirement be broken down further
to have a smaller must have with one or more
should/could have.
Should have...
Important but not vital
Painful to leave out - needs workarounds
Could have...
Wanted or desirable bu less important
Less impact if not done compared to should have.
Wont have this time...
Will not be delivered in this timeframe.
Prioritisation
BV and BAmb have the final say
Start with all requirements as "wont have" and then justify any priority
increment
Business sponsor
- Expects ALL must haves
- Typically expects most/all should haves
- DSDM recommends 20% contingency for could haves
but 10% can be "more normal" sometimes.
Team needs to ask questions to relevant stakeholders to determine the priority.
• Must haves:
○ Minimum Usable SubseT (MUST),
▪ Not legal without it,
▪ No point in delivering without it,
▪ Unsafe without it,
▪ Not viable without it.
○ <= 60% effort typically,
○ Meaning not negotiable v.s. could/should meaning which is more subjective.
○ Ask: "Can this be broken down into a set of must with could./should's?"
• Should haves:
○ 20% effort typically,
○ Ask: "What value of befefits could justify dropping this to a could have?"
• Could haves:
○ Main point of contingency
20% effort typically,

agile Page 27
 ○ 20% effort typically,
○ Ask: "At what point does number of people impacted raise a could to a should?"
• Won't have this time:
TmeBoxing :
2-4 weeks.

agile Page 28
Clear - for teams of 8 or fewer people
Yellow - for teams of 10-20 people
Orange - for teams of 20-50 people
Red - for teams of 50-100 people

====================================================================

Kanban :

Toyota used it first 1940 lean mafufacture.

Lean principles :

History of lean management :

agile Page 29
History of lean management :

Lean management is also acceptable by government and other market people.

Why to use lean management :

agile Page 30
Advantage :

Kanban:

agile Page 31
Candence meeting is daily meeting for team, and service oriented

agile Page 32
agile Page 33
agile Page 34
Wip : work in capacity.

Blockers are indicated with red magnet in physical.

Wip and manageing flow:

agile Page 35
agile Page 36
agile Page 37