Agile Software Development Methodologies

Agile methodology is being adopted as an alternative to traditional way project management, document driven, heavy weight software development process to help business respond to unpredictability and to guide an iterative and people-centric approach to software development process.

The intension of ASD methodology is to reduce overheads in the software development process and it is to build small parts of the project progress as well as to be able to respond quickly changing requirements without excessive rework. ASD methodology anticipates the need for flexibility and applies a level of desirability into the finished product. Especially this process helps you to keep code simple, testing often and delivering functional bits of the application as soon as they are ready. There are 15 such methodologies and 6 Processes. Shocked? There are quite a lot.  The manifesto of all agile processes is: 1. Individuals and interactions over processes and tools 2. Working software over comprehensive documentation 3. Customer collaboration over contract negotiation 4. Responding to change over following a plan The popular processes are: Scrum: Let’s quickly check it out where it came from Scrum is Rugby (sports) term. The literal meaning of it is:   “An ordered formation of players used to restart play, in which the forwards of a team form up with arms interlocked and heads down” This is how it looks. Every member in a scrum has a specific role to perform. Scrum is the most popular process in the agile software development community due to its simplicity, proven productivity, and ability to act as a wrapper for various engineering practices promoted by other agile methodologies. Its focus is on managing iterative development rather than specific agile practices. Three phases in Scrum:  (I) The initial phase is an outline planning phase where you establish the general objectives for the project and design the software architecture. (II) This is followed by a series of sprint cycles, where each cycle develops an increment of the system. (III) The project closure phase wraps up the project, completes required documentation such as system help frames and user manuals and assesses the lessons learned from the project. 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. With priorities driven by the Product Owner, cross-functional teams estimate and sign-up to deliver “potentially shippable increments” of software during successive Sprints, typically lasting 30 days. Once a Sprint’s Product Backlog is committed, no additional functionality can be added to the Sprint except by the team. Once a Sprint has been delivered, the Product Backlog is analyzed and reprioritized, if necessary, and the next set of functionality is selected for the next Sprint. Lean: Lean Software Development is based on the core principle of eliminate waste activities and increase customer value. It focuses the team on delivering Value to the customer, and on the efficiency of the “Value Stream,” the mechanisms that deliver that Value. 7 key principles of lean software development:  (I) Eliminating Waste: Learn to see and reduce waste such as,

• partially work done
• excess documentation
• extra features
• unnecessary code & functionality
• waiting for the information
• task switching & process
• defects
• unnecessary management activities
• slow communication

 (II)Amplifying Learning: This is the best way for improving software development environment.

• Run tests as soon as the code is written to stop growing defects
• Try different ideas by writing and building code instead of documentation.
• Present screen to the end-user & get their input to simplify requirement gathering process
• take top 3 tools and evaluate them
• increase feedback from client for future improvement
• Implement set-based-development process, this focuses on communicating the constraint of future solution.

(III) Deciding as Late as Possible: Better results should be achieved with an option based approach

• Delay decision until they can be made based on facts and not predictions but provide the needed flexibility for late decision making
• delay your commitments until customer realized their needs better
• maintain flexibility until uncertainty is removed, because you cannot predict the future

(IV) Delivering as Fast as Possible:

• Faster the end product is delivered without defects, the faster feedback can be received and incorporated into the next iteration
• Follow pull system which allow people to figure out for themselves what needs to be done and work becomes self directing
• JIT approach allow for decision about work to be made real-time not in advance
• Queuing theory to reduce cycle time.
• Releasing small package of work, allow you to spread it evenly through the team

 (V) Empowering the Team:

• Empower the people who do the work to make decisions
• let the team design their own working procedure, commitments and avoid micro managing
• Create a sense of purpose at work. People care about a purpose greater the themselves
• Give developer access to the customers

(VI) Building Integrity In: Basically two types of integrity Perceived and conceptual.

• Perceived is affected by the customers whole experience of a system
• Conceptual system’s separate components work well together as a whole with balance between flexibility, maintainability, efficiency, and responsiveness.
• Refactoring is one healthy way toward integral architecture. It maintains simplicity, clarity, suitability for use, and no repetition of code & extra features.

