How To Understand And Understand The Benefits Of Agile Software Development

(1)

W

H

ITE

P

A

PE

R

Adopting Agile Methods for Software

Projects

To Achieve Competitive Advantage

Version 1.1 March, 2013

(2)

Getting ready for PLM

Copyright Notice

No part of this document (whether in hardcopy or electronic form) may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, to any third party without the written permission of Geometric Limited. Geometric Limited reserves the right to change the information contained in this document without prior notice.

The names or trademarks or registered trademarks used in this document are the sole property of the respective owners and are governed/ protected by the relevant trademark and copyright laws.

This document is provided by Geometric Limited for informational purposes only, without representation or warranty of any kind, and Geometric Limited shall not be liable for errors or omissions with respect to the document. The information contained herein is provided on an “AS-IS” basis and to the maximum extent permitted by applicable law, Geometric Limited hereby disclaims all other warranties and conditions, either express, implied or statutory, including but not limited to, any (if any) implied warranties, duties or conditions of merchantability, of fitness for a particular purpose, of accuracy or completeness of responses, of results, of workmanlike effort, of lack of viruses, and of lack of negligence, all with regard to the document.

THERE IS NO WARRANTY OR CONDITION OF NON-INFRINGEMENT OF ANY INTELLECTUAL PROPERTY RIGHTS WITH REGARD TO THE DOCUMENT. IN NO EVENT WILL GEOMETRIC LIMITED BE LIABLE TO ANY OTHER PARTY FOR LOST PROFITS, LOSS OF USE, LOSS OF DATA, OR ANY INCIDENTAL, CONSEQUENTIAL, DIRECT, INDIRECT, OR SPECIAL DAMAGES WHETHER UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING IN ANY WAY OUT OF THIS DOCUMENT, WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES.

Confidentiality Notice

This document is disclosed only to the recipient pursuant to a confidentiality relationship under which the recipient has confidentiality obligations defined herein after. This document constitutes confidential information and contains proprietary information belonging to Geometric Limited, and the recipient, by its receipt of this document, acknowledges the same. The recipient shall use the confidential information only for the purpose defined above for which this document is supplied. The recipient must obtain Geometric Limited’s written consent before the recipient discloses any information on the contents or subject matter of this document or part thereof to any third party which may include an individual, firm or company or an employee or employees of such a firm or company. The recipient acknowledges its obligation to comply with the provisions of this confidentiality notice.

(3)

Introduction ... 4

Agile Software Development ... 4

Agile Manifesto ... 5

Agile Methods and Techniques ... 6

Agile Practices ... 9

Agile Development Process Model ... 9

Common Project Management Challenges in Applying Agile ... 15

Conclusion ... 18

References ... 19

About the Author ... 19

(4)

Introduction

Ever changing market conditions are forcing companies to shorten delivery cycles and become more responsive to customer expectations. Project Managers are being tasked with energizing and focusing their project teams to improve productivity and responsiveness to business change, provide quicker time to market, produce higher quality product, reduce costs and increase customer satisfaction. Known limitations in traditional software development methodologies have lead many organizations to adopt or experiment with AGILE application development processes to address these challenges.

Agile methodologies were designed with small co-located, cross functional teams in mind. However companies with large and geographical dispersed teams also have to move ahead and adopt agile approaches to software development. But it is simply not practical to just ‘flip a switch’ and have a 1,000 person department start doing agile. These organizations must wade through a transition period where agile and waterfall models have to coexist.

To address these transition challenges a number of more agile and adaptive software development techniques are being adopted which allow companies to deliver higher quality software more quickly. This knowledge paper presents an accumulated view of the key aspects of agile methods as talked of and documented in the industry and describes an agile software development approach and process model for high assurance systems that addresses many of the challenges found in these environments.

Agile Software Development

Major reasons for Agile software development methodologies attracting considerable attention in the past few years can, in general, be attributed to the following advantages over traditional plan-driven approaches:

• Improved return on investment (ROI): Customers provide frequent feedback on each iteration, which allows the development team to create better software, thus improving the ROI.

