Debunking “Bleeding Edge” Methodologies A to Z: Agile – RUP – Scrum – XP

1. Debunking “Bleeding Edge” Methodologies A to Z: Agile – RUP – Scrum – XP David M. Sides, PMP, OPM3, ITIL Vice President, Sogeti Project Consulting Practice www.us.sogeti.com 1

2. Introduction & Caveats • Expectations? • Agile – RUP – Scrum – XP – To use or not? You decide. • My premise and bias: Traditional methods for 20+ years…maybe there is a better way? You tell me. • Change is hard. • True leadership is rare. • There is no “Silver Bullet”. • There are no perfect People, Processes, or Tools. • Corporate cultures are full of “Organizational Inhibitors”. 2

3. And now…Agile Late Show with David Sides

4. Dave’s “Top 10” Stupid Agile Tricks 1. Never look back. What’s done is done. 2. Matrix manage me. 3. Make it really complex so everyone will be impressed. 4. Pay me by the pound. 5. Close your door and send an email. 6. Micro-manage me. 7. Stay in your silos. 8. They’ll get it when we’re done. 9. Stick your head in the sand. 10. We in IT know what’s best for our customer. 4

5. Agile • Manifesto • History • Values • How do you know? • TDD & Refactoring • SDLC • AUP • Change Management • Simple Definition 5

6. The Agile Manifesto 1. Never look back. What’s done is done. [At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.] 2. Matrix manage me. [The best architectures, requirements, and designs emerge from self-organizing teams.] 3. Make it really complex so everyone will be impressed. [Simplicity--the art of maximizing the amount of work not done--is essential.] 4. Pay me by the pound. [Working software is the primary measure of progress.] 5. Close your door. Send an email. [The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.] 6. Micro-manage me. [Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.] 7. Stay in your silos. [Business people and developers must work together daily throughout the project.] 8. They’ll get it when we’re done. [Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.] 9. Stick your head in the sand. [Welcome changing requirements, even late in development. Agile processes harness change for competitive advantage.] 10. We in IT know what’s best for our customer. [Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.] 6

7. History of Agile • In the late 1990’s several methodologies began to get increasing public attention. Each had a different combination of old and new ideas, but all emphasized: • Close collaboration between the programmer team and business experts • Face-to-face communication (as more efficient than written documentation) • Frequent delivery of new deployable business value • Tight, self-organizing teams • Ways to craft the code and the team so the inevitable requirements churn was not a crisis Who?17 independent thinkers, competitors and anarchists from XP, Scrum, DSDM, ASD, et al What? Met to try to find common ground on software development When?February 11-13, 2001 Where? The Lodge at Snowbird, Utah Why? They felt the need for an alternative to “documentation-driven, heavyweight software development processes” How? They skied, ate, drank, and came to terms, naming themselves “The Agile Alliance” Output?The Agile Software Development Manifesto 7

8. Agile Values • Individuals and interactions over processes and tools.  Teams of people build software they need to work together effectively. • Working software over comprehensive documentation.  Provide benefits and value early and often. Don’t get paid by the pound for your documentation; be concise. • Customer collaboration over contract negotiation. Only your customer can tell you what they want.  Yes, they will change their minds and won’t get it right the first time. Communicate, understand their needs, and educate your customers along the way. • Responding to change over following a plan. People change, priorities change, and the business environment changes.  Technology changes over time, although not always for the better.  A Project Plan is good, but stuff happens and there must be room to change it as your situation changes.  8

9. How do you know if you are Agile? Ask yourself these questions… • Is the team taking a test-driven approach to development? With Test-driven Development (TDD) you write a single test before writing just enough code to fulfill that test.  Review the test suite, see it run, and view the actual source code.  Look for a 50-50 split between testing code and production code. A 20-80 split is clearly a problem. • Are stakeholders active participants in development? Minimally stakeholders should be available and involved on a daily basis, provide information and make decisions in a timely manner.  The team should be able to introduce me to their stakeholder(s) immediately. • Is the team regularly producing high-quality, working software? Within a few weeks, the team should be able to show the working software that they've built to date as well as the source code.  The code should be consistent because it will have been written to conform to a common set of guidelines and the team will refactor when appropriate to ensure that it remains of high quality. • Is the team self-organizing and highly collaborative? Agile teams employ the most effective communication strategies available. Detailed specifications may be sparse, but all should know and understand them. Team members should be motivated and self-directed instead of having a project manager do their planning for them. 9

