- Original at: https://www.versionone.com/wp-content/uploads/2015/06/agile101-software-dev-300×200.gif
Agile Scrum Methodology
Scrum is a management and control process that cuts through complexity to focus on building software that meets business needs. With Scrum methodology, the “Product Owner” works closely with the team to identify and prioritize system functionality in form of a “Product Backlog”. The Product Backlog consists of features, bug fixes, non-functional requirements, etc. – whatever needs to be done in order to successfully deliver a working software system.
- A “process framework” is a particular set of practices that must be followed in order for a process to be consistent with the framework. (For example, the Scrum process framework requires the use of development cycles called Sprints, the XP framework requires pair programming, and so forth.)
- “Lightweight” means that the overhead of the process is kept as small as possible, to maximize the amount of productive time available for getting useful work done.
Lean and Kanban Software Development
Lean Software Development focuses the team on delivering Value to the customer, and on the efficiency of the “Value Stream,” the mechanisms that deliver that Value. The main principles of Lean methodology include:
- Eliminating Waste
- Amplifying Learning
- Deciding as Late as Possible
- Delivering as Fast as Possible
- Empowering the Team
- Building Integrity In
- Seeing the Whole
Lean also concentrates on the efficiency of the use of team resources, trying to ensure that everyone is productive as much of the time as possible.
Kanban is based on 3 basic principles:
- Visualize what you do today (workflow): seeing all the items in context of each other can be very informative
- Limit the amount of work in progress (WIP): this helps balance the flow-based approach so teams don ‘t start and commit to too much work at once
- Enhance flow:
something is finished, the next highest thing from the backlog is pulled into play
Extreme Programming (XP)
In XP, the “Customer” works very closely with the development team to define and prioritize granular units of functionality referred to as “User Stories”.
The original XP recipe is based on four simple values simplicity, communication, feedback, and courage and twelve supporting practices:
- Planning Game
- Small Releases
- Customer Acceptance Tests
- Simple Design
- Pair Programming
- Test-Driven Development
- Refactoring
- Continuous Integration
- Collective Code Ownership
- Coding Standards
- Metaphor
- Sustainable Pace
Crystal
This Crystal family addresses the realization that each project may require a slightly tailored set of policies, practices, and processes in order to meet the project ‘s unique characteristics.
Several of the key tenets of Crystal include teamwork, communication, and simplicity, as well as reflection to frequently adjust and improve the process. Like other agile process methodologies, Crystal promotes early, frequent delivery of working software, high user involvement, adaptability, and the removal of bureaucracy or distractions.
Dynamic Systems Development Method (DSDM)
The DSDM Philosophy is that any project must be aligned to clearly defined strategic goals and focus upon early delivery of real benefits to the business.
DSDM is vendor-independent, covers the entire lifecycle of a project and provides best practice guidance for on-time, in-budget delivery of projects, with proven scalability to address projects of all sizes and for any business sector.
DSDM advocates the use of several proven practices, including:
- Facilitated Workshops
- Modelling and Iterative Development
- *MoSCoW Prioritisation
- Time boxing
DSDM is designed to be easily tailored and used in conjunction with traditional methods such as PRINCE2® or to complement other Agile approaches such as Scrum.
*Requirements are planned and delivered in short, fixed-length time-boxes, also referred to as iterations, and requirements for DSDM projects are prioritized using MoSCoW Rules:
M Must have requirements
S Should have if at all possible
C Could have but not critical
W – Won ‘t have this time, but potentially later
Feature-Driven Development (FDD)
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, “useful in the eyes of the client” results. FDD designs the rest of the development process around feature delivery using the following eight practices:
- Domain Object Modeling
- Developing by Feature
- Component/Class Ownership
- Feature Teams
- Inspections
- Configuration Management
- Regular Builds
- Visibility of progress and results
- The FDD project lifecycle.
FDD recommends specific programmer practices such as “Regular Builds” and “Component/Class Ownership”. FDD’s proponents claim that it scales more straightforwardly than other approaches, and is better suited to larger teams.
In the next post I will be talking deper about Kanban and XP.
