Agile Concepts
Pavan Kumar Gorakavi M.S, M.B.A, G.M.C.P,C.A.P.M
Copyright 2010 Pavan Gorakavi
The information in this book is distributed on an ‘as is’ basis without any warranty. Although every precaution has been taken in the preparation of this work, Author is not liable to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the information contained in this work.
What is Agile?
Agile denote nimbleness. Agile methodology is a light weight development methodology which based on iterative development where solutions evolve from tightly collaborated cross functional teams (Gorakavi, 2009). Agile methodology recommends building a project in small increments. It is a disciplined project management methodology which encourages small development life cycles, business part of the development team, periodic analysis and inspection, dynamic modification of requirements, and highly accountable environment. Though the concept of light weight development methodologies were raised in 70’s, agile methodology got much significance in mid 90’s.
What is Agile Manifesto?
Agile manifesto (agilemanifesto) is a set of statements which depicts the principles of agile software development. In early 2000, when many people are having hard time in identifying a methodology which delivers a product quickly and with good responsive index, a group of Industry expert forms into an alliance called themselves as ‘Agile Alliance’. Over two days they worked to create statement of value, which results in agile manifesto. It was first drafted on February 11-13, 2001 in Utah by a group of seventeen Industry experts.
* Further details about agile manifesto can be obtained at https://agilemanifesto.org/
Principles of Agile Manifesto
Agile Manifesto (agilemanifesto) is a set of principles that underpin agile software development. Following principles are derived as part agile manifesto:
1)Individuals and interactions over process and tools
2)Working software over comprehensive documentation
3)Customer collaboration over contract negotiation
4)Respond to change over following a plan.
* Further details about agile manifesto can be obtained at https://agilemanifesto.org/
Principles of Agile Methodology
Agile methodology has primary focus on Individuals and their communication, Working Software over comprehensive documentation, Customer collaboration over contract negotiation, and responding to change over following a plan. We can summarize following principles that differentiate an agile process.
a)Customer Satisfaction
b)Good team with higher accountability
c)Flexible requirements
d)Small and Iterative cycles
e)Communication, Communication and Communication
f)Early feedback
Principles of Agile Methodology- Customer Satisfaction
Customer Satisfaction is one of the important principles of agile methodology. An agile process facilitates the customer to have a quick view of the product. Agile process delivers early and often. As rudimentary system is provided with in first couple of weeks, Customers has a chance to make requirement changes if they feel that what they see doesn’t match with what they envision. Requirements changes dynamically but they strictly adhere to deadlines. This process of correcting the requirements based on the project dynamics reduces the refactoring cost.
Principles of Agile Methodology- Good Team with high accountability
A good team always plays a vital role for project success. As agile methodologies are dynamic in nature, there is always a need for good team players. Though all players need not be strong players, players with higher accountability and user involvement is imperative. An agile team comprises of developers, testers, customers, and any other business related personalities. For a better project results, the team should be empowered to make independent decisions.
Principles of Agile Methodology- Flexible requirements
Requirements have to be light weighted. In agile practice, we can expect change in requirements late in the development process. It should be noted that requirements evolve with fixed time scale. This differentiates agile methodology with conventional development methodology. Requirements are modified in different phases of development process and are based on the project dynamics. Hence requirements for the functional modules should be simple, flexible and lucid.
Principles of Agile Methodology- Small and Iterative Cycles
“Eating an elephant, one Bite at a time” policy should be implemented when we focus on agile methodology. Agile methodology advises to develop project in a small size with an incremental nature. Agile is iterative in nature. This nature reduces the risk of what you see vs. what you envision aspects. It also provides effective cost management, and less re-factor cost. Deliverable is given preference over documentation. Agile methodology is incremental in nature. A rough draft will be available to customers with in first couple of weeks. The agile cycle is at most 2-3 months in size. Sometimes they are even less than that. Agile encourages incremental delivery system with shorter cycles of development. Cycle size varies based on consensus among stakeholders, size of the project, and environment of the project.
Principles of Agile Methodology- Communication, communication and communication
There should be a high degree of communication between the team members in order to implement agile methodology effectively. There should be significant interaction between the customers, developers and stakeholder. Just-In-Tme [JIT] methodology has to be implemented for successful practice of agile methodology.
Principles of Agile Methodology- Early Feedback
Agile team includes developers, testers, and stakeholders. As testers are integral part of development team, unlike traditional methodology, testing can be performed in synch with development. Early product delivery yields early feedback, which opens an option to compare what customers see vs. what they envision. This kind of approach reveals implementation difficulties at an initial stage, which provides an opportunity to renegotiate requirements.
Benefits of Agile Methodology
As agile methodology provides rapid delivery in a dynamic environment, this incremental nature provides cost-effective behavior for product development. This methodology not only enables to deliver cost effective prototype, but also provides flexible re-factoring. In a competitive environment, business always competes with others business by releasing innovative products in a dynamic world, which can be completely supported in agile methodology. As agile methodology delivers products in a small life cycle the risk of handling a project is optimal. As product structure is foreseen at a very early stage of the product, level of structural variation most of the times will be below the tolerance level. As testing team and stake holders are also part of day-to-day activities, quality of the project is relative higher and sticks to core requirements.
What is Extreme Programming
Extreme programming (extremeprogramming.org) is a software engineering methodology which has gained its importance in the arena of agile software development methodologies. Extreme Programming was initially formulated by Kent Beck (Beck, 1999). Extreme Programming is a disciplined methodology which stresses on customer satisfaction. It basically underlines on the concept of ‘deliver when needed’. Extreme programming encourages high degree of interactions between team players, which includes developers, testers, managers, business owners and others. This practice advices the team to possess a lucid information system. Extreme programming emphasizes just not on testing, but testing well. Test cases and tests are created at all stages of coding. As Extreme programming provides early feedback, it will reduce failure cost. It
provides a flexible environment to both customers and developers for changing requirements.
Life Cycle of Extreme Programming
Extreme Programming can be implemented by disciplined methodology which focuses primarily on customer satisfaction. Life cycle of extreme programming includes Planning, Iterative development phase, maintenance phase and death phase (Beck, Extreme Programming explained: Embrace change, 1999). In planning phase user stories are written, Iterative implementation planning is performed, efforts are estimated, and priorities of the features are decided. In Iterative development phase, functional modules are developed using standard software development life cycle process: analysis, design, development and testing. Maintenance phase includes new small releases with customer experience. Once Extreme programming reaches a maturity level where there are no user stories, then product life cycle reaches a death phase.
Life Cycle of Extreme Programming - Planning
User stories are initially written in this phase. User stories are brief 3-4 lines of description about usage scenario. User stories briefly describe about initial details which helps to identify higher level of effort estimations, risk factors involved, and identify basic acceptance test cases. Once user stories are developed, XP team performs a formal meeting with business owners, developers, testers and other key players to identify the priority of the user stories, and formally decide about a release plan. Development team estimates the estimates for each story and how much a team can produce in a given time interval. An iteration planning is being held at the beginning of iteration, user stories scheduled for next iterations, failed acceptance test cases, and any other backlog items are considered as part of this scheduled meeting. The high level tasks are broken down into smaller tasks with technical outlines.
Life Cycle of Extreme Programming - Implementation
In Iterative development phase, functional modules are developed using standard software development life cycle process: analysis, design, development and testing. This is iterative in nature. After user stories tasks are broken down into smaller tasks, the schedule set in the planning stage is broken down to a number of iterations which will each take one to four weeks of implementations. Infrastructure projects are given high priority in initial iteration and the customer decides the stories to be selected for other subsequent iteration.
Life Cycle of Extreme Programming - Maintenance
After the initial release when all acceptance test cases are completed, any subsequent iteration will fall under maintenance phase. In maintenance phase, developers need to handle the request for current production system and next iteration tasks. This development effects development velocity. Maintenance phase includes new small releases with customer experience.
Life Cycle of Extreme Programming - Death Phase
When customers or business clients are done with the user stories and there are no more any new stories, then we consider the XP cycle to be in death phase. This is the last phase of Extreme Programming life cycle.
What is a User Story?
User stories are brief 3-4 lines of description about usage scenario. User stories briefly describe about initial details which helps to identify higher level of effort estimations, risk factors involved, and identify basic acceptance test cases. User stories functions similar to use-cases but at very high level. Often user stories are compared with requirement documents, unlike requirement documents user stories outlines high level statements. User stories avoid technical specifications, user interface layouts and any other micro details. User stories are generally written by either business owners or customers. User stories are generally written on index cards.
What is an Index card?
Index cards has a high level of descriptions about user stories, priority of the story, estimates, and any other details. Prioritization can generally be of High/Medium/Low or number index.
Pair Programming
Pair Programming is an innovative concept of two people sitting together at a single terminal and tries to produce a solution. One person types the program tactically while other person thinks strategically. This approach will produce same functionality when compared with two different people sitting at two different terminals. Researchers reassure a high quality product with pair programming methodology. Pair programming encourages pair-analysis and pair-design to have smooth product delivery. Pair-analysis should include development directions and strategy outlines during complete cycle. As two brains works together, there is always a better chance of yielding a good solution rather than a simple solution. Pair-design helps to identify the defect defects in a very early stage, reducing defect tunnel vision. With the partner discussing on top of other developer’s vision, programmers will have a better understanding of the requirement. After design is completed, pair team starts their implementation. One of the developers will be in driver seat and other will be strategic controller. Unit testing will be performed after pair development by having developers develops test cases together and executing the results.
Advantages of Pair Programming
Errors are identified upfront. This reduces the cost of software maintenance significantly. Design reviews are part of regular pair discussions, which helps in making the design simple and reduces re-factoring cost. Pair-programming facilitates cross-training between developers.
Test Driven Approach
Test Driven development is a software development practice widely used in Extreme Programming. Test driven development advices to build the software in small increments. This approach widely relies on the tests to drive the design of the module. It is a simple evaluation of software from test cases and can also be proclaimed as test-driven approach. Test driven development encourages creating automated unit test cases that define design and code before writing the code itself. Test Driven Development is a unique practice which relies on unit testing and refactoring. Test Driven Development is a methodology which proclaims incremental steps: designing a unit test case, developing a functional module for the unit test case, making the test case pass, and re-factor the code.