Extending Agile to Suite Big Projects

  • 2,951 views
Uploaded on

 

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,951
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Extending Agile to Suite Big Projects 1 Extending Agile to Suite Big Projects Muhammad Amin Bandeali, MSE Student California State University, Fullerton Amin.Bandeali@csu.fullerton.edu Abstract – It has been said that Agile methods only work for small, collocated, self-directed teams that include on-site customers and trusted relationship among team members. But what if the team is distributed around the world or the developers lack self-directed team skills? This article presents a case for using key Agile practices in a broader range of projects, which includes large physically distributed projects keeping in mind safety, reliability and criticality. I.Introduction “It [is] predicted that a decade would not see any programming technique that would by itself bring an order-of-magnitude improvement in software productivity.” - (Brooks, 1995, p.vii) Brooks’ bold and provocative “No Silver Bullet” statement was made in 1986. Even after two decades his prediction stays and is widely accepted as the truth. It is also believed that the next decade wouldn’t bring any change and his statement will stand the time. Agile methodologies were being developed around the era this statement was made, perhaps even earlier. The ‘Agile’ name came about when the Agile Manifesto was signed in February 2001. It was signed after highly regarded individuals from the software development industry came together to form what is now termed ‘the Agile Movement.’ (Highsmith, 2002, p.xvii). These proponents of the Agile methodologies all believed that the traditional methodologies of heavy documentation and rigorous processes are in many cases no longer appropriate. Today’s unpredictable environment requires rapidly changing software which can adapt and evolute with the ever emerging requirements. Many organizations are looking seriously at Agile methods to see if there are benefits to be gained across a broader range of projects. The fundamental problem that these organizations have with adopting Agile methodology is the myth that Agile cannot be used with large scale projects, but as we would see later in this article that with some extensions to the well-known Agile methodology, it can be applied to large scale projects. These organizations currently use the more traditional “heavy-weight” type methodologies sometimes known as non-Agile methodologies. II.Non-Agile Methodologies The serial, or waterfall, development lifecycle are very widely used throughout the industry and have been under attack for years. Donald Reinertsen said, “The vast majority of academic literature on product development is skewed towards the sequential approach. This is in striking contrast to the enormous shift that has taken place in managerial practice towards a more concurrent approach.” Serial development cycle’s supporters believe that time spent early on in software production can lead to greater economy later on in the software lifecycle. A bug found in the early stages of the
  • 2. Extending Agile to Suite Big Projects 2 production lifecycle – specification or design is cheaper to fix in terms of money, effort and time than later on in the process. McConnell estimates that quot;a requirements defect that is left undetected until construction or maintenance will cost 50 to 200 times as much to fix as it would have cost to fix at requirements time.quot; However, the defense industry abandoned the waterfall methodology for iterative methods after experiencing high failure rates. Critics of Agile methods are from the above community and they believe that Agile is an ad-hoc, undisciplined, and technically mediocre style of development. The reality is that Agile methods have less-elaborate process structures compared to the serial or iterative methodologies, but they tend to “follow” the ones they have; unlike projects that thrive on process, procedure and documentation, but have high failure rates – since those processes, procedures, forms and documents are systematically ignored. III.Iterative Methodology If you want to innovate, you have to iterate! That is what the proponents of Iterative Methodologies believe in. Their main argument is that Estimates of budgets, schedules, etc. become more realistic as work progresses, because important issues are discovered earlier. It is important because iteration helps in coping with the changes that software development generally entails and software engineers can get their hands dirty by start working on a project earlier. Agile methodology is also built on iterative concepts as discussed in the next section. IV.Agile Methodology What does a business executive want from a product development and project management process – reliability, predictability and dependability. So that good business decisions could be taken earlier than later. That is what Agile methodology is set to achieve. Agile development is reshaping the way coders and entrepreneurs create software products based on Web-based services. Agile teams work very efficiently. They create small chunks of functional code, sometimes in as little as a week and once a component is finished, additional features are added, with the process repeating indefinitely. Agile employs different strategies to achieve its goal. Few of those well known methods are Scrum, XP and Lean. Scrum focuses on one month sprints. XP advises shorter iterations (2 week, typical). Lean focuses on a single piece (one feature, in the case of design projects), delivered in the shortest possible time. This methodology has built a reputation for enabling managers to deliver products on time and under budget, which helps explain why it has become a methodology of choice at companies like Google and Lockheed Martin. This mindset has started as a revolt against over-exercised, Dilbert-style software development projects. CNN has compiled a list of the 50 people, products, trends, and ideas that are transforming the world of business. Agile Software Development ranks #18. V.How to apply Agile on large and distributed projects Software Life cycles are full of trade-offs. Software is complex as people are complex and the only thing that is certain in projects is change. This lethal combination of unpredictability is more often helped by Agile principles. But there are implications. In exchange to working and
  • 3. Extending Agile to Suite Big Projects 3 functional products, you do get less predictability. Some people believe that Agile development is right for every project, while others argue that Agile is a hoax. But the reality is somewhere in between. Most approaches could be applied to any project but the best way to methodology is the way you know. But the key question is – how do you know if out-of-the-box Agile suits a project? DSDM (Dynamic Systems Development Method) is one of the initial development methodologies based on the Agile philosophies. The DSDM methodology includes a project suitability filter. This filter is a simple questionnaire that tries to highlight the key characteristics of a project that is well suited to DSDM, or more generally to an Agile approach. Here are some of the questions that matter most: • Does the sponsor/senior management understand and accept the iterative philosophy? • Can the organization accommodate the frequent delivery of increments? • Will it be possible for the developers to have access to users (user representatives) throughout the project? • Will the development team remain the same throughout the project? • Will the project use technologies suitable for prototyping? • Will the development be computationally non-complex? • Can the requirements be prioritized? Will users be able to define requirements interactively? “Yes” to the above questions means that the out-of-the-box Agile approach would work great for the project. However a few of “No”s do not eliminate the Agile approach entirely. Through a small amount of risk mitigation, and extensions, the Agile approach could be used. VI.Agile on large and distributed projects If you attempt Agile methods out of the box on large and distributed projects, you are likely to miss the key benefits of Agile. This is because these methods require extensions to work on more complex projects. Using a combination of the following extensions, Agile architecture could be used with large scale, complex projects: A.Agile Architecture Agile architecture involves first setting up an Agile architecture team. The goal of the Agile architecture is to address the complete project scope and provide a minimum set of architecture compliance rules. First a small strategically selected team rapidly develops a high-level Agile architecture and documents the results. The resultant product of the first level is a thin architecture document that includes a simple, high-level diagram showing the major system components. After this practice, the Agile architecture team focuses on the high-risk areas for each iteration. When the architecture grows over time as the solutions accumulate, these documents are updated in a timely manner. This is crucial to Agile architecture scalability. B.Super Leads A super lead oversees between three and five Agile teams working on a large scale project; however he/she is not the Agile team lead. Super leads could also attend daily stand-up meetings
  • 4. Extending Agile to Suite Big Projects 4 but if they do, they do not speak. The super lead's role is to mentor the less experienced Agile team leads with filling the communication gap among them. Super leads also review the team plans and provide feedback. A primary benefit for having an on-site customer is to answer questions quickly so the Agile team does not waste valuable time. A super lead can function as a customer proxy, especially on large and distributed projects. In scenarios where the super lead does not know the answer they might know who to call. C.Light Weight Documentation Since large and distributed teams cannot meet every day, therefore, having light weight documentation can help in many regards. Training the team to be able to document efficiently and lightly the processes that might help their other peers to successfully maintain velocity could increase productivity and count towards successful project delivery. VII.Advantages of adopting Agile on large and distributed projects 1) Edge: Since Agile development is iterative, the most important features with the most priorities are delivered early. This could cause the revenue to start pouring in way before anticipation. Completing a large project using traditional methodologies might take very long to complete. Research also depicts that 80% of all market leaders in any industry had their flagship product first in the market. Agile development is set out to do just that – capture the market before any of your competitors. 2) Quality: With integrated testing, product owners can make adjustment to the system without compromising quality. Agile would help improve quality in large projects by having a constant eye on the most important quality attributes after each release, instead of the one and only final release. With users’ active involvement throughout the product’s development, the visibility increases for key stake holders, which can ensure expectations are met and expectations are adequately managed and ultimately result in higher customer satisfaction. 3) Risk: Through incremental releases, product owners and team can easily identify any potential risks early and mitigate them to ensure that any necessary decisions could be taken at the first possible opportunity. 4) Cost: The above approach of fixed timescales and evolving requirements enables a fixed budget. The scope of the product and its features are variable, rather than the cost. 5) Product: The ability to embrace change makes sure that the right product is delivered versus a successful project to only find that the product is not what was expected, needed or hoped for. Agility is all for the right product especially if it is being developed by geographically diverse teams. VIII.Conclusion The factors that are involved in software development are far too extensive and unpredictable for just one methodology to be the answer in today’s chaotic environment. Employing any of the existing or emerging Agile methods does not exclude the use of another. Nevertheless, Agile is about breaking through to the grassroots level, making real status visible and acted upon sooner, which ultimately provides greater value to the customer. It is also becoming increasingly conspicuous that a large development project can make use of rudiments of more than one
  • 5. Extending Agile to Suite Big Projects 5 methodology. However, the focus is clearly shifting, from processes to practice, from heavy documentation to iterative releases of working software, from price fixing and contract negotiation to collaboration with the customer and from following a plan to adapting quickly to change. And that is the set of underlying philosophies that form the Agile Manifesto. I would like to wrap up this paper with the best of Agile Manifesto (Highsmith, 2002, p.xvii) itself: • Individuals and Interactions over Processes and Tools • Working Software over Comprehensive Documentation • Customer Collaboration over Contract Negotiation • Responding to Change over Following a Plan References [1] Highsmith, J. 2002, Agile software development ecosystems, Addison-Wesley, Boston. [2] McMahon, Paul. E. “Extending Agile Methods: A Distributed Project and Organizational Improvement Perspective.” May 2005. [3] Schwaber, Ken. Agile Project Management with Scrum. Microsoft Press, 2004. [4] Lynos, Kevan. “The Agile Approach”. [5] Business 2.0 Staff. “The 50 Who Matter Now” CNN. (http://money.cnn.com/galleries/2007/biz2/0706/gallery.50whomatter.biz2/33.html) [6) Waters, Kelly. “Is Agile development right for your project”. [7] Agile Alliance. (http://www.agilealliance.com/) [8) Ambler, Scott “Why Agile Software Development Techniques Work: Improved Feedback”. (http://www.ambysoft.com/essays/whyAgileWorksFeedback.html) [9] WikiPedia. “Agile Software Development”. [10] Fowler, Martin. “Is Design Dead?” Appeared in Extreme Programming Explained, G. Succi and M. Marchesi, ed., Addison-Wesley, Boston. 2001. [11) Elssamadisy, Amr. “Agile Team Size” InfoQ. 2007. (http://www.infoq.com/news/2007/07/agile_team_size) [12] Cohn, Mike. “Agile Estimating and Planning”. 2005. [13] Brooks, Frederick. “The Mythical Man-Month: Essays on Software Engineering”. 1995.