Agile is an iterative software development process.
Other Models


Discussion of Waterfall as a process started with Winston Royce, who was naming common problems with the default software development process. So from the start, what is called Waterfall was an anti-pattern. Winston Royce was already in favor of an iterative model.

Stages of the Waterfall process:
- Requirements gathering
- Design
- Construction
- Integration
- Testing and Debugging
- Installation or Deployment
- Maintenance

Problems with Waterfall:
- It doesn't allow you to go back to a previous phase of the project, to make repairs or improvements.
- You progress to the next phase before you have time to get feedback about the previous phase.
- You don't have any working software until the end of the process.

For instance, it is impossible to collect all requirements before starting to build a system. Many requirements are revealed as developers and users consider the partially built system.

What needs to be true for Waterfall to work?
- All requirements are well documented, clear, and unchanging
- Product definition is stable throughout development
- The technology being used is well understood
- The project is short - 4 months max
- You have all the resources you need available

Advantages of Waterfall:
- Easy to schedule and control
- Roles can be clearly defined and departmentalized
- An easy to understand process
- Fits into a Gantt chart nicely

[Winston Royce's 1970 paper]
"The virtue of all of this is that as the design proceeds the change process is scoped down to manageable limits. At any point in the design process after the requirements analysis is completed there exists a firm and closeup, moving baseline to which to return in the event of unforeseen design difficulties.

What we have is an effective fallback position that tends to maximize the extent of early work that is salvageable and preserved."

"At this point it is appropriate to raise the issue of - "how much documentation?" My own view is "quite a lot"; certainly more than most programmers, analysts, or program designers are willing to do if left to their own devices. The first rule of managing software development is ruthless enforcement of documentation requirements.

...During the early phase of software development, the documentation IS the specification and IS the design. Until coding begins, these three nouns (documentation, specification, design) denote a single thing."


V-Model is a modifeid Waterfall. (Paul E. Brook, 1986)

In the V-Model, there is a test-design phase for each development phase. Then all these tests are run during the validation phase.

Types of tests:
- Acceptance Tests, based on requirements
- System Tests, based on system design
- Integration Tests, based on architecture and module design
- Unit Tests, based on coding


Agile is a software development process that allows for the evolution of requirements over time. The Agile Manifesto was first published in 2001.

It promotes:
- Adaptive Planning
- Evolutionary Development
- Early Delivery

The aim of Agile is frequent delivery of working software, starting with the Minimum Viable Product, and gradually adding more features.
This allows you to prioritize the most valuable features first, and deliver them to the business long before the entire project is complete.

Agile Manifesto

"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
- Custom 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."


Regular delivery of software:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
(This principle indicates that overworking your staff is counter to the Agile principles, as it not sustainable.)

Team communication:
- Business people and developers must work together daily throughout the project.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Excellence in design:
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity, the art of maximizing the amount of work not done, is essential.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Agile teams are made up of people from many different departments. They should consider themselves part of the team first, and members of different departments second.

Team members do what is needed at the time it is needed to achieve the team goals.

Product Expert

The product export or domain expert will interact closely with users/customers.
They will research the market the product is in, and what business benefits the software will provide.

They create and prioritize work for the team.
They help determine when work is complete.

Scrum calls this role the "Product Owner".

Cross-Functional Skills

Some team members have cross-functional skills for building and operating the entire system, and understanding how it will fit into the larger world.

These core members work as a single team to design, code, test, and implement a software system.

They must all work and collaborate together.
A team member will frequently assume multiple roles in additional to their primary responsibilities.


This may be the manager or the team lead. Their goal is to enable and support the success of the team.
This may involve managing stakeholder expectations, company communication, progress reporting, motivating team members, budget management, and staff management.

This is a "servant leadership" role, where the leader's main focus is serving the team.

Scrum calls this role the "Scrum Master".


It is helpful for have someone available as coach/mentor.

This person is not responsible for any specific project deliverables. They focus on continuous improvement and engineering discipline.
They help guide the team to become better every single day.

User Story Size

Regarding user stories / tickets / whatever you call a task in Jira/TFS/etc.

How large should a user story be? Meaning how much work should be encompassed by a single user story?

I recommend small user stories. Break larger tasks down into smaller, cohesive pieces.
Ex: You're refactoring, and it will affect several endpoints of your service. If possible, refactor one endpoint at a time.
Ex: You're adding a create-and-edit feature. Do the creation work first, then the edit work.

Rules of thumb for how to break down a large task:
- Separate by function, such as create-edit-delete.
- Separate by code base, such as updating a service, then updating the front-end.
- Separate by layer, such as adding new objects, then adding the operations that use them.
- Separate by slice, such as updating one endpoint at a time.
- Separate by work mode, such as research, then design, then implementation.

Benefits of small user stories:
- You had to think through the task already, in order to break the task into smaller pieces.
- Small tasks are easier to hold in your head. You'll forget and overlook less.
- Small tasks are easier for other developers to validate. A small pull request is easier to sign-off on with confidence.
- Small tasks are less likely to balloon out of control with unforeseen requirements or implementation problems.
- Doing a small part of the task first is a good way to establish the pattern that will be followed for the rest.
- You're mind will be clearer when you can steadily complete small tasks.
- You're mood will be better when you can steadily complete small tasks.


Fear of over-committing: causes heavily padded time estimates and light sprints.
- First, this isn't a terrible thing to make cautious estimates. As the team gains confidence in the amount of work they can complete, they will give more accurate estimates.
- Second, management must give teams the leeway to make mistakes. Missing a few commitments is forgivable.

Lack of team empowerment.
- Management not supporting Agile is probably the #1 killer of switching to Agile.
- Engage the team to actively help with planning, and provide their insights about the work.
- Actually allow the team to make important decisions instead of just telling them what to do.
- Management provides priorities, the team decides how the work will proceed.
- This will involve negotiations between management and the team about what work can be completed by what deadlines.

Poor communication: always harms a project.
- Agile recommends daily face-to-face meetings (brief meetings) as a starting point.

Assigning blame: Agile places team success above individual performance.
- To engender trust in the team, management must not use individual metrics.

The team doesn't have the skills to complete the project.

The team isn't stable - people come and go.

Estimating the actual time is will take to complete a task, instead of abstractly estimating its difficulty/complexity: Agile recommends abstract ranking of tasks as coming out more accurately.
- I'm not sure about this part of Agile. It takes time to learn to accurately make time estimates, but you can learn it. And once you're selecting tasks for a sprint, you HAVE to have a good idea of how long they will take because you are committing to completing them in a set amount of time. So it seems easier to me to just train people to make accurate time estimates.
- "Different team members give different time estimates based on their abilities" - absolutely, it makes sense that a time estimate is based on the people that will complete the task. So why not use a task system that can track multiple time estimates paired with developers? And you can still track the abstract magnitude of the task at the same time.

Poor planning: Agile does not mean not planning anything.
- Expect to spend 20% of your time on planning.
- Planning includes backlog preparation, a daily stand-up, iteration and sprint planning, and release planning meetings.

Poor testing: a task is not complete until it is thoroughly tested.
- Do not try to be faster by skipping testing.
- Test continuously throughout development.

Ignoring customer feedback: you can't make the customer happy by ignoring them.

Agile is ad-hoc, with no process control.
- Processes like Scrum and Lean follow Agile principles.

Agile is faster or cheaper.
- Agile produces working software faster, but it may take the same amount of time to complete the entire project.

Agile teams don't make plans or documentation.
- Agile generates only the plans/documentation that are valuable.

An Agile project never ends.
- Taking maintenance into account, many projects never end. That's normal.

Agile only works for small organizations.
- Size shouldn't be a factor.

Without upfront planning, Agile is wasteful.
- If you actually know all the requirement upfront, upfront planning makes sense. But that is rare.

Agile means "no commitment".
- Common processes like Scrum and XP both include the commitment to complete tasks each sprint.

Agile development is not predictable.
- Once a team is good at accurately estimating how long tasks will take, they can be very predictable about when work will be completed.

Agile is a silver bullet.
- There are no silver bullets.

There's only one way to do Agile.
- There are many Agile processes, such as Scrum and XP.

Agile doesn't need upfront design.
- Design is done as late as possible, but it must still be done.

We're doing Scrum, so we don't need to pair program, refactor, or use TDD.
- These are all useful tools that can be incorporated into Scrum.

"Scrum is a light-weight management framework for iterative and incremental projects."

Scrum finds software development runs more smoothly when teams are feed with objectives instead of tasks.
"Teams required autonomy to achieve excellence."

Scrum is widely popular.

The Scrum process is a series of "sprints", 2-4 weeks each.


Product Owner:
- Project's key stakeholder
- Represents the customers
- Have a vision of the final product, and convey that vision to the team
- Must be totally available to the team
- Must understand the business very well
- Must be a good communicator
- Maintains the Product Backlog

Scrum Master / Process Owner:
- Responsible for making sure the team is as productive as possible
- Team coach / Personal trainer
- Helps the team follow the process, removes impediments, protects team from outsiders
- Facilitator
- Does not manage the team, cannot give orders

Scrum Team:
- 5 to 9 people, usually (to scale, make a team of teams)
- No divisions into programmers, designers, architects, etc
- Everyone works together on everything they can
- A successful team develops a strong camaraderie


Sprint Planning
- Happens at the start of each sprint
- All team members attend
- Product owner presents their top priorities from the Product Backlog (about 2-sprints worth)
- Scrum Team asks the Product Owner enough questions to translate the Product Backlog item into technical Sprint Backlog tasks
- Scrum Team selects the work they can complete in this sprint
- The selected work is moved from the Product Backlog to the Sprint Backlog
- Once a sprint has started, the requirements of that sprint should not change

Daily Scrum Meeting:
- Happens each morning
- All team members are required to attend
- Briefly state what was accomplished yesterday, what will be done today, and any blocking problems
- If anything is blocking you, you can work with the Scrum Master after the meeting to resolve the issue
- It's called a "Stand-Up" because everyone stands to keep the meeting short

Sprint Review
- Happens at the end of each sprint
- A short meeting
- Can include customers, management, and members of other teams
- The Scrum Team presents all completed work (informal demo, not long)
- The product should be well-tested and functional at the end of each sprint

Sprint Retrospective
- Happens at the very end of each sprint
- May be up to an hour long (longer if a crisis arises)
- The whole team discusses how well, or not well, Scrum is working for them
- Discusses possible changes to the process


Product Backlog:
- A prioritized list of every feature or change pending in the project
- Short descriptions in the Product Owner's words
- Features (usually as user stories), bugs, technical work, knowledge acquisition

Sprint Backlog
- A list of tasks to be completed in the current sprint
- Maintained by the Scrum Master
- Each item (user story, bug, etc) is broken into smaller technically-worded tasks
- Includes time estimates

Burn-down Charts
- Tracks progress of sprint, with completed work vs. committed work

Extreme Programming

Also called XP.

"A disciplined approach to delivering high quality software quickly and continuously. It provides high customer involvement, rapid feedback loops, continuous testing, continuous planning, and close teamwork to deliver working software at very frequent intervals (about 1 to 3 weeks)."

The name comes from the principle that useful coding processes are more useful when taken to the extreme. For example, code review is useful, therefore continuous code review in the form of pair programming will be more useful.

XP is more controversial than Scrum.


XP was invented in a few weeks by Kent Beck when he needed to save a failing software project with drastic methods. He discarded anything that did not directly contribute to business value, and pumped up the rest.


XP attempts to reduce the cost of changing a piece of software by using short development cycles.

XP plans for changing requirements, rather than expecting all requirements to stable.


- Coding
- Testing
- Listening (to the customer, and I assume to management and the team)
- Designing (reduce coupling)


- Solve today's problems today.
- Build the minimum set of features.

- This is how you can adjust to change, and set customer expectations.
- If you have questions about requirements, ask the customer directly. This is the most efficient way to move forward.

- Ask questions and learn from the answers.
- This includes talking to the customer, and testing the code.

- Making the hard decisions: fixing broken features, bringing code up to standard, be upfront about changes to the schedule.
- The only to recover from a mistake is to admit it and fix it openly.

- Everyone must care about the project.
- Internal rewards, like pride, beat physical rewards like employee of the month.
- Everyone should feel the respect of being a valued team member.


- Feedback
- Assume simplicity
- Embracing change

Supporting Practices

Fine-scale feedback:
- The planning game
- Pair programming
- Test driven development
- Whole team (the team should include members will all the necessary technical and business domain knowledge)

Continuous process:
- Continuous integration (frequently push local code to main repository, automated unit and integration tests)
- Design improvement
- Small releases

Shared understanding:
- Coding standards
- Collective code ownership (anyone can edit any part of the code)
- Simple design
- System metaphor (sounds similar to Domain Driven Design - naming standards shared between customers and developers, used in the code)

Programmer welfare:
- Sustainable pace (should only work 40 hour weeks, should not do overtime 2 weeks in a row, should not end up in crunch time)


- User stories are written (by the customer, approx. 3 lines of text in their own words)
- Release planning creates the release schedule (technical people make technical decisions, business people make business decisions, a plan is made together)
- Make frequent small releases
- The project is divided into iterations
- Iteration planning starts each iteration (1-2 week iterations, do not assign tasks to any future iterations)

- Give the team a dedicated open work space
- Set a sustainable pace
- A stand up meeting starts each day (what was accomplished yesterday, what will be attempted today, what problems are blocking progress)
- The Project Velocity is measured
- Move people around
- Fix XP when it breaks

- Simplicity (use the simplest design/method possible)
- Choose a system metaphor (naming conventions communicate business meaning)
- Use CRC cards for design sessions (CRC: class responsibility and collaboration)
- Create spike solutions to reduce risk (spike solution: simple program to explore possible solutions)
- No functionality is added early (you probably won't need it)
- Refactor whenever and wherever possible

- The customer is always available (the customer is part of the team, preferably on-site)
- Code must be written to agreed standards (use something like Resharper to enforce standards)
- Code the unit test first (TDD)
- All production code is pair programmed (increases quality without taking more time)
- Only one pair integrates code at a time
- Integrate often
- Set up a dedicated integration computer
- Use collective ownership

- All code must have unit tests
- All code must pass all unit tests before it can be released
- When a bug is found, tests are created
- Acceptance tests are run often and the score is published (acceptance tests are scenarios created from user stories)


"The crystal methodology is one of the most adaptable, light-weight approaches to software development."

It's actually a collection of methodologies like Crystal Clear, Crystal Yellow, and Crystal Orange. The choice of methodology is based on team size, how critical the project is, and project priorities.

The aim is to provide tailored processes suitable for each team and project.

DSDM stands for Dynamic Systems Development Method.

DSDM grew out of RAD (Rapid Application Development) in the 90s.
Feature Driven Design

"FDD is a model-driven, short-iteration process. It begins with establishing an overall model shape, then it continues with a series of two-week design-by-feature, build-by-feature iterations. The features are small and useful in the eyes of the clients."


- Domain object modeling
- Developing by feature
- Component and class ownership
- Feature teams
- Inspections
- Configuration management
- Regular builds
- Visibility of progress and results

"Lean software development is an iterative methodology, owing much of its practices to the Lean Programming movement and companies like Toyota."

"Lean software development focuses the team on delivering value to the customer, and on the efficiency of the value-stream and the mechanisms that deliver that value."


- Eliminate waste
- Amplify learning
- Decide as late as possible
- Deliver as fast as possible
- Empower the team
- Build-in integrity
- See the whole

"Rather than planning work items upfront and pushing them into the work queue, the team signals when they are ready for more work and pulls it into their queue."

Kanban uses a visual organization of tasks to display the state of development - what is being worked on and what state it is in. This is the Kanban Board.