• Early detection and cancellation of failing projects: In traditional projects, optimistic reporting on abstract tasks such as analysis and design, in general, delays the problems from being identified in the early stages of the project. Agile methods execute design, analysis, and implementation tasks repeatedly in short iterations allowing greater visibility on the state of progress of the project. Sponsors can cancel the project early if they find it is not going as expected and thus loose minimal investment.

• Higher software quality: Test-driven development, short iterations, scoping, and frequent customer feedback improve the overall quality of the software.

• Improved control over project: Agile processes focus on people over processes. With less stress on documentation and more attention on delivering functionality at the end of each

(5)

iteration, agile teams can improve their velocity. Short iterations, multi-disciplinary teams, knowledge sharing, continuous integration, and feedback allow better control over the project and increased visibility.

• Reduced dependence on individuals and increased flexibility: Agile practices emphasize on creating cohesive teams of developers that collectively analyze, design, and code software. This eliminates the possibility of any bottlenecks in the development process because of developers working individually on tasks.

Agile Manifesto

In February 2001, seventeen representatives from the different agile methods decided to form an Agile Software Development Alliance (www.agilealliance.com) to address the challenges faced by software developers and to better promote their views. Most of the agile techniques have been used by developers before the alliance but it is after the alliance that these techniques were grouped together into a workable framework. They crafted a manifesto, and a collection of supporting principles, for encouraging better ways of developing software. The manifesto defines four values and twelve principles which form the foundation of the agile movement.

The focal values honored by the agilists are presented in the following: We are uncovering better ways of developing

software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more. The 12 principles of agile software development from the Agile Manifesto are:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

(6)

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity--the art of maximizing the amount of work not done--is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and

adjusts its behavior accordingly.

Agile Methods and Techniques

Even though agile ways of development have been around since the 1960s, only recently has the agile model gained so much momentum that it has turned into a major movement within the software industry. This movement has led many project managers to investigate what it means to be ‘agile’ and practice agile methods.

Agile development methods focus on a portion of the overall delivery lifecycle. Section below overviews some core agile methods, indicating the purpose or scope of the method as well providing a list of representative practices (the practice lists are not meant to be complete). It is interesting to note that several practices are supported by one or more methods, an indication of the compatibility between the methods. Disciplined agile delivery teams will typically mine the core agile methods for practices and ideas which are then combined to form a more robust process. Each method has its own unique focus and approach, a specific process scope which it addresses, and uses its own terminology.

eXtreme Programming (XP)

Extreme Programming, or XP, is a software development methodology that prescribes a set of 12 engineering practices that embody and encourage the XP values of communication, feedback, simplicity, courage, and respect. These practices such as continuous integration, test-driven development, and pair programming, help the development team stay responsive to the customer’s needs. XP teams are small and co-located. Their practitioners embrace the fact that product requirements change, and change for good reason, while working in iterations alongside the customer to capture and implement the requirements for immediate feedback.

Kent Beck created XP, and coined the phrase to reflect that in this discipline teams were to take things that had been proven as good practices to the extreme. For example, if peer reviews are good, then the team should have peer reviews all the time in the form of paired programming. If testing is a good thing to do, then the team should do that all the time as well, in the form of unit

(7)

testing. Each practice is done in an extreme way, culminating in technical excellence and rapid iterative delivery.

Scrum

Scrum is an iterative, incremental process for developing any product or managing any work. It produces a potentially shippable set of functionality at the end of the iteration. Scrum focuses on dedicated, cross-functional, self-managed teams to build increments of product, and facilitates the emergence of product based on empirical learning. There are 3 roles in Scrum: a product owner who is responsible for the success of the product, a delivery team that is charged with creating a potentially shippable product increment every 30 days and a Scrum Master who facilitates communication between the product owner and the team, owns the Scrum process, and removes obstacles in the way of development.

