agile methodologies in software development - ijetmas.com

International Journal of Engineering Technology, Management and Applied Sciences

www.ijetmas.com November 2014, Volume 2 Issue 6, ISSN 2349-4476

AGILE METHODOLOGIES IN SOFTWARE DEVELOPMENT Nayab Zya#1, Mohammad Suaib#2 1

M.Tech (CSE), Second Year 2

#

Research Guide

Department of Computer Science and Engineering Integral University, Lucknow Uttar Pradesh, India

Abstract The traditional strategies were chaotic nature of software development, it may be impossible to control or to predict and which did not give the company many chances to integrate all the latest changes effectively. This raised a need for a light weight and flexible methodology to overcome the basic issues in traditional methodologies. So the Agile Methodology was born that aims to overcome the problems faced in traditional development/testing methodologies and also to easily maneuver software activities in today’s complex Business activities using light weight practices and adaptability. Keywords: Agile Methodologies - eXtreme Programming, Scrum and Kanban Methodologies

Introduction The object of the article is to uncover the disadvantages of the traditional methodologies with Agile Methodology. Lets discuss why OLD / Traditional methodologies did not work: Detailed test planning was required in traditional methodologies  Not enough time  Too many changes Dedicating a phase for testing  No iterations, so complete testing needs to be done in fixed timelines  In Agile, a good tester is never done with his testing due to frequent changes in every iteration Change control  Changes are a commonplace in today’s world, which happen on the fly and all these frequent changes could not be incorporated

9

Nayab Zya, Mohammad Suaib


www.ijetmas.com November 2014, Volume 2 Issue 6, ISSN 2349-4476 So Agile is designed to break the software down into manageable parts that can be delivered earlier to the customer. The aim of any Agile project is to deliver a basic working product as quickly as possible and then to go through a process of continual improvement. An Agile project is characterized by having a large number of short delivery cycles (sprints) and priority is given to the feedback-loops from one cycle to the next. The feedback-loops drive continuous improvement and allow the issues that inevitably occur (including the way requirements have been defined or the quality of the solution provided) to be dealt with much earlier in the development life cycle. To achieve this, companies need to re-think their approach to delivery an have their previously independent contributors (Business Analysts, Developers, Testers, End Users etc.) worked together in teams. It favors direct communication within the team as well as the customer over complete documentation and quick adaptation to change instead of fixing the problem later on. However, Agile methodology is followed differently in different organizations; but still, they share certain common principles.Here are some popular agile methodologies:   

Scrum, Extreme Programming and KANBAN

Agile - Extreme Programming (XP) Extreme Programming was introduced by Kent Beck in 2000. Being an emerging agile methodology, XP offers a number of practices, values and principles which are advised to be adopted in order to run a software development project [1]. XP is a package of several practices and ideas, most of which are not new. The combination and packaging of all of these is, however, new [2]. Extreme Programming was infact targeted especially at small co-located teams developing non-critical products. It has been suggested that the early adopters of agile methods have been small high-tech product companies [3]. Currently, however, it has already been proven at many companies of all different sizes and industries worldwide [4]. extreme Programming (XP) is an Agile Software Development technique intended to enhance software quality and responsiveness to changing users requirements. It advocates frequent "releases" in short development cycles (timeboxing), which is intended to enhance productivity and introduce checkpoints where new users requirements can be adopted. (Definition is taken from Wikipedia) [5]

10



www.ijetmas.com November 2014, Volume 2 Issue 6, ISSN 2349-4476 Extreme Programming is successful because it stresses customer satisfaction. Instead of delivering everything you could possibly want on some date far in the future this process delivers the software you need as you need it. Extreme Programming empowers the developers to confidently respond to changing customer requirements, even late in the life cycle. It emphasizes teamwork. Managers, customers, and developers are all equal partners in a collaborative team. Extreme Programming implements a simple, yet effective environment enabling teams to become highly productive. The team self-organizes around the problem to solve it as efficiently as possible.