10. Test-driven Design/Development (TDD) Test–driven Design/Development (“test first”): Add a test with just enough code to fail. Run your tests to fail; either a subset, or if time allows, the complete test suite. Update your functional code to make it pass the new tests. Run your tests again.  If they fail, update your functional code and retest. Once the tests pass, start over (you may first need to refactor any duplication out of your design as needed). Refactor – Restructure your code by making small changes to improve your design, making it easier to understand and modify.  Refactoring enables you to evolve your code slowly over time, to take an iterative and incremental approach to programming. 10

11. Agile SDLC 11

12. Agile Unified Process (AUP) 12

13. Agile Change Management Key CM Factors: Embrace change. Accept the idea that requirements will evolve throughout a project. Understand that because requirements evolve over time that any early investment in detailed documentation will be wasted. Do just enough initial requirements envisioning to identify project scope and develop a high-level schedule and estimate. “Model Storm” (JIT modeling) continually during development to explore each requirement in the necessary detail. 13

14. A Simple Agile Definition Agile is an iterative and incremental (evolutionary) approach to software development performed in a highly collaborative manner by self-organizing teams with “just enough process” (JEP) that produces high quality software in a cost effective and timely manner  which meets the changing needs of its stakeholders. 14

15. Agile Quiz • What is it? • History • When to use it? 15

16. The Rational Unified Process 16

17. You Might Be A Texan If... 1. You can properly pronounce Corsicana, Palestine, Waxahachie, Bexar, Mexia, Waco, Beaumont and Amarillo.2. A tornado warning siren is your signal to go out in the yard and look for a funnel.3. You've ever had to switch from "heat" to "A/C" in the same day.4. You measure distance in minutes or hours.5. You know cowpies are not made of beef.6. Someone you know has used a football schedule to plan a wedding date.7. You are 100% Texan if you have ever had this conversation:"You wanna coke?""Yeah.""What kind?""Dr. Pepper." 17

18. The RUP? • RUP is and not? • ABCDEF • History • Why? • Profile • Use Cases • PM 18

19. What is RUP? What is it not? The Rational Unified Process (RUP) is an iterative software development process framework created by the Rational Software Corporation. • The RUP is not a single concrete prescriptive process, but rather an adaptable process framework. • The RUP does not have to be used as-is, all the time, but should be tailored by the development organizations and software project teams that select the elements appropriate for their needs. • The RUPis also a software process product, including a hyperlinked knowledge base with sample artifacts and and detailed descriptions for many different types of activities. • The RUPis included in IBM’s Rational Method Composer (RMC) which allows customization of the process. 19

20. IBM Rational Method Composer (RMC) 7.2 Plug-ins • IBM Rational Method for SOA Governance Plug-in V1.0 • RUP for WebSphere Business Modeler Plug-in V1.0 (beta) • IBM Rational Method for Portfolio Management (for Initiatives) Plug-in V1.0 • RUP for Microsoft .NET Plug-in V3.0 • RUP for COTS Package Delivery Plug-in V2.1.1 • IBM Rational Method for Program Mobilization Plug-in V1.02 • RUP for Practical Software and Systems Measurement (PSM) V3.0 • RUP for Maintenance Projects Plug-in V1.0 • RUP for DoDAF Plug-in V1.0 • RUP for Compliance Management Plug-in V1.0 • The IBM Rational Unified Process for System z V1.0 • The IBM Rational Unified Process with ITSM/ITUP Connection V1.0 • RUP with CMMI Compliance Support V1.0 Beta 2 • RUP for Asset-Based Development V3.0 and Asset-Based Dev. Governance Plug-in V1.0 • The IBM Rational Unified Process for Global Dev. and Delivery Maintenance V1.0 Beta • RUP for Model-Driven Systems Development Plug-in V4.0 20