Scrum was created by Jeff Sutherland and Ken Schwaber, based on a paper written by Hirotaka Takeuchi and Ikujiro Nonaka titled ‘The New New Product Development Game’. Scrum is often referred to as a “project management wrapper” or framework, because it does not prescribe any specific technical practices. It is often used in conjunction with other processes such as XP.

Unified Process (UP)

This is a simpler and more agile adaption of the artifact-heavy Rational Unified Process. It is summarized by Scott Ambler as being “serial in the large, iterative in the small, and delivering incremental releases over time.” There are four major phases divided into one or more iterations: inception, elaboration, construction, and transition. Techniques such as test-driven development and agile model-driven development are part of the AUP (Agile Unified Process) process. AUP is risk driven, and contains many optional artifacts that teams may or may not choose to use.

Crystal Methods

Crystal methods are a collection of agile methods that can be trailed based on project complexity and team size. The focus is on people rather than process, and the priorities of all the crystal methods are safety, frequent delivery, reflective improvement, and close communication. Like individual facets on a crystal, the dimensions of projects- techniques, roles, tools and standards- sit atop as core principles and values. A color scheme helps teams to determine the minimum set of standards to employ: Maroon is for very heavy projects in terms of the number of people, the criticality, and the project-level priorities. Then in descending order there is Red, Orange, Yellow, and finally Clear, for the lightest approach. The intent is to be ‘barely sufficient’ in the amount of process imposed on the team. Crystal enables teams to use the color grid to define the basic process or starting point and customize the process as they go. If a process helps people work together, then the team should keep it- and if it isn’t helping, they should discard it.

Lean Software Development (LD)

Lean Software Development was adopted from lean manufacturing, the Toyota Production System, and Bob Charette’s Lean Development. It focuses on seven principles: eliminating waste,

(8)

amplifying learning, deciding as late as possible, delivering as fast as possible, empowering the team, building integrity in, and seeing the whole. A set of tools - set based design, value stream mapping, and queuing theory are some of examples - are provided to help teams adhere to the principles and achieve their goals. Lean is a management approach for streamlining the process of providing value to the customer. It goes beyond the tactical software development team, yet complements its existing practices. Lean principles and tools are well-suited for strategic execution at the enterprise level.

Adaptive Software Development (ASD)

Developed by Jim Highsmith and Sam Bayer, Adaptive Software Development (ASD) is adapted from Rapid Application Development (RAD) practices and Complex Adaptive System theory. The focus of ASD is continuous adaption to change as a result of learning. The typical static plan-design-build lifecycle is replaced by ASD’s dynamic Speculate-Collaborate-Learn approach, which is intentionally “messy, nonlinear, and overlapping.” ASD is mission focused, feature based, iterative, time boxed, risk driven, and change tolerant.

Dynamic System Development Method (DSDM)

DSDM, or Dynamic System Development Method is an iterative and incremental methodology popular in Europe. It combines a project management lifecycle and a product development lifecycle into one process. It is composed of three phases: pre-project, project lifecycle, and post-project phase. The post-project lifecycle phase is broken down into five parts: feasibility, foundations, exploration, engineering, and development. A bit more prescriptive than some other agile frameworks in defining project artifacts and specific roles and responsibilities, DSDM remains responsive to changing requirements. Its nine principles are closely aligned with those in the Agile Manifesto. DSDM V4.2 now advocates the use of XP in conjunction with its process.

Feature Driven Development (FDD)

Feature Driven Development, or FDD is a marriage between Jeff De Luca’s lightweight development approach and Peter Coad’s feature-oriented object modeling. FDD’s focus is the domain model, the creation of which is the foundational step in the FDD process. The five activities to be followed in FDD are: develop an overall model, build a list of features, plan by feature, design by feature, and build by feature. Sets of features are worked through to completion in two-week iterations. The features to be built are small aspects of client-valued functionality that can be expressed in the form <action> <result> <object>. Like in DSDM, there are multiple specific roles and responsibilities in a project, all clearly defined. Unlike XP, FDD prefers individual code ownership and seeks to avoid refactoring by focusing on domain modeling. FDD is also scalable and works with multiple teams or large teams.

