Hitesh Sahu
Hitesh SahuHitesh Sahu
  1. Home
  2. β€Ί
  3. posts
  4. β€Ί
  5. …

  6. β€Ί
  7. 1.1 Agile

Loading ⏳
Fetching content, this won’t take long…


πŸ’‘ Did you know?

πŸ¦₯ Sloths can hold their breath longer than dolphins 🐬.

πŸͺ This website uses cookies

No personal data is stored on our servers however third party tools Google Analytics cookies to measure traffic and improve your website experience. Learn more

Cover Image for πŸŒ€ Agile Methodology πŸ“–

πŸŒ€ Agile Methodology πŸ“–

Comprehensive guide to Agile methodology, including principles, frameworks, and best practices. Learn how Agile improves collaboration, delivery, and adaptability in software projects.

Hitesh Sahu
Written by Hitesh Sahu, a passionate developer and blogger.

Tue Nov 11 2025

Share This on

The Agile Manifesto

We are uncovering better ways of developing software by doing it & helping others do it.

Through this work we have come to value:

  • Individuals & interactions over processes & tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan>

12 Principles of the Agile Manifesto

  1. Our highest priority is to satisfy the customer through early & 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 & developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment & support they need, & trust them to get the job done.
  6. The most efficient & effective method of conveying information to & 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, & users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence & good design enhances agility.
  10. Simplicityβ€”the art of maximizing the amount of work not doneβ€”is essential
  11. The best architectures, requirements, & designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes & adjusts its behavior accordingly.

Frameworks

Scrum, Extreme Programming, or Feature-Driven Development (FDD).

Advantages : Speed to market & risk mitigation

  • High quality of software: Goal is to have an available release (with minimal bugs) at the end of each iteration
  • Risk mitigation: Products have room to "fail often & early" throughout each iterative phase instead of drastically on a final release date
  • High Visibility to stackholders: Working software is the primary measure of progress
  • Efficient Communication: Face to face communication & colocation redcuce chances of miscommunication. Customer get higher visibility of progress through daily scrum meetings & developers can ask question about perticular acceptance criteria.
  • "Customer Centered Methodology"- At the end of each iteration, stakeholders & the customer representative review progress & re-evaluate priorities with a view to optimizing the return on investment (ROI) & ensuring alignment with customer needs & company goals.

Techniques

  • continuous integration(CI/CD)
  • pair programming
  • design patterns
  • domain-driven design(DDD)
  • automated unit testing
  • test-driven development(TDD)
  • behavior-driven development(BDD)
  • code refactoring

Pitfalls

  • Rework: team progress to make a requirement met but it changed by customer so we had to do rework again
  • Badly Planned stories: underestimated effort in refactoring, rigid or fragile code base, incomplete design often lead to break planned sprint & cause spillover-> backlog refinement or grooming.
  • Ever growing Technical debt:- Team failed to plan scaling of project cause technical debt & rework. Lack of documentation leads to unclear design/ architecture insights.
  • Attempting to take on too much in an iteration:- Having too much work-in-progress (WIP) results in inefficiencies such as context-switching & queueing. The team must avoid feeling pressured into taking on additional work.
  • Fixing CI/CD Release issue: Often someone from team need to lay role of bug hero to fix build related issues

The project management triangle

> Scope = Time Γ— Resources

The quality of work is constrained by the project's budget(cost), deadlines(time) & scope (features). Good, fast, cheap. Choose two.

  • The project manager can trade between constraints.
  • Changes in one constraint necessitate changes in others to compensate or quality will suffer.

To meet same scope with fewer resource we need more time and vice versa

Daily standup

Scrum Style Daily:

  • What did I do yesterday that helped the development team meet the sprint goal?
  • What will I do today to help the development team meet the sprint goal?
  • Any impediment that prevents me or the development team from meeting the sprint goal?

Kanban-style daily:

  • What obstacles are impeding my progress?
  • (looking at the board from right to left) What has progressed?