This flow chart [5] shows how Extreme Programming's rules work together. Customers enjoy being partners in the software process, developers actively contribute regardless of experience level, and managers concentrate on communication and relationships. Unproductive activities have been trimmed to reduce costs and frustration of everyone involved. XP planning addresses two key questions in software development: predicting what will be accomplished by the due date, and determining what to do next. The emphasis is on steering the project — which is quite straightforward — rather than on exact prediction of what will be needed and how long it will take — which is quite difficult. There are two key planning steps in XP: Release planning where the Customer presents the desired features to the programmers and the programmers estimate their difficulty. With the cost estimates in hand, and with knowledge of the importance of the features, the Customer lays out a plan for the project. Initial release plans are necessarily imprecise: neither the priorities nor the estimates are truly solid, and until the team begins to work, we won’t know just how fast they will go. Even the first release plan is accurate enough for decision making, however, and XP teams revise the release plan regularly. Iteration Planning is the practice whereby the team is given direction every couple of weeks. XP teams build software in two-week “iterations”, delivering running useful software at the end of each

11



www.ijetmas.com November 2014, Volume 2 Issue 6, ISSN 2349-4476 iteration. During Iteration Planning, the Customer presents the features desired for the next two weeks. The programmers break them down into tasks, and estimate their cost (at a finer level of detail than in Release Planning). Based on the amount of work accomplished in the previous iteration, the team signs up for what will be undertaken in the current iteration. The best XP teams treat their customer tests the same way they do programmer tests: once the test runs, the team keeps it running correctly thereafter. This means that the system only improves, always notching forward, never backsliding. Features of eXtreme Programming     



Design in XP is not a one-time thing, or an up-front thing, it is an all-the-time thing. All production software in XP is built by two programmers, sitting side by side, at the same machine. Two heads really are better than one! Extreme Programming is obsessed with feedback, and in software development, good feedback requires good testing. Top XP teams practice “test-driven development”, working in very short cycles of adding a test, then making it work. XP uses a process of continuous design improvement called Refactoring, The refactoring process focuses on removal of duplication (a sure sign of poor design), and on increasing the “cohesion” of the code, while lowering the “coupling”. Extreme Programming teams keep the system fully integrated at all times. We say that daily builds are for wimps: XP teams build multiple times per day.

Agile - SCRUM SCRUM methodology was initiated by Ken Swaber in 1995. It was practiced before the announcement of Agile Manifesto. Later, it was included into agile methodology since it has the same underlying concepts and rules of agile development. SCRUM has been used with the objective of simplifying project control through simple processes, easy to update documentation and higher team iteration over exhaustive documentation [6]. SCRUM has a well defined software development life cycle and methodology, covering aspect of project management and engineering development. SCRUM is generally perceived as incremental development on base product, however, in several real life situations, SCRUM is implemented on a reference architecture (that is developed linearly) or blueprint, covering typically infrastructure/ reusable services, like persistence management, transaction management, error handling, audit trail etc.

12



www.ijetmas.com November 2014, Volume 2 Issue 6, ISSN 2349-4476 SCRUM Process

“Story” is a business and functional requirement created in a simple language, allowing developer and client/customer to discuss requirements throughout the project lifetime. Their main purpose is to influence the software development. Then they are passed on to the testers. Allow projects to be broken into small increments each story spans across one or more functional areas. “Sprint” is an incremental development step (1-4 week of calendar time) that contributes to product development, or series of sprints contribute to product development. Each sprint starts with a “Sprint planning meeting” to decide about the features to be implemented in that sprint. “Backlog” is quantum of work to be accomplished in product development. Backlog is list of features/ functionalities to be implemented, generally categorized as: Product Backlog: A prioritized list of all the desired changes (including new features) to the product being developed put together by the product owner. Sprint Backlog: A list of items that will be completed in the current sprint. These items are taken from the product backlog. “Scrum Meetings” are daily short discussions that happen within the team to discuss what was done on that scrum and the activities planned for next scrum. Meaning, all developers/testers will now know the exact progress and happenings in their team. “Scrum Team” that means both developers and testers. Each team will keep the ownership for identified modules / business areas.“Scrum Master” is leading the team. He will not actually lead the team, but act as a buffer to remove any hindering influences, to facilitate the team to reach the sprint goal. Team – Roles & Responsibilities SCRUM team is generally managed by the SCRUM Master, the team overall is responsible for estimation, reviewing product backlog list and suggesting impediments removed from project.

13