Common Threads & Goals

All the above methodologies explicitly or implicitly support the following common ideas: • Iterative development, develop applications in iteration of 1 – 4 weeks

(9)

• Goal to have an available release (without bugs) at the end of each iteration (may not actually warrant release)

• Get early feedback from users and re-evaluate at end of each iteration • Emphasis on communication

• Working software as primary measure of progress

Agile Practices

One of the fundamentals ideas of agile is that there is no process that fits every project as such, but rather practices should be tailored to suit the needs of individual projects. The question is how far the individual practices and principles can be implemented and also at what level? Any resistance to agile practices and principles on behalf of project members as an individual and/or as team, management or customer may be enough to fail the process. There are many published papers on various aspects of these practices, but probably due to it being seen more as a practical rather than an academic method, the following categorization of practices has been done at various levels:

Agile Practices

Agile Development Process Model

Overview

With the experiences gathered through agile projects, Geometric has developed and refined a repeatable way to enable the efficient and successful delivery of enterprise-scale agile projects. In essence, defining an agile method that works. This approach includes the concepts applied, the tools used and the activities conducted for successfully delivering all business applications. By leveraging the Agile Platform and Agile Network, Geometric is able to adopt agile development methods and scale its agile projects across the organization.

(10)

At Geometric, we believe that being agile requires not only a set of adaptive processes but also tools that make everyone involved with the project. This includes the complete agile delivery team -management, development team members, business users and all key stakeholders. In this section, we will discuss Geometric’s agile process based on the common elements of the popular agile methods and the cornerstone practice of iterative development. We will review the primary activities in the process including project initiation, iteration planning and execution, small releases, and the production release underlying activity of tuning and maintenance support.

Agile Development Process Model

Project Initiation

The project charter is a formal document used to justify, explain, define, and ultimately authorize a project. There are two ways to develop a project charter in an agile environment. One it to continue along the traditional route of preparing the paperwork needed in order to obtain approval, as this then translates into funding and charge codes and formation of team. The other way presumes that either provisional funding has been awarded or that tacit approval has already occurred without the need of detailed paperwork. For these teams, conducting a 4-to-8 hour vision meeting will result in the deliverables associated with the preparation of a project charter.

(11)

Vision Box

In agile software development, with its emphasis on just-in-time design and participatory decision-making, the project planning activities translate into several different envisioning and planning exercises done on an iterative basis, referred as “rolling wave planning” or “multilevel planning”. Rather than defining all the elements of a project plan at the beginning of the project, the agile project manager will instead focus on planning for the visible horizon while staying within the boundaries agreed to in the vision meeting.

The goal of the vision meeting is to define the boundaries and intent of the project by sharing the vision and needs of the business. The team designs the virtual box that would carry the product/ service - the final outcome of project. The front of the box will have the product/ service name and key statement about the product/ service. The back of the box will have some of the key features that can be transferred to sticky notes as the high level features marking the beginning of the product backlog.

While the team and product owners/ stakeholders are discussing the features, the agile project manager facilitates and writes down assumptions, concerns/risks, dependencies, decisions and actions as they come up in conversation. Finally, the Product Roadmap is presented with high level representation of what features are to be delivered in each release, the customer targeted, architecture needed to support features, and the business value the release is expected to meet. In addition to the vision plan and product roadmap, the end result of the product vision and product roadmap discussions is the prioritized product backlog. These are all inputs into the next level of planning - Release Planning.

In release planning meeting, the team reviews the strategies and vision and determines how to map the work from the prioritized backlog into the iterations that make up a release or that make up the period of time such as a quarter. Once the project is underway, updates to the release plan are made at the end of each iteration based on the actual progress and the remaining work for the release. Agile team uses abstract measurements to estimate product backlog items, like story points, which follows Fibonacci sequence: 1,2,3,5,8,13,21… or Exponential scale: 1,2,4,8,16,32… It is common for features in the product backlog to be written as “user stories”, which is a format for writing requirements from a user’s perspective. These user stories are then estimated in a unit of measurement called “story points”. A sense of how many story points a team can complete in one iteration lends the ability to forecast the number of iterations a set of features will take to implement. This set of features called the “release backlog” can be used as a baseline by which project progress is measured.