21. RUP = ABCDEF 6 Key Principles of Business-Driven Development • Adapt the process - A project or organization must “right-size” the process to their needs. RUP provides pre-configured process templates for small, medium, and large projects. • Balance stakeholder priorities - This includes often conflicting business goals and stakeholder needs that compete for time and money. • Collaborate across teams - Software engineering in a globally distributed environment and executed in an iterative-incremental approach is truly a team effort with all stakeholders being heard. • Demonstrate value iteratively – Each delivered increment, which includes the value of the past iteration, is used to measure the progress of the project and to encourage feedback from stakeholders about the direction of the project. Stakeholders influence the shape of the development effort while the project is executed. • Elevate the level of abstraction – This practice motivates the use of reusable assets and prevents software engineers going directly from requirements to custom code. • Focus continuously on quality - Quality checks are an ongoing activity, often performed daily, supported by the entire team. Automating test scenarios (scripts) helps in dealing with the increasing amount of tests due to iterative development. 21

22. History of RUP • The roots of Rational Process go back to the original spiral model (combination of prototyping and waterfall models) of Barry Boehm. • The Rational Approach was developed at Rational Software in in the 1980s and 1990s. • The RUP was the result of the merger of the Rational Approach and the Objectory process (Ivar Jacobson) following Rational’s 1995 acquisition of the Swedish Company Objectory AB. • The first version of the RUP (v5.0) was released in 1998 (chief architect Philippe Kruchten). • The latest version of the RUP (v7.0) was released with the announcement of the IBM Rational Method Composer (RMC) in November 2005. 22

23. Why a RUP? Problem: The developers of the RUP focused on diagnosing and analyzing the root causes of failed software projects. They also looked at existing software engineering processes for solutions to these symptoms. Findings: • Ad hoc requirements management • Ambiguous and imprecise communication • Brittle architecture (architecture that does not work well under "stress") • Overwhelming complexity • Undetected inconsistencies in requirements, designs, and implementations • Insufficient testing • Subjective assessment of project status • Failure to attack risks • Uncontrolled change propagation • Insufficient automation Conclusion: Project failure is caused by a combination of several symptoms, though each project fails in a unique way. The outcome of this study was a system of software best practices they named the Rational Unified Process. 23

24. RUP Project Profile Performed in iterations – Elaboration-Construction-Transition 24

25. Rational Unified Process Look familiar? 25

26. Defining What When • RUP • Prioritize use cases • By stakeholder priority • And by architectural coverage 26

27. Components of a Use Case Diagram Actor:Someone/something outside the system that interacts with the system Use Case:Defines a piece of functionality of the system Communication – Association:Shows the Actor and the Use Case communicate Use Case Specification:Basic flow of events,alternate flows, error flows and sub-flows as appropriate 27

28. Architecture • What is architecture? • High-level components and their connections • How key elements will work together to support the system • Sweeping mechanisms that impact much of the system • Common patterns applied within the design • Design can be “as-is” • Architecture always implied “to-be” • An architecture-centric process • Attacks risk with an early emphasis on architecture • Architecturally-significant requirements elicited earlier • Early builds exercise architecture 28

29. What about Project Management? • Project planning in the RUP occurs at two levels. There is a high-level Phase Plan (software development plan) which describes the entire project, and a series of detailed Iteration Plans which describe the iterations. • The RUP PM discipline focuses mainly on the following aspects of an iterative development process: • Risk management • Planning an iterative project, through the lifecycle and for a particular iteration • Monitoring progress of an iterative project, metrics for quality and performance • However, this discipline of the RUP does not attempt to cover all aspects of project management. For example, it does not cover: • Managing resources: hiring, training, coaching • Managing cost/budget: defining, allocating • Managing procurement: contracts with suppliers, vendors, and customers PM gaps to be filled: Integration, Scope (Change Mgt), Cost, Resource Team Building, Communications, Procurement 29

30. The RUP Quiz • What is it? • History • When to use it? 30

31. Scrum 31

32. Scrum • What is it? • History • Process • Scrum compared to a Pressure Cooker 32

33. What is Scrum? Scrum is an iterative, incremental process for developing any product or managing any work. It has been used from simple projects to complex software. It produces a potentially shippable set of functionality at the end of every iteration. Scrum attributes: • An agile process to manage and control development work. • A wrapper for existing engineering practices. • A team-based approach to iteratively and incrementally develop systems and products when requirements are rapidly changing. • A process that controls the chaos of conflicting interests and needs. • A way to improve communications and maximize co-operation. • A way to detect and cause the removal of anything that gets in the way of developing and delivering products. • A way to maximize productivity. • Scalable from single projects to entire organizations. Scrum has controlled and organized development and implementation for multiple interrelated products and projects with over a thousand developers and implementers. 33