www.ijetmas.com November 2014, Volume 2 Issue 6, ISSN 2349-4476 Role

Key Responsibilities

Customer



Management



Participates in tasks related to product backlog list

Makes final decision making along with charters, standards and conventions to be followed in project  Participates in setting of goals and requirements SCRUM  Ensures that project is carried according to the practices, values and rules of SCRUM and monitor the project’s progress Master  Interacts with projects team, customer and management during the project & ensures that impediments are removed. Selects product owner Product Owner  Responsible for managing and controlling the project and making visible the product backlog list  Makes decision on task related to product backlog  Estimates the development effort for backlog items  Turns the issues in the backlog into features to be developed SCRUM Implementation

14



www.ijetmas.com November 2014, Volume 2 Issue 6, ISSN 2349-4476 SCRUM defines three major phases with several sub-phases and activities defined. These phases are summarized as Pre-game (largely contributing to planning and system architecture/ high level design), Game (Sprints where the product is developed) and Post Game (Closure for release and final documentation) SCRUM development methodology, Sprint contributes to development from backlog, packaging, review and adjustment to the backlog list of requirement. 5-step (Plan, Design, Code, Test and Demo) of each sprint mapped to standard software development activities. Sprint promotes flexibility and alternate approach identification allowing development initiatives to remain aligned with the business goals of the product. Features of SCRUM      

Customer focused: With disruptive transformation in the industry, customer are challenged to respond to change quickly to maintain competitive advantage, SCRUM provide a native capability to managing changing requirements effectively. Time to Market: SCRUM definitely score in quickly produces something useful, keeps making useful enhancements and hence very well suited to R&D initiatives and high risk projects where continuous customer feedback is critical to the success of project Higher Team Productivity: With continuous integration, use of automated tools, avoidance of rework, SCRUM usually improves the team productivity. Shorter Release Cycles: Hence minimal risk, very well suite for R&D initiatives and innovative products that needs customer feedback and insight on regular basis. Continuous feedback: And communication, avoids rework, reduce the risk and improve the development productivity. Team unification: Promotes one team, one goal between the business and IT teams, hence joint accountability/ enhanced acceptance and ownership of the product from business.

Agile - KANBAN The name ‘KANBAN’ originates from Japanese, and translates roughly as "signboard"[7]. KANBAN traces back to the early days of the Toyota production system. Taiichi Onho developed 1940/1950 KANBANs to control production between processes and to implement Just In Time (JIT) manufacturing at Toyota manufacturing plants in Japan. The KANBAN method as formulated by David J. Anderson is an approach to incremental, evolutionary process and systems change for organizations. It uses a work-in-progress limited pull system as the core mechanism to expose system operation (or process) problems and stimulate collaboration to continuously improving the system. One example of such a pull system is a KANBAN system, and it is after this popular form of a work-in-progress limited pull system that the method is named [8].

15



www.ijetmas.com November 2014, Volume 2 Issue 6, ISSN 2349-4476 KANBAN is all about Flow : Festina lente – Latin proverb “Translation: Make haste slowly. In Aesop’s fable, “The Tortoise and the Hare,” the hare excelled at adding value quickly, but still lost the race due to inactivity. Eliminating periods of inactivity, such as time spent in queues, can be far more important than speeding up activities [9].” KANBAN in a Nutshell [10]: 

 

Visualize the workflow o Split the work into pieces, write each item on a card and put on the wall o Use named columns to illustrate where each item is in the workflow. Limit WIP (work in progress) – assign explicit limits to how many items may be in progress at each workflow state. Measure the lead time (average time to complete one item, sometimes called “cycle time”), optimize the process to make lead time as small and predictable as possible. This is a direct implementation of a lean pull scheduling system. Here’s an example of a simple KANBAN board, with WIP limits in red [10].

KANBAN might be useful if: “Everyone is way too busy, yet work is not getting finished.” KANBAN limits work in progress and forces focus and team collaboration. It leads to an even, sustainable pace. 

“The development process is painful and long but no one really knows why” KANBAN exposes bottlenecks in your system so you can deal with them directly.

“Team doesn’t want to change too much all at once” KANBAN practices aren’t radical changes and they can be adopted gradually. 