Teams schedule Iteration 0 (zero) at the beginning of the project and Iteration H (hardening) as the last iteration in a release cycle. Iteration 0 is used for project approvals, environment setup, ramp-up, investigation and initial overviews and design discussions. Iteration H is used at the end to prepare for delivery and it includes activities such as finalizing training and marketing materials and preparing the golden master or installation/ download files. Managing a number of iterations in a release plan is dependent on the new discoveries made about the system. Any

(12)

changes that need to be made can be done by adding an item to the product backlog. The product and release backlogs therefore function as natural change management system. To make comfortable room for the requirements changes that come from collaborating with the customers about the emerging product, top-down estimation model is followed. The top-down approach allows teams to estimate to time horizon by using a just-in-time elaboration of details. Estimating top-down and relative to the horizon lowers the upfront planning costs as well as the cost of change later in the project.

In agile, some work must be authorized prior to project kick-off so that team can at least engage in release planning. The resulting release plan will then establish the cost baseline and subsequent budget. This number will be revisited every iteration and recalculated based on the changes to the release plan. With this information visible to the customer, the customer can then negotiate scope, authorize an increase in budget, or change the project’s release date in response to what is happening.

Resourcing: The Roadmap and release planning meetings help identify resource needs early, so that by the time first iteration arrives teams are ready to create slices of functionality. Additionally resource manger can work with teams to understand their resource bottlenecks and institute measures to help relieve the constraints. These efforts include working with training organization to help cross-train roles within teams and aligning with their individual career development plans.

Agile team size generally ranges from five to ten team members. Pulling together a cross-functional team means selecting not only developers, but also testers, analyst, architects - all people who are needed to implement the features of the product. Preferably, the agile team is co-located. However, many project managers find themselves having to work with dispersed teams instead and therefore pay close attention to tools and techniques that help the team effectively communicate. Some examples of tools used to facilitate this communication include web conferencing, video-conferencing, instant messaging, online dashboards/ whiteboards from enterprise project management tool.

Iteration Planning and Execution (Process)

Iteration Planning Meeting

Iteration planning and release planning follow similar agenda, but the outputs of each are different. Whereas a release plan is high level strategic plan for collection of iterations, an iteration plan is detailed task list that serves as a tactical guide to help accomplish the iteration’s goal. Both release and iteration plans are created by the team in negotiation and collaboration with the customer in the respective planning meetings.

The team is responsible for managing its work within the confines of the iteration. Keeping the agile practice of just-in-time design, it is in iteration planning meeting where the details of the features are discussed and negotiated. It is often discovered during this meeting that the sum of

(13)

the task efforts exceeds the size of the iteration time-box. When this occurs, some of the work is shifted back to backlog and take up in next iteration. Similarly, if a team discovers that it has chosen too little work for the iteration, it will consult with the customer, who can then give the team an additional feature or two to make up the difference. This allows the team to make a realistic commitment to the scope of the work being defined.

Iteration phases and its relation with product backlog & release plan

The above process flow illustrates how a release plan guides delivery over the course of iterations. It also maps the planning and review processes along with outputs of each iteration. Daily Scrum

The lowest level of the agile fractal is daily work, represented as tasks in the iteration plan that is completed by team members. It is a daily standup meeting where all team members attend and report their plan for the day based on the progress that they have made. Standing helps to keep the meeting short and focused. Stand-ups run for at max up to 15 minutes. The primary purpose is for the team to inspect and adapt its work plan (iteration backlog) by quickly sharing information about the progress being made by each individual against the tasks that were committed to during iteration planning meeting.

(14)

Iteration Review

