Agile Methodologies and Frameworks

Extreme Programming (XP) (Methodology)

XP is an Agile methodology consisting of effective development practices to achieve client satisfaction. It focuses on constantly delivering software, responding to change, effective teamwork, and self-organization.

5 aspects of XP:

1. Communication
2. Simplicity
3. Feedback
4. Respect (everyone is equal. Client, developer, designer, and manager.)
5. Courage

 

12 XP Pracitces

12 Practices to follow

1. Planning Game

The client and dev team work together to plan the product. 

• List of new features that each turn into a user story.
• Dev team estimate task amount, determine how much effort to complete each user story.
• The client and dev team prioritize user stories and decide the release of each feature.

*planning should be simple and adaptive

2. Small Releases

Releases must occur as frequent as possible to gain plenty of feedback

• The client and dev team need to balance between must and can be developed early features.

3. System Metaphor

Using a metaphor makes it easier to explain the product to someone else even to those who are without technical background.

4. Simple Design

Designs should be as simple as they can be. Requirements are going to change constantly, thus there's no point in making detailed designs. Design for the requirements that are focused on today, right now.

5. Continuous Testing (Test-driven development, TDD)

Tests are prepared for a required feature or functionality before its corresponding source code is written. 

• Focusing on understanding what is required
• If the test is difficult to write, that might be a sign to rework the interface or original requirement.

Acceptance tests - Client to verify the product. Checking if product feature or requirement works as specified and is acceptable. 

Unit tests - written and run by developers. Checking specific, low-level functionality.

6. Refactoring

• Restructuring the internal design of the code without changing its behavior. 
• If it's not done or not performed properly, it will become "Technical debt"

7. Pair Programming

Instead of the conventional code reviews where one programmer complete source code and another programmer reviews it, two programmers work side-by-side on the same workspace to get immediate feedbacks.

• Boosting courage by having a partner
• Foster learning from seniors
• New perspectives from juniors

*this doesn't mean XP won't have code reviews

8. Collective Code Ownership

Other team members can add to your code or vice-versa. The code is not yours, it's ours. The work outcome is not the individual's but the team's.

9. Continuous Integration

Developers combine their codes often to catch integration issues early. 

• Usually once a day, but can happen multiple times a day.
• Sames goes to tests

10. 40 Hour Work Week

Some crunch time is allowed but long crunch time might be a sign of poor management or estimation.

11. On-Site Customer

The client is situated near the development team throughout the project to clarify and answer questions.

12. Coding Standards

All the developers agree to and follow a coding standard that specifies conventions on code style, formatting, and usage. This makes the code easier to read, and it encourages the practice of collective ownership.

 

Cons of XP

• XP is intended and suited for small development teams. (less than 10 people typically)
• Having the client on-site might not be a feasible option.
• No architectural design practices. Following only the metaphor shared early on, working product can be produced early but longer development might be hell as it's relying on refactors.
• Pair programming might not be a suitable options for all developers.

 

Scrum (Framework)

3 Pillars of Scrum

Transparency - everyone can see every part of the project. Agreeing and shared "done" requirements.

Inspection - Frequent inspection of work products and progress to detect undesirable deviations from expectations.

Adaptation - Adapt to prevent further deviation when risks are developing.

Scrum Process: Sprint Planning - Daily Scrum - Sprint Review - Sprint Retrospective

Product Owner

• Communicate to stakeholders
• manages requirements

Scrum Master

• Sprint planning with developers.
• Facilitate daily scrum
• Be a servant manager checking developers through daily scrum

Sprint planning

• Agree on the sprint goal, that is, what they intend to deliver by sprint end
• Identifying product backlog items that contribute towards this goal
• Form a sprint backlog by selecting which identified items should be completed in the sprint

 

Lean (framework)

Its origin is inspired by the manufacturing industry where Lean production grew out of the “Toyota Production System.” At Toyota, their approach was used effectively to reduce waste in the production process and increase the quality of their vehicles.

1. Eliminate waste

Focusing on what the team needs to fulfill the requirements. Busy working with outcomes doesn't always mean good contribution towards the goal. 

Partially done work, Extra features, Relearning, Task switching, Waiting, Handoffs, Defects, Management activities.

Value stream mapping (Material-information-flow mapping) - https://en.wikipedia.org/wiki/Value-stream_mapping 

to identify visually the waste in process.

Value-stream mapping - Wikipedia

2. Amplify learning

Explore all ideas sufficiently before proceeding with actions. This also encourages running tests after each build of the product as failures are considered as opportunities to see how to improve.

3. Decide as late as possible

Unless a decision needs to be made right now, don't decide before exploring alternate solutions. Premature decisions sacrifice the potential for a better solution and the right product.

4. Deliver as fast as possible

Frequent releases provide opportunities for the client to give feedback for further refinements. Shorter the iterations, the better the learning and communication in the team.

5. Empower the team

build projects around motivated individuals ... and trust them to get the job done
- Scott W. Ambler

The developers should be given access to the customer; the team leader should provide support and help in difficult situations, as well as ensure that skepticism does not ruin the team's spirit. Respecting people and acknowledging their work is one way to empower the team.

6 - 1. Build integrity in

Broader in scope, addressing not just quality but also other critical attributes like security, performance, and overall system coherence.

Concept:

• Holistic View: Focuses on the overall integrity of the product, which includes quality but also other aspects like performance, security, and maintainability.
• System Integrity: Ensuring that all parts of the system work together seamlessly and maintain coherence as new features are added.

Practices:

• Architectural Integrity: Ensuring the architecture supports scalability, reliability, and other non-functional requirements.
• Security Practices: Integrating security measures throughout the development process.
• Performance Testing: Regular performance tests to ensure the system meets required benchmarks.

6 - 2. Build quality in

More commonly used in the context of Lean and Agile, focusing on ensuring that the product is defect-free and meets user requirements from the start.

Concept:

• Proactive Approach: Instead of inspecting and fixing defects after they occur, the focus is on preventing defects during the development process.
• Continuous Integration: Emphasizes the importance of continuous testing and integration to catch issues early.
• Automated Testing: Extensive use of automated tests to ensure that code changes do not introduce new defects.
• Collaborative Practices: Encourages collaboration between developers, testers, and other stakeholders to ensure quality from the start.

Practices:

• Test-Driven Development (TDD): Writing tests before coding ensures that the code meets the specified requirements.
• Pair Programming: Two developers work together at one workstation, continuously reviewing each other's code.
• Code Reviews: Regular code reviews by peers to identify potential issues early.
• Continuous Delivery/Deployment: Frequent releases to production to ensure that the software is always in a deployable state.

7 - 1. Optimize the whole

Modern software systems are not simply the sum of their parts, but also the product of their interactions. Defects in software tend to accumulate during the development process – by decomposing the big tasks into smaller tasks, and by standardizing different stages of development, the root causes of defects should be found and eliminated.

7 - 2. See the whole

A quality product is cohesive and well designed as a whole. Individual components must complement the entire user experience.

 

Kanban

Kanban supports Lean methodology very well.

"Just-in-time manufacturing" - imagine how cards were moved in to "bin" and moved to other "bins" in kanban.