Agile Methodology and Frameworks

Agile is a philosophy and a mindset. Agile is not a methodology. Agile consists of a set of methodologies and frameworks which fulfill certain aspects of the Agile Manifesto described earlier. I look at Agile as a umbrella with various agile methodology and frameworks under the umbrella

Following are some of the popular Agile Methodology (ies) and Frameworks

• Scrum
• Lean software development
• Extreme Programming(XP)
• Dynamic Systems Development Method (DSDM)
• Test Driven Development (TDD)
• Acceptance Test Driven Development (ATDD)

We will also learn in this post about applying ITSM principles to Agile

Scrum

Scrum is an iterative and incremental Agile software development framework for managing software projects and product or application development. Its focus is on “a flexible, holistic product development strategy where developers works as a unit to reach a common goal” as opposed to a “traditional, sequential approach”. Scrum enables the creation of self-organizing teams by encouraging co-location of all team members, and verbal communication among all team members and disciplines in the project.

Scrum is a project Management framework which enables one to execute the projects. The other methodology tools and techniques work very well in the Scrum framework. Following picture depicts the Scrum as a framework working with tools and techniques from other methods such as Lean, Extreme Programming, TDD and DSDM.

We will be studying SCRUM in detail in the next few chapters.

Lean Software Development

The core idea is to maximize customer value while minimizing waste. Simply, lean means creating more value for customers with fewer resources.

A lean organization understands customer value and focuses its key processes to continuously increase it. The ultimate goal is to provide perfect value to the customer through a perfect value creation process that has zero waste.

To accomplish this, lean thinking changes the focus of management from optimizing separate technologies, assets, and vertical departments to optimizing the flow of products and services through entire value streams that flow horizontally across technologies, assets, and departments to customers.

Eliminating waste along entire value streams, instead of at isolated points, creates processes that need less human effort, less space, less capital, and less time to make products and services at far less costs and with much fewer defects, compared with traditional business systems. Companies are able to respond to changing customer desires with high variety, high quality, low cost, and with very fast throughput times. Also, information management becomes much simpler and more accurate.

Extreme Programming

Reference : http://www.extremeprogramming.org

Extreme Programming (XP) is a software development agile methodology which is intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development, it advocates frequent “releases” in short development cycles, which is intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted.

Extreme Programming improves a software project in five essential ways;

• communication
• simplicity
• feedback
• respect
• courage

DSDM

Dynamic systems development method (DSDM) is an agile methodology, primarily used as a software development method. First released in 1994, DSDM originally sought to provide some discipline to the rapid application development (RAD) method. In 2007 DSDM became a generic approach to project management and solution delivery. DSDM is an iterative and incremental approach that embraces principles of Agile development, including continuous user/customer involvement.

DSDM fixes cost, quality and time at the outset and uses the MoSCoW prioritisation of scope into musts, shoulds, coulds and won’t haves to adjust the project deliverable to meet the stated time constraint. DSDM is one of a number of Agile methods for developing software and non-IT solutions, and it forms a part of the Agile Alliance.

The previous version of DSDM (released in May 2003) which is still widely used and is still valid is DSDM 4.2 which is a slightly extended version of DSDM version 4. The extended version contains guidance on how to use DSDM with Extreme Programming.

DSDM Principles

There are eight principles underpinning DSDM. These principles direct the team in the attitude they must take and the mindset they must adopt in order to deliver consistently.

• Focus on the business need
• Deliver on time
• Collaborate
• Never compromise quality
• Build incrementally from firm foundations
• Develop iteratively
• Communicate continuously and clearly
• Demonstrate control

Test Driven Development – TDD

Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards. Kent Beck, who is credited with having developed or ‘rediscovered’ the technique, stated in 2003 that TDD encourages simple designs and inspires confidence.

Test-driven development is related to the test-first programming concepts of extreme programming, begun in 1999, but more recently has created more general interest in its own right.

Programmers also apply the concept to improving and debugging legacy code developed with older techniques

Test-driven development cycle

A graphical representation of the development cycle, using a basic flowchart

The following sequence is based on the book Test-Driven Development by Example.

Add a test