The iteration review provides a designated time and space for collaborative decision-making about the product, as well as an opportunity to review the metrics and overall progress of the iteration. This review acts as a magnifying glass into the current state of the product. The product is tested to meet the criteria set forth to meet the agile value of “working software”. The team provides a walkthrough of the work it completed for the iteration, as well as a review of the work it did not complete during the iteration. Additionally, team will review their iteration metrics, such as test coverage, burndown charts and velocity. This all paints a very clear picture of project status for all the stakeholders and attendees of the review meeting. This review also provides team an opportunity to collect and share feedback and recommend changes both in the process and in the product.

Iteration Retrospective

The iteration retrospective follows the review and is the final closing process for iteration. In this meeting, the team identifies what worked well in the iteration, what did not work well, which item it can control, and what actions it would like to take to improve the process. Other retrospective activities may include conducting root cause analysis, defining team working agreements, recording decisions and identifying actions items. The actions that the team can directly control go on its next iteration backlog, else go into the impediment list.

Small Releases

The culmination of the release cycle is to release a new version of the application to customers. Developing with an agile and iterative development process opens the door to the possibility of smaller and more frequent releases. Two primary benefits of this change are increased responsiveness and reduced risk. Responsiveness increases because newly discovered customer needs can be addressed in a much shorter timeframe. Risk is reduced because customers have the ability to provide feedback as to whether the product is on track earlier in the development process.

Production Release

During production release, the application is published to production. Depending on the nature of the application, the production release might be targeted to a limited set of users and be running in parallel with any replacement systems. As soon as the application is in production, the delivery team begins tuning the application. This stage is a mandatory part of our agile approach and is critical in preparation for full application rollout and end-user adoption.

Tuning

The tuning stage is a key part of the Geometric’s agile approach. It is based on our accumulated experience across successful projects. During this ‘special’ iteration, two key activities are conducted – application performance and functional tuning. During functional tuning,

(15)

outstanding issues are resolved and any remaining low-priority project backlog items are assessed for delivery. These items are assessed to determine if they can be considered as ‘adoption boosting’ functionality. Adoption boosting features increases the probability of the users liking and immediately using the new application. From the delivery team’s perspective, this stage is very intense. There will typically be multiple production deployments each day using the newly published features as the team conducts functional tuning. The intent of multiple deployments is to resolve any outstanding issues and to implement as many ‘adoption boosting’ features as possible, while continuously collecting feedback from the users.

Maintenance

The objective of the maintenance stage is to ensure that the application continuously supports the business through evolutionary maintenance. This means that as the business changes, so should the application. Therefore, this stage consists of a series of 1 to 2 week iterations depending on the changes or new features identified in an ongoing basis. These iterations continue to follow all the primary activities in a regular iteration and leverage all the necessary tools required to keep the delivery team agile. At Geometric, we believe that the promise of agile cannot be fully realized without enabling technology that shortens delivery cycles, increases software development agility, project predictability, responsiveness to business change and overall development team productivity.

Highly Visible Information Radiators

We have identified specific points in the project where communications are most efficient and effective. However open communication throughout the project in agile environments demands more than just point communication. Real-time communication occurs throughout the project via the use of what is called “highly visible information radiators”. These concepts was derived from Lean Manufacturing’s use of a signaling system called “kanban” which provides a way for production lines to observe and respond to demand levels. The word literally means “signal” or “sign”. In Geometric, through one of the horizontal initiative of ‘Whiteboards’, kanbans are represented by graphs, tables, burncharts, task boards that show the current status of the project. As the team starts the work on iteration, team members update the status using the task board where the stakeholders can see how the project is processing at any point of time.

Common Project Management Challenges in Applying Agile

We have looked at ways an agile team incorporates some traditional practices at the beginning, end, and throughout a project. But there are non-project-specific instances as well, where agile project managers are focusing their energies on communication and coordination in order to overcome the hurdles or challenges in their path. A few common challenges identified with management and organization, people, process and technology issues in adopting agile are:

(16)

• Organizational form • Reward systems

• Customer relationships-commitment, knowledge, proximity, trust, respect.

Management and Organizational

• Organizational culture • Management style

People

• Working effectively in a team • High level of competence

Process

