Using Agile Processes on Documentum Projects

5,008 views

Published on

Software Developer's Conference 2005

Published in: Business, Technology
3 Comments
16 Likes
Statistics
Notes
No Downloads
Views
Total views
5,008
On SlideShare
0
From Embeds
0
Number of Embeds
89
Actions
Shares
0
Downloads
0
Comments
3
Likes
16
Embeds 0
No embeds

No notes for slide
  • Using Agile Processes on Documentum Projects

    1. 1. Using Agile Processes on Documentum Projects Michael Trafton Founder & Chief Architect
    2. 2. Blue Fish ECM Practices Content Migrations <ul><li>Focused on retaining the value of intellectual assets </li></ul><ul><li>Attention to migration of regulatory docs in validated environments </li></ul>Web Content Management <ul><li>Focused on empowering business users </li></ul><ul><li>Attention to ease of use and enforcing brand standards </li></ul>Custom ECM Solutions <ul><li>Focused on helping clients gain a competitive advantage </li></ul><ul><li>Attention to supportability and upgradeability </li></ul>
    3. 3. Survey <ul><li>How many people work in a group that claims to have a well-defined software development process? </li></ul><ul><li>How many follow it religiously? </li></ul><ul><li>Is it a waterfall-style process? </li></ul><ul><li>Is it an agile process? </li></ul>
    4. 4. Advent of Agile Processes
    5. 5. State of Software Development <ul><li>31% Canceled </li></ul><ul><li>53% Over Budget, Over Schedule, Fewer Features </li></ul>Failed Projects Successful 84% 16% <ul><li>Delivered with only 42% of original features </li></ul>Source: “The CHAOS Report (1994)”, The Standish Group
    6. 6. What Is Wrong? <ul><li>Software Development is not a predictable process! </li></ul><ul><li>Can run repeatedly with predictable results </li></ul><ul><li>Performs best with little variation in inputs </li></ul>Defined Process <ul><li>Can not be defined so precisely that it can guarantee predictable results </li></ul><ul><li>Empirical Control Model </li></ul><ul><ul><li>Frequent Inspections </li></ul></ul><ul><ul><li>Adaptive Response </li></ul></ul>Complex Process
    7. 7. 1990s - Adaptive Software Development <ul><li>Frustrated software developers started experimenting with adaptive software development processes </li></ul><ul><ul><li>Extreme Programming (XP) </li></ul></ul><ul><ul><li>Scrum </li></ul></ul><ul><ul><li>Crystal </li></ul></ul><ul><ul><li>Feature Driven Development (FDD) </li></ul></ul><ul><ul><li>Adaptive Software Development (ASD) </li></ul></ul><ul><ul><li>Lean Software Development </li></ul></ul><ul><ul><li>Dynamic Systems Development Method (DSDM) </li></ul></ul>
    8. 8. What is an Agile Methodology? <ul><li>“Agile” is an umbrella term for software processes that use iterative development as a process control framework </li></ul><ul><li>Agile methodologies are focused on </li></ul><ul><ul><li>Early and Continuous Delivery of Software </li></ul></ul><ul><ul><li>Iterative Development </li></ul></ul><ul><ul><li>Business User Involvement </li></ul></ul><ul><ul><li>Building Effective Teams </li></ul></ul><ul><ul><li>Welcoming Changing Requirements </li></ul></ul>
    9. 9. Agile Example: Extreme Programming
    10. 10. Cost of Change <ul><li>Based on the premise that changing software is not as expensive as we once thought </li></ul>Cost of Change Time Traditional Assumption XP Assumption
    11. 11. XP’s Big Picture <ul><li>Little or no requirements gathering </li></ul><ul><li>No “Big Design Upfront” </li></ul><ul><li>String together several time-boxed iterations </li></ul><ul><ul><li>Develop most important features first </li></ul></ul><ul><ul><li>Stop when the features’ benefits aren’t worth the cost of an iteration </li></ul></ul>
    12. 12. Anatomy of an XP Iteration High-Discipline Development <ul><ul><li>Customer Selects “Stories” </li></ul></ul><ul><ul><li>Stories broken into tasks and estimated </li></ul></ul>Planning Game <ul><ul><li>Customer Runs Acceptance Tests </li></ul></ul>Iteration Review
    13. 13. High-Discipline Development Practices <ul><li>Pair Programming </li></ul><ul><ul><li>All code is written by two people at one computer </li></ul></ul><ul><li>Refactoring </li></ul><ul><ul><li>Code is constantly refactored as new features are added </li></ul></ul><ul><ul><li>The internal structure of the code is changed without changing its external behavior </li></ul></ul><ul><li>Unit Tests </li></ul><ul><ul><li>All code must be accompanied by programmatic unit tests </li></ul></ul><ul><ul><li>Unit tests are run whenever code is compiled </li></ul></ul>
    14. 14. XP Practices <ul><li>Pair Programming </li></ul><ul><li>Testing </li></ul><ul><li>Refactoring </li></ul><ul><li>Continuous Integration </li></ul><ul><li>Short Releases </li></ul><ul><li>Simple Design </li></ul><ul><li>Collective Ownership </li></ul><ul><li>On-site Customer </li></ul><ul><li>Planning Game </li></ul><ul><li>40 Hour Week </li></ul><ul><li>Metaphor </li></ul><ul><li>Coding Standards </li></ul>
    15. 15. XP Practices
    16. 16. “Extreme” Programming <ul><li>Takes traditional software engineering practices to the “extreme” </li></ul>Continuous Integration Integration Testing Unit Testing Testing Pair Programming Code Reviews XP Implementation Common Sense Practice
    17. 17. Agile Documentum Projects
    18. 18. Enabling Factors <ul><li>Documentum projects are well suited to Agile Methodologies </li></ul>Small Teams Internal Projects Packaged Software
    19. 19. Packaged Software <ul><li>Business users unlikely to understand capabilities </li></ul><ul><ul><li>Leads to changes in requirements as they understand </li></ul></ul><ul><li>Developers likely to be inexperienced </li></ul><ul><ul><li>Leads to poor estimating and prediction </li></ul></ul><ul><li>Expensive Software </li></ul><ul><ul><li>Leads to desire to see ROI early </li></ul></ul><ul><li>Constantly evolving (patches, new versions, etc.) </li></ul><ul><ul><li>Leads to changes being introduced frequently </li></ul></ul><ul><li>Few books/other resources </li></ul><ul><ul><li>Experience is the main way to learn </li></ul></ul>
    20. 20. Internal Projects <ul><li>Trust </li></ul><ul><ul><li>Enables schedule ambiguity </li></ul></ul><ul><li>User Availability </li></ul><ul><ul><li>Close proximity to users </li></ul></ul><ul><li>Resource Inflexibility </li></ul><ul><ul><li>You have to go to war with the army you have </li></ul></ul><ul><li>Multiple Projects/Responsibilities </li></ul><ul><ul><li>Impossible to predict availability </li></ul></ul>
    21. 21. Case Study: Blue Fish Agile Process
    22. 22. History <ul><li>Used a Waterfall methodology for 4 years </li></ul><ul><li>Switched to Agile 2 years ago after experimenting with it on various projects </li></ul><ul><li>Primary Drivers for Change </li></ul><ul><ul><li>Heavy documentation wasn’t adding value </li></ul></ul><ul><ul><li>Wanted teams more invested in client success </li></ul></ul><ul><ul><li>Needed less reliance on “heroic efforts of individuals” </li></ul></ul>
    23. 23. Overview <ul><li>Elements from multiple methodologies </li></ul><ul><ul><li>Rational Unified Process (RUP) </li></ul></ul><ul><ul><li>Extreme Programming </li></ul></ul><ul><ul><li>Scrum </li></ul></ul><ul><ul><li>Crystal Clear </li></ul></ul>
    24. 24. RUP Phases… Elaboration Construction Transition Inception Project Lifecycle <ul><li>Understand Business Problem </li></ul><ul><li>Envision Solution </li></ul><ul><li>Identify Risks </li></ul><ul><li>Design </li></ul><ul><li>Prototype </li></ul><ul><li>Prepare for Construction </li></ul><ul><li>Iterate </li></ul><ul><li>Test </li></ul><ul><li>Frequent Releases </li></ul><ul><li>User Adoption </li></ul><ul><li>Documentation </li></ul><ul><li>Training </li></ul><ul><li>Hand-Off </li></ul>Project Management
    25. 25. …with Agile Practices <ul><li>Planning Game (XP) </li></ul><ul><li>Frequent Releases (XP) </li></ul><ul><li>Testing (XP) </li></ul><ul><li>Refactoring (XP) </li></ul><ul><li>Frequent Integration (XP) </li></ul><ul><li>Active Customer (XP) </li></ul><ul><li>Coding Standards (XP) </li></ul><ul><li>Daily Stand-Up Meeting (Scrum) </li></ul><ul><li>Osmotic Communication (Crystal Clear) </li></ul>
    26. 26. Other Blue Fish Practices <ul><li>Ideal Hours and Velocity </li></ul><ul><li>Management through Systems </li></ul>
    27. 27. Internal Systems
    28. 28. Lessons Learned
    29. 29. Positive Effects <ul><li>Higher User Adoption/Fewer Missed Requirements </li></ul><ul><ul><li>User Involvement </li></ul></ul><ul><li>Things Get Done Sooner </li></ul><ul><ul><li>Iterations and Daily Stand-Up Meetings </li></ul></ul><ul><li>Increased Management Confidence </li></ul><ul><ul><li>Early and Frequent Releases </li></ul></ul><ul><li>Improved Assimilation of New Team Members </li></ul><ul><ul><li>Pair Programming </li></ul></ul><ul><li>Reduced Defects </li></ul><ul><ul><li>10 month project generated only 40 hrs. of bug fixes </li></ul></ul>
    30. 30. Other Lessons Learned <ul><li>Methodology is not a replacement for a strong Project Manager and strong Technical Lead </li></ul><ul><li>Have flexibility on long-term commitments, but hold accountable to short-term commitments </li></ul><ul><li>It is better to complete a few deliverables 100% than to be 90% on all deliverables </li></ul>
    31. 31. Frequently Asked Questions <ul><li>How do you meet clients’ needs for documentation? </li></ul><ul><li>How do you meet clients’ needs for certainty? </li></ul>
    32. 32. For More Information <ul><li>“ Whatever process you start with will not be the process that'll really work for you. You have to take charge of your process, monitor it and adapt it to your circumstances. In the end it must become your process, any other labels are secondary.” </li></ul><ul><ul><ul><li>– Martin Fowler </li></ul></ul></ul>www.bluefishgroup.com

    ×