Agile Approch

Manifesto for Agile Software Development

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

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

That is, while there is value in the items on
the right, we value the items on the left more.

https://agilemanifesto.org

Expectations from programmers

  1. We will not ship shit
  2. We will always be ready (Iteration length)
  3. Don’t slow down (Stable productivity)
  4. The software must be changeable (Inexpensive Adaptability)
  5. Code should be better with time (Continuous Improvement)
  6. Conquer the fear with tests (Fearless Competence)
    • Checking better than before (Boy Scout Rule)
    • Design tests decouple them from the code (like any other code)
    • Target test coverage should be 100% (Don’t show it to managers)
  7. We will not dump on QA (QA will find nothing)
    • Automation (Automated tests)
    • Nothing fragile
  8. We cover for each other (Team Work)
    • Pair Programming (Hour – two few times a week, enough to cover for each other)
  9. “Honest Estimates”
    • I don’t know
    • Three numbers: Best case, Usual case, Worst case
    • Say “No” when the answer is No.

Introduction

It’s hard to manage software projects because of inevitable trade-offs:
Good (Quality), Fast (Time to Market), Cheap (Cost-Effectiveness), Done – Pick any three.

Agile aims to get Velocity and Burndown charts. That lets us estimate when the project will be ready for the next delivery. That will help meet deadlines.

The Waterfall model does not work because requirements change all the time. It was presented as a bad idea in the first place.

The solution is Iterative Development, where analysis, design, and implementation are done in small loops and repeated many times. This approach allows adapting to changing requirements and any problems that can arise.

The first sprint is mainly analysis and design. Implementation starts on the second sprint. Planning the second sprint is just a guess. After each sprint, we’re better at estimating how much we can do in a sprint.

The control knobs of project management: Schedule, Staff, Scope, Quality

Assuming that we can’t change the Schedule or Staff. Quality should always be at the max. The lower it is, the slower everything gets. The only knob to move is Scope. Maybe not everything needs to be delivered on the scheduled date or fully.

Programming projects are very, very complicated and hard to estimate.

Agile Software Development Practices

Business Practices (Scrum):

  • Planning Game (Creating User Stories, Estimating using Story Points)
  • Whole Team
  • Small Releases
  • Acceptance Tests

Team Practices:

  • Continuous Integration
  • Collective Ownership
  • Sustainable Pace
  • Metaphor

Engineering Practices:

  • Test Driven Development
  • Refactoring
  • Simple Design
  • Pairing

Scrum without Team and Engineering Practices is a Flacid Scrum – Scrum that fails. Failure is manifesting as a slowdown in development.

Agile is for small teams.

Thanks to estimating and previous sprints we can estimate how much can be done in a sprint. Estimates also let stakeholders decide what should be done next. High-value cards with a high return on investments are done in the first place. At some point, there is nothing else worth doing. Then the project is completed.

Iterations do not fail because their purpose is to produce data. The number of points in a sprint is not a goal!

There should be one User Story that all other estimates compare against to combat inflation or deflation of story points.

A different approach is instead of assigning story points around the question: “Can we split User Story?“. The goal is to split the story in such a way that the resulting substories are shippable. Then put aside stories that depend on other stories and choose one that is the simplest. Discuss this story in detail. Then move to there rest of the stories. You can leave some of them for later. The stories that depend on other stories discuss at the end.

Quality Assurance should create automatic Acceptance Tests that will tell if any User Story is completed.

If You can’t estimate a given story, You can do Spike. It is a story in which You try to estimate how much it will take to do a hard-to-estimate story.

Non-functional requirements like speed should be written down and tested. Architectural and non-functional Design-related requirements programmers shouldn’t discusse with stakeholders. Clean code practices and going well should be a standard way of working for You, Your Craftsmanship. Does anyone tell the surgeon not to wash their hand to start the operation faster? Just do your job!

Senior Developers should teach and pair with less experienced people.

If You have a good reason, You can break the rules but do everything You can to keep them, and if in some cases it is not possible, then get back to the rules as soon as possible.

Sources:
Agile Software Development, Principles, Patterns, and Practices (Robert C. Martin)