In test-driven development, each new feature begins with writing a test. This test must inevitably fail because it is written before the feature has been implemented. (If it does not fail, then either the proposed “new” feature already exists or the test is defective.) To write a test, the developer must clearly understand the feature’s specification and requirements. The developer can accomplish this through use cases and user stories to cover the requirements and exception conditions, and can write the test in whatever testing framework is appropriate to the software environment. This could also be a modification of an existing test. This is a differentiating feature of test-driven development versus writing unit tests after the code is written: it makes the developer focus on the requirements before writing the code, a subtle but important difference.

Run all tests and see if the new one fails

This validates that the test harness is working correctly and that the new test does not mistakenly pass without requiring any new code. This step also tests the test itself, in the negative: it rules out the possibility that the new test always passes, and therefore is worthless. The new test should also fail for the expected reason. This increases confidence (though does not guarantee) that it is testing the right thing, and passes only in intended cases.

Write some code

The next step is to write some code that causes the test to pass. The new code written at this stage is not perfect, and may, for example, pass the test in an inelegant way. That is acceptable because later steps improve and hone it.

At this point, the only purpose of the written code is to pass the test; no further (and therefore untested) functionality should be predicted and ‘allowed for’ at any stage.

Run tests

If all test cases now pass, the programmer can be confident that the code meets all the tested requirements. This is a good point from which to begin the final step of the cycle.

Refactor code

Now the code should be cleaned up as necessary. Move code from where it was convenient for passing the test to where it logically belongs. Remove any duplication you can find. Make sure that variable and method names represent their current use. Clarify any constructs that might be misinterpreted. Use Kent Beck’s four rules of simple design to guide you, as well as anything else you know about writing clean code. By re-running the test cases, the developer can be confident that code refactoring is not damaging any existing functionality.

The concept of removing duplication is an important aspect of any software design. In this case, however, it also applies to removing any duplication between the test code and the production code—for example magic numbers or strings repeated in both to make the test pass in step 3.

Repeat

Starting with another new test, the cycle is then repeated to push forward the functionality. The size of the steps should always be small, with as few as 1 to 10 edits between each test run. If new code does not rapidly satisfy a new test, or other tests fail unexpectedly, the programmer should undo or revert in preference to excessive debugging. Continuous integration helps by providing revertible checkpoints. When using external libraries it is important not to make increments that are so small as to be effectively merely testing the library itself, unless there is some reason to believe that the library is buggy or is not sufficiently feature-complete to serve all the needs of the main program being written.

Acceptance Test Driven Development

Acceptance Test Driven Development (ATDD) is the extension of Test Driven Development TDD in agile. The ATDD includes typical tests that test the behavior of the system. ATDD needs to test the expected behavior of the system from the user’s point of view.

Steps followed by an agile team in ATDD agile:

Discuss : During the planning meeting we ask the product owner or customer questions that are designed to gather acceptance criteria.

Distill : In this phase we get the tests ready (distill) to be entered into the acceptance test tool. .

Develop: In this phase we develop the code and hook up the tests. Initially the tests fail because they cannot find the necessary code. Once the code is written and tests are hooked to it, the tests validate the code. They may again fail, so the proeces of writing code and testing continues until the code passes the tests.

Demo : The team does exploratory testing using the automated acceptance testing scripts and demos the software to the customer.

Applying Agile Principles to ITSM

First of all, using practices from Agile methodologies such as Scrum in the context of ITSM does not necessarily make ITSM Agile. There are instance where people have set up a support team using an issue backlog similar to the sprint backlog from Scrum, are doing daily stand-up meetings with that team to review progress and impediments to progress, and a number of other practices similar to Scrum. Doing Agile is not the same as being Agile, instead, it is actually about improving ITSM practices by applying Agile principles.

Let us take a principles-based approach to applying Agile to ITSM, not a practice-based approach. The difference is that the principles give guidance on how to do things in a better way, whereas the practices just follow from these principles in the specific context of the services you provide.

Agile principles, as per the Agile Manifesto and Principles discussed earlier, come down to a number of core items:

• Focus on value creation for the customer – this is the external view on service management that needs to be kept in mind at all times: what is the benefit of what we do in service management for the party that ultimately should reap its fruits, the customer?
• Focus on people – this is an internal view, which puts the people and teams performing all the activities to make sure services are delivered in the centre of attention.
• Close collaboration between the customer and the service provider.
• Flexibility in dealing with changing requirements and a changing environment.
• Incremental and iterative service design, implementation and improvement.
• Simplicity and efficiency in service design and operation.