34. History of Scrum • The approach was first described by Takeuchi and Nonaka in "The New New Product Development Game" (Harvard Business Review, Jan-Feb 1986). • They noted that projects using small, cross-functional teams historically produce the best results, and likened these high-performing teams to the scrum formation in Rugby. • In 1990’s Ken Schwaber, Jeff Sutherland, John Scumuniotales, and Jeff McKenna used the approach and called it Scrum. • Although Scrum was intended to be for management of software development projects, it can be used in running maintenance teams, or as a program management approach: Scrum of Scrums. 34

35. Scrum Process Flow Scrum focuses an entire organization on building successful products. Without major changes - often within thirty days - teams are building useful, demonstrable product functionality. Scrum can be implemented at the beginning, in the middle, or anytime in a product development effort that is in trouble. A Scrumproject is controlled by establishing, measuring and trackng key controls (backlog and risk). Controls are critical when a software development has uncertainty, unpredictability, and chaos. Backlog should start relatively high, get higher during planning, and then get whittled away as the project proceeds - either by being solved or removed, until the software is completed. Risk rises with the identification of backlog, issues, and problems, and falls to acceptable levels as the software is changed. 35

36. Scrum Development as a Pressure Cooker • The Planning and System Architecture phases prepare the input that is placed in the pressure cooker. The input consists of: • Ingredients – backlog, objects, packets, problems, issues • Recipe – system architecture, design, and prototypes • Cooking sequence – infrastructure, top priority functions, next priority • The Closure phase removes the final product (executable and documentation) and prepares it for shipment. • The Consolidation Phase cleans up the pressure cooker and ingredients for the next batch. 36

37. Scrum Quiz • What is it? • History • When to use it? 37

38. Extreme Programming 38

39. Extreme Programming • What is it? • Best Practices • History • Take it to the Extreme 39

40. Extreme Programming (XP) • A deliberate and disciplined approach to software development that stresses customer satisfaction by delivering software your customer needs when it is needed. • Empowers developers to confidently respond to changing customer requirements, even late in the life cycle. • Emphasizes team work. Managers, customers, and developers are all part of a team dedicated to delivering quality software. • XP improves a software project in four essential ways • Communication – Programmers talk to their customers and team members. • Simplicity – They keep their design simple and clean. • Feedback – Testing and feedback starts on day one. • Courage – They respond to changing requirements and technology often to delver the system as early as possible. • XP essentially takes existing "best practices" to extreme levels. For example, the practice of TDD was used as early as NASA's Project Mercury, in the early 1960s. Refactoring, modularity, bottom-up and incremental design were described by Leo Brodie in his book published in 1984. 40

41. XP Best Practices • Coding • The customer is always available. • Code must be written to agreed standards. • Code the unit test first. • All production code is pair programmed (code in twos at the same computer). • Integrate often but only one pair integrates code at a time (version control). • Use collective code ownership (everyone contributes). • Leave optimization (make it work, make it right, then make it fast) till last. • No overtime (great idea if management and customers agree!). • Testing • All code must have and pass all unit tests before it can be released. • When a bug is found tests are created. • Acceptance tests are run often and the score is published. • Planning • User stories (use cases) are written. • Release planning creates the schedule. • Make frequent small releases. • The Project Velocity (amount of work getting done) is measured. • The project is divided into iterations. • Iteration planning starts each iteration. • Move people around (cross train). • A stand-up meeting starts each day. • Fix XP (improve the process) when it breaks. • Designing • Simplicity. • Choose a system metaphor (naming standards) . • Use CRC cards (Class, Responsibilities, Collaboration) for design sessions. • Create spike solutions (simple programs to explore potential solutions) to reduce risk. • No functionality is added early (focus on today’s needs). • Refactor (let it go; rejuvenate obsolete designs) whenever and wherever possible. 41

42. XP History • XP was created by Kent Beck in 1996 during his work as project leader on the C3 payroll project at Chrysler. • In 1999, Beck wrote a book on the method: Extreme Programming Explained. • Chrysler canceled the C3 project in 2000, and although some see that initial failure as a problem with XP, the method had caught on in the software engineering field. • As of 2007, a number of software-development projects continue to use XP as their method. 42