(VII) Seeing the Whole: Software system is not just a sum of its small parts, its a product of those interactions and when the systems start to break down, rigid more sequential rules are usually put in place and this process can cure one symptom, but not the root cause. It will become increasingly difficult to keep up with changing needs. Kanban: It emphasizes on continual delivery while not overburdening the development team. Like Scrum, Kanban is a process designed to help teams work together more effectively. Kanban is based on 3 basic principles:  (I) Visualize what you do today (workflow): seeing all the items in context of each other can be very informative (II) 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 (III) Enhance flow: when something is finished, the next highest thing from the backlog is pulled into play Extreme Programming (XP): The original XP recipe is based on four simple values – simplicity, communication, feedback, and courage – and twelve supporting practices:  (I) Planning Game: Business and Devops Services Company to produce the maximum business value as rapidly as possible. The planning game happens at various scales, but the basic rules are always the same: o Business comes up with a list of desired features for the system. Each feature is written out as a user story, which gives the feature a name, and describes in broad strokes what is required. . o Development estimates how much effort each story will take, and how much effort the team can produce in a given time interval. o Business then decides which stories to implement in what order, as well as when and how often to produce a production release of the system. (II) Small Releases: The minimal useful set of functionality that provides business value is developed first. Releases of the system are frequent and incrementally add functionality to the first release. (III) Customer Acceptance Tests: also known as functional Tests are specified by the customer to test that the overall system is functioning as specified. Acceptance tests typically test the entire system, or some large chunk of it. When all the acceptance tests pass for a given user story, that story is considered complete. At the very least, an acceptance test could consist of a script of user interface actions and expected results that a human can run. Ideally acceptance tests should be automated, either using the unit testing framework, or a separate acceptance testing framework.  (IV)Simple Design: Enough design is carried out to meet the current requirements and no more.  (V) Pair Programming: Developers work in pairs checking each other’s work and providing the support to always do a good job.  (VI) Test-Driven Development: An automated unit test framework is used to write tests for a new piece of functionality before that functionality itself is implemented.  (VII) Refactoring: All developers are expected to refactor the code continuously as soon as possible code improvements are found. This keeps the code simple and maintainable.  (VIII) Continuous Integration: As soon as the work on a task is complete, it is integrated into the whole system. After any such integration, all the unit tests in the system must pass. (IX) Collective Code Ownership: The pairs of developers work on all areas of the system, so that no islands of expertise develop and all the developers take responsibility for all of the code. Anyone can change anything. (X) Coding Standards: Everyone codes to the same standards. Ideally, you shouldn’t be able to tell by looking at it who on the team has touched a specific piece of code. (XI) Metaphor: Each project has an organizing design which help new people being contributing quickly , and it makes naming classes and method consistent. (XII) Sustainable Pace: Projects do not follow the ‘Crunch Time’ in XP because development cycles are short cycles of continuous integration and are more frequent. In other side it gives best of the performance and more creativity from developers Crystal: Crystal includes teamwork, communication, and simplicity, as well as reflection to frequently adjust and improve the process. Crystal promotes early, frequent delivery of working software, high user involvement, adaptability, and the removal of bureaucracy or distractions. Dynamic System Development Method (DSDM): It’s primarily revolved around business needs/value, active user involvement, empowered teams, frequent delivery, integrated testing, and stakeholder collaboration. DSDM specifically calls out “fitness for business purpose”. 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-Driver Development: 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.  (I)Domain Object Modeling: It is consist of exploring and explaining the domain of the problem to be solved. The resulting model provides an overall framework in which to add features.  (II) Developing by Feature: Any function that is too complex to be implemented within two weeks is further decomposed into smaller functions until each sub problem is small enough to be called a feature. This makes it easier to deliver correct functions and to extend or modify the system. (III) Component/Class Ownership: Individual class ownership means that distinct pieces or grouping of code are assigned to a single owner. The owner is responsible for the consistency, performance, and conceptual integrity of the class. (IV) Feature Teams: A feature team is a small, dynamically formed team that develops a small activity. By doing so, multiple minds are always applied to each design decision and also multiple design options are always evaluated before one is chosen. (V) Inspections: Carried out to ensure good quality design and code, primarily by detection of defects. (VI) Configuration Management: It helps with identifying the source code for all features that have been completed to date and to maintain a history of changes to classes as feature teams enhance them. (VII) Regular Builds: Regular builds ensure there is always an up to date system that can be demonstrated to the client and helps highlighting integration errors of source code for the features early. (VIII) Visibility of Progress and Results: By frequent, appropriate, and accurate progress reporting at all levels inside and outside the project, based on completed work, managers are helped at steering a project correctly.