• Change from process-centric to a feature-driven, people-centric approach • Short, iterative, test-driven development that emphasizes adaptability • Managing large, scalable projects

• Selecting an appropriate agile method

Technology (Tools and Techniques)

• Appropriateness of existing technology and tools

• New skill sets-refactoring, configuration management, JUnits

Management and organizational issues

Organizational culture has a significant impact on the social structure, which in turn influences the behavior and actions of people. The values, norms, and assumptions of an organization are stabilized and reinforced over time, and are reflected in the policies embodied in organizational routines. Culture exerts considerable influence on decision making processes, problem-solving strategies, innovative practices, information filtering, social negotiations, relationships, and planning and control mechanisms. Neither culture nor mind-sets of people can be easily changed, which makes the move to agile methodologies all the more formidable for the organization. As mentioned, agile methodologies require a shift from command-and-control management to leadership-and-collaboration. The organizational form that facilitates this shift needs the right blend of autonomy and cooperation to achieve the advantages of synergy while providing flexibility and responsiveness.

The project manager’s traditional role of planner and controller must be altered to that of a facilitator who directs and coordinates the collaborative efforts of those involved in development, thus ensuring that the creative ideas of all participants are reflected in the final decision. The biggest challenge here is to get the project manager to relinquish the authority he/she previously enjoyed.

Agile development relies on teamwork, as opposed to individual role assignment that characterizes traditional development. Performance measurement and reward systems, therefore, must be suitably designed for successful adoption of agile methodologies.

(17)

People-related issues

A cooperative social process characterized by communication and collaboration between a community of members who value and trust each other is critical for the success of agile methodologies. For programmers accustomed to solitary activities or working with relatively homogeneous groups of analysts and designers, the ideas of shared learning, reflection workshops, pair programming, and collaborative decision making may be overwhelming.

At the present time, there is little evidence to suggest that agile principles will work in the absence of competent and above-average people. This can pose serious problems related to staffing and morale.

First, it will be difficult to find enough personnel to staff software development teams that use agile methodologies. Second, it will create a culture of elitism within the systems development group that may affect the morale of non-agile developers. In an agile environment, the development team comprising software developers and the customer makes most of the decisions. This creates a pluralist decision-making environment due to the diverse backgrounds, attitudes, goals, and cognitive dispositions of the team members. Decision making in this environment is more difficult compared to the traditional approach where the project manager is responsible for most decisions. It may take an organization enormous effort, time, and patience to build a culture of trust and respect among its employees to facilitate such collaborative decision making. The success of agile development hinges on finding customers who will actively participate in the development process. Further, the customers are expected to be “Collaborative, Representative, Authorized, Committed, and Knowledgeable”. It is not an easy task to find such persons, especially for complex systems.

Process-related issues

The problem of changing attitudes and practices from process-centric to people- centric is acute. Organizations that have for years attempted to achieve higher levels of CMM are particularly susceptible to this problem. The idea of changing a process to fit the capabilities and competencies of people and the characteristics of the project, rather than using a rigid process encompassing standardized activities may be sound, but can be achieved only through significant investment of time, effort, and capital.

Traditional processes are compliance-driven and activities and measurement based, aimed at providing assurance. Agile methodologies rely on speculation, or planning with the understanding that everything is uncertain, to guide the rapid development of flexible and adaptive systems of high value. They stress the importance of assessing as opposed to measuring, and are highly tolerant of change. One of the biggest barriers to migration is the change in a process model from a life cycle model to one that supports feature based development using evolutionary and iterative development. Such a change entails major alterations to work procedures, tools and techniques, communication channels, problem solving strategies, and roles of people.

(18)

While all agile methods, to some extent, conform to the tenets outlined in the agile manifesto, they are not all alike in every respect. They differ in terms of team size, code ownership, duration of each iterative cycle, emphasis on upstream and downstream activities, and the mechanisms for rapid feedback and change. In the absence of a unified agile approach, organizations must decide which is most compatible with their existing practices.

Conclusion