43. Take it to the Extreme: Make Your Customers Notice… Change the way we program. • Keep it simple. Don’t be slick and clever. Software engineered to be simple and elegant is more valuable than software that is complex and hard to maintain. A typical project will spend about 20x more on people than hardware. • A project spending $2M/yr on programmers will spend about $100k on technology. Say we save 20% of the hardware costs by some very clever programming tricks. The source code will be harder to understand and maintain, but we are saving 20% or $20k/yr. • If instead, we wrote our programs such that they were easy to understand and extend, we could expect to save no less than 10% of our people costs = $200k, significantly more. • Really listen to your customers and act on their feedback. Too often a customer will see a real opportunity for making a system useful after it has been delivered. Use customer feedback while there is still time to change functionality or improve user acceptance. • Co-locate and collaborate to improve communications and velocity. • Buddy-up (pairs) to reduce risk and increase quality. Two heads are better than one. • Write and execute tests early and often. Automate tests so bugs don’t get through twice. • Live with change, embrace change, no…Seek Change! 43

44. Extreme Programming • What is it? • History • When to use it? 44

45. Recap So…is there anything really new under the sun? • Agile • The RUP • Scrum • XP • Waterfall Is Deming still relevant? How do I do it? • People: Education, training, and certification • Process: • Set and manage expectations. • Prepare for change • Technology: Is it about Tools? • Agile – Version One, Serena, Axosoft • RUP – Rational Method Composer, ClearCase • Scrum – ScrumWorks, ScrumZ, Serena, Axosoft • XP – Version One, XPWeb Plan Act Do Check 45

46. Organizational Project Management Enterprise Governance: Leadership, Organizational Structures and Enablers, Policies Project Portfolio Management Strategic Alignment & Selection Approval & Funding Prioritization Weekly Regular Program Management: PMO, Methodology, Standards, Processes, Tools, Stakeholder Management, Performance Metrics & Measurement, Benefits Realization SOW • Project Team • Meetings • Tracking of Progress, Status, Forecast • Risks & Issues • Steering Group • Meetings • Reporting of Progress, Status, Forecast • Risks & Issues Escalation Quality Procurement Time Resources Integration • Knowledge Management • Project Files • Best Practices • Lessons Learned • Responsibility: • Accountability • Approvals • Signoffs Scope Cost Risks & Issues Communications Project Management Initiation – Planning – Execution (Monitor & Control) – Closing Project Governance: Step Gate Reviews, Milestones, Risk & Quality Management Traditional System Life Cycle: Planning – Requirements – Analysis & Design – Development – Implementation – Maintenance Iterative System Life Cycle: Inception – Elaboration – Construction – Transition – Maintenance 46

47. Closing & Caveats • Expectations? Q&A? Bs&Cs? Evaluations? PDUs? • Agile – RUP – Scrum – XP – Waterfall explained? • To use or not? You decide. • My premise and bias: Traditional methods for 20+ years…maybe there is a better way? • Change is hard. • True leadership is rare. • There is no “Silver Bullet”. • There are no perfect People, Processes, or Tools. • Corporate cultures are full of “Organizational Inhibitors”. 47 david.sides@us.sogeti.com

48. Who & Why Sogeti? • 40+ years of global experience – global reach, local touch • Comprehensive service offerings to solve client business & IT challenges • Complemented by our alliance relationships with Microsoft, IBM and others • Leveraging our global delivery capabilities to keep client costs down • Quality delivery always • Industry-leading, knowledgeable, experienced and certified professionals in Project Management and IT development (150+ PMPs) We work with clients to develop and deploy unique solutions to help them achieve their strategic business objectives. David M. Sides, PMP david.sides@us.sogeti.com

49. Global expertise & local proximity 16,000 worldwide 2000 in USA Benelux UK Nordic France United States Central Europe Southern Europe India A multi-national, premier provider of IT and project management services Global reach, local touch

50. Sogeti USA locations Seattle Minneapolis Detroit Chicago Des Moines New York Cleveland Omaha Columbus Baltimore Indianapolis Dayton Ft. Collins Kansas City Washington DC Cincinnati Denver St. Louis Phoenix Dallas Houston Tampa 2000 IT Professionals in 23 locations across the country Ft. Lauderdale