“Team members want to engage the team more” KANBAN can lead to kaizen, a culture of continuous improvement.

16



www.ijetmas.com November 2014, Volume 2 Issue 6, ISSN 2349-4476 “Team’s workload doesn’t map to iterations” KANBAN provides a model for work to flow continuously.The KANBAN method is rooted in these basic principles: Start with what you do now The KANBAN method does not prescribe a specific set of roles or process steps. There is no such thing as the KANBAN software development process or the KANBAN project management method. The KANBAN method starts with the roles and processes you have and stimulates continuous, incremental and evolutionary changes to your system. Agree to pursue incremental, evolutionary change The organization (or team) must agree that continuous, incremental and evolutionary change is the way to make system improvements and making them stick. Sweeping changes may seem more effective but more often than not fail due to resistance and fear in the organization. The KANBAN method encourages continuous small incremental and evolutionary changes to your current system. Respect the current process, roles, responsibilities & titles It is likely that what the organization currently does have some elements that work acceptably and are worth preserving. We must also seek to drive out fear in order to facilitate future change. By agreeing to respect current roles, responsibilities and job titles we eliminate initial fears. This should enable us to gain broader support for our KANBAN initiative. Perhaps presenting KANBAN against an alternative more sweeping approach that would lead to changes in titles, roles, responsibilities and perhaps the wholesale removal of certain positions will help individuals to realize the benefits. Features of KANABAN       

Shorter cycle times can deliver features faster. Responsiveness to Change: When priorities change very frequently, Kanban is ideal. Balancing demand against throughput guarantees that most the customer-centric features are always being worked. Requires fewer organization / room set-up changes to get started Reducing waste and removing activities that don’t add value to the team/department/organization Rapid feedback loops improve the chances of more motivated, empowered and higherperforming team members

Conclusion

17



www.ijetmas.com November 2014, Volume 2 Issue 6, ISSN 2349-4476 Software development methodologies have evolved since the 1970s. Agile methodologies came into existence after the need for a light way to do software development in order to accommodate changing requirements environment. Agile methodologies provide some practices that facilitate communication between the developer and the customer, and undergo develop-deliver-feedback cycles, to have more specific view of the requirements, and be ready for any change at any time. The main aim of agile methodologies is to deliver what is needed when it is needed. Agile methodologies include a set of software development approaches. They have some variations, but still they share the same basic concepts. The main agile methodologies that are being used include XP, SCRUM and KANBAN. XP is the coding of what the customer specifies, and the testing of that code. SCRM, on the other hand, supports management role in software development. KANBAN is a method for managing the creation of products with an emphasis on continual delivery while not overburdening the development team.

References [1] K. Beck, and C. Andres, Extreme Programming Explained: Embrace Change (2nd Edition), Addison-Wesley, Boston, 2004. [2] D. Karlström, Introducing Extreme Programming - An Experience Report. In proceedings 3rd International Conference on eXtreme Programming and Agile Processes in Software Engineering, XP Sardinia, Italy. [3] C. Schwaber and R. Fichera, Corporate IT leads the second wave of agile adoption. Forrester Research, Inc, 2005. [4] Extreme Programming. What is Extreme Programming? [Online] Retrieved 18th March 2009. Available at: www.extremeprogramming.org [5] From Wikipedia, the free encyclopedia, Available at:http://en.wikipedia.org/wiki/Extreme_programming [6] M. Cristal, D. Wildt and R. Prikladnicki, Usage of SCRUM Practices within a Global Company. Global Software Engineering, 2008. ICGSE 2008. IEEE International Conference on, 2008, 222-226. [7] From Wikipedia, the free encyclopedia, Available at: http://en.wikipedia.org/wiki/Extreme_programming [8] Bayzone, Thinking and inspiration Available at: http://bayzone.wordpress.com/2012/10/22/kanban-some-myths-andtruths/ [9] Principles of Product Development Flow by Don Reinertsen [10] Henrik Kniberg, Kanban vs Scrum Version 1.1 (2009-06-29) Deprecated version! Latest version is available at : http://www.crisp.se/file-uploads/Kanban-vs-Scrum.pdf [11] Gratis material och guider, Kanban, available at: http://www.crisp.se/gratis-material-och-guider/kanban

18