The intensely competitive nature of the software product marketplace continues to put more pressure on today’s product development teams. Moreover, as the market matures, the scope and sophistication of the applications that must be deployed to address user needs is growing dramatically. Team size is increasing while development times decrease. Agile software development methods address these challenges by providing teams with a way to deliver smaller increments of functionality to the customer more quickly than before. In turn, this accomplishes three business objectives:

1. Faster time-to-market and subsequent larger market share

2. Better fit of software features to customer's true needs for increased product preference 3. Adapt to changing business conditions faster than rivals

At the core of all these agile methods is iterative and incremental development, a technique that provides objective feedback on a real time basis. With iterations, teams have visibility into the product under development, and they have more time to adapt and adjust to changing customer needs.

Adopting these new practices fundamentally changes the way teams plan, run and manage software projects. Moreover, scaling these agile methods to increasingly demanding applications requires adaptive requirements, test and project management practices as well as appropriate tools to support larger and more distributed teams.

Establishing these practices gives teams a true competitive edge, an edge that allows them to better meet both their personal and business objectives. These are the teams that will be the most competitive in the future, and these teams will continue to deliver early and deliver often.

(19)

References

• Agile Manifesto - www.agilemanifesto.org

• Principles Behind the Agile Manifesto - www.agilemanifesto.org/principles.html

• Boehm, B. and Turner, R. Balancing Agility and Discipline: A Guide for the Perplexed. Addison-Wesley, Boston, MA, 2004.

• Cockburn, A. Agile Software Development. Addison-Wesley, Boston, MA, 2002.

• Highsmith, J. Agile Software Development Ecosystems. Addison-Wesley, Boston, MA, 2002. • Ken Schwaber, Agile Project Management with Scrum, Microsoft Press, ISBN 073561993X • Ken Schwaber, The Enterprise and Scrum, Microsoft Press, ISBN 073561993X

• MacCormack, A. Product-development practices that work: How Internet companies build software. MIT Sloan Management Review (Winter 2001), 75–84

• M. C. Paulk, "Agile Methodologies and Process Discipline," CrossTalk, 2002. • M. Cohn, Agile Estimation and Planning: Addison-Wesley, Boston, MA 2005

• M. Cohn, User Stories Applied : For Agile Software Development: Addison-Wesley, Boston, MA 2004

• Poppendieck, M. and Poppendieck, T. (2006). Implementing Lean Software Development: From Concept to Cash. Addison-Wesley, Boston, MA

• Takeuchi, H. and Nonaka, I. (1986). The New New Product Development Game. Harvard Business Review Jan./Feb.: 137-146.

• The Software Project Manager's Bridge to Agility: By Michele Sliger, Stacia Broderick

About the Author

Shailesh Kalmegh is a certified Project Management Professional (PMP) from PMI, USA and a certified Scrum Master (CSM) from SrcumAlliance. As a Project Manager at Geometric, Shailesh facilitates software development teams to adopt and succeed with the agile development model. Shailesh has managed offshore and onshore projects as a Project Manager and as a Technical Expert. He has over 11 years of experience in projects/ programs across Aerospace and Automotive domain.

He is BE (Mechanical), Post Graduate Diploma in Advanced Computing and specializes in PLM/ CAD applications.

(20)

About Geometric

Geometric is a specialist in the domain of engineering solutions, services and technologies. Its portfolio of Global Engineering services and Digital Technology solutions for Product Lifecycle Management (PLM) enables companies to formulate, implement, and execute global engineering and manufacturing strategies aimed at achieving greater efficiencies in the product realization lifecycle.

Headquartered in Mumbai, India, Geometric was incorporated in 1994 and is listed on the Bombay and National Stock Exchanges. The company recorded consolidated revenues of Rupees 8.08 billion (US Dollars 167.51 million) for the year ended March 2012. It employs over 4500 people across 12 global delivery locations in the US, France, Romania, India, and China. Geometric was assessed as CMMI 1.1 Level 5 for its software services and is ISO 9001:2008 certified for engineering operations. The company’s operations are also ISO 27001:2005 certified.