XP (Extream programming)

Agile methodology beneficial elements of traditional software engineering practices are taken to "Extreme" levels

Example:

  • code reviews are considered a beneficial practice; taken to the extreme, code can be reviewed continuously (i.e. the practice of pair programming).

Activities

  1. Coding: Coding can be used to figure out the most suitable solution & communicate thoughts.

    • Other programmers can give feedback on this code by also coding their thoughts., testing, listening, and designing
  2. Testing: if a little testing can eliminate a few flaws, a lot of testing can eliminate many more flaws.

    • TDD
    • ATDD
    • Integration Testing
  3. Listening: Programmers must listen to what the customers need the system to do, what "business logic" is needed.

  4. Designing: Good design will avoid many dependencies within a system; this means that changing one part of the system will not affect other parts of the system.

Values:

  • Communication

  • Simplicity:

    • Start with simple functionality and improve on it
    • Focus on designing and coding for the needs of today instead of those of tomorrow
  • Feedback:

    • from customer
    • from system/acceptence testing
    • Flaws in the system are easily communicated by writing a unit test
  • Courage

    • design and code for today and not for tomorrow
    • remove source code that is obsolete, no matter how much effort was used to create that source code
    • problem quickly the next day, but only if they are persistent
  • Respect(+): respect for others as well as self-respect

    • never commit changes that break compilation, that make existing unit-tests fail, or that otherwise delay the work of their peers
    • Nobody on the team should feel unappreciated or ignored.

Drawbacks

  • No SRS: Requirements are expressed as automated acceptance tests rather than specification documents.

  • Future Proof Plan: Requirements are defined incrementally, rather than trying to get them all in advance.

  • Cost Software developers are usually required to work in pairs.

  • No Big Design Up Front. Most of the design activity takes place on the fly and incrementally, starting with "the simplest thing that could possibly work" and adding complexity only when it's required by failing tests. Critics compare this to "debugging a system into appearance" and fear this will result in more re-design effort than only re-designing when requirements change.

  • PO Work Load This role can become a single-point-of-failure for the project, and some people have found it to be a source of stress. Also, there is the danger of micro-management by a non-technical representative trying to dictate the use of technical software features and architecture.


Scrum

Scrum is a lightweight, iterative and incremental framework for developing, delivering, and sustaining complex products

  • https://en.wikipedia.org/wiki/Scrum_(software_development)

Values:

These three pillars require trust and openness in the team, which the following five values of Scrum enable:[19]

  • Commitment: achieving team goals, each and every sprint.
  • Courage: courage to work through conflict and challenges together so that they can do the right thing.
  • Focus: focus exclusively on their team goals and the sprint backlog; there should be no work done other than through their backlog.
  • Openness: transparent about their work and any challenges they face.
  • Respect: respect each other to be technically capable and to work with good intent.

Drawbacks:

  • Hurting productivity and wasting time that by agile rituals.
  • Scrum practices have a tendency to become a form of micromanagement.
  • Estimation often unpredictable.
  • Dont encourage freedom of empirical analysis and experimentation.
  • Scrum is perceived as an alternative approach to, managing projects.
Programming/1.1-Agile
Let's work together
+49 176-2019-2523
hiteshkrsahu@gmail.com
WhatsApp
Skype
Munich πŸ₯¨, Germany πŸ‡©πŸ‡ͺ, EU
Playstore
Hitesh Sahu's apps on Google Play Store
Need Help?
Let's Connect
Navigation
Β  Home/About
Β  Skills
Β  Work/Projects
Β  Lab/Experiments
Β  Contribution
Β  Awards
Β  Art/Sketches
Β  Thoughts
Β  Contact
Links
Β  Sitemap
Β  Legal Notice
Β  Privacy Policy

Made with

NextJS logo

NextJS by

hitesh Sahu

| Β© 2025 All rights reserved.