1 / 57

Gartner Workshop Series: Applying Agile Strategies to BPM Development

Workshop Objectives. During this workshop, you will learn how to: Leverage Agile BPM development strategies to minimize risk and speed time-to-value on BPM initiatives Manage the Process Discovery Phase using agile documentation and collaborative modeling principlesCreate a flexible BPM project

adin
Download Presentation

Gartner Workshop Series: Applying Agile Strategies to BPM Development

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

    1. Gartner Workshop Series: Applying Agile Strategies to BPM Development

    2. Workshop Objectives During this workshop, you will learn how to: Leverage Agile BPM development strategies to minimize risk and speed time-to-value on BPM initiatives Manage the Process Discovery Phase using agile documentation and collaborative modeling principles Create a flexible BPM project plan that puts business stakeholders in the driver’s seat while empowering developers 9/1/2012 What tools and techniques teams are using to minimize risk and speed time-to-value in BPM projects? How agile methods can be leveraged in modeling and prototyping capabilities of BPM. How to leverage agile methods with key features of BPM suites. How leading organizations are driving to push solutions out in 60 to 90 days. How to leverage BPM as a "Rapid Solution Development" platform. How to standardize on an implementation methodology. What tools and techniques teams are using to minimize risk and speed time-to-value in BPM projects? How agile methods can be leveraged in modeling and prototyping capabilities of BPM. How to leverage agile methods with key features of BPM suites. How leading organizations are driving to push solutions out in 60 to 90 days. How to leverage BPM as a "Rapid Solution Development" platform. How to standardize on an implementation methodology.

    3. Workshop Agenda 9/1/2012

    4. Introductions Clay Richardson Practice Leader for PPC’s dedicated BPM Practice Certified BPM Professional – Boston University Chair, Workflow Management Coalition (WfMC) Public Sector Former Director, Professional Services for HandySoft Global Corporation 9/1/2012

    5. Module 1 An Introduction to Agile BPM 9/1/2012

    6. Module Objectives By the end of this module, you will be able to: Understand why agile development is ideally suited to implementing BPM initiatives Evaluate the pro’s and con’s of popular agile development methodologies Define the key phases and roles involved with implementing Agile BPM projects 9/1/2012

    7. BPM Vendors: “Yes, your BPM Analysts can develop the processes with minimal support from IT.” Line of Business: “This is great! We can get things out faster without having to go through IT” IT Managers: “This is great! Line of Business can get things out with minimal support from us.” This is not reality… Dealing with the 800-lb Gorilla 9/1/2012

    8. Reality Check Successful BPM initiatives require… Balanced and effective collaboration between Lines of Business and IT Significant investments in development and IT resources (70% - 80% of costs can be attributed to development) Repeatable development methodologies for managing costs and scope throughout implementation 9/1/2012

    9. Waterfall Approach to BPM Leading up to Y2K, IT budgets ballooned and in many cases IT was seen as business innovation in and of itself. Analogy: before and immediately following Y2K the business innovation pendulum was squarely placed in the IT quadrant. However now, the pendulum is more in the Business Quadrant. Business feels that they are accountable for delivering value and want to be more involved in solution development. In some cases business has even formed their own internal IT/Development team to gain more control. This scenario created nightmares for IT. Image: Show clock pendulum and examples of where things were in 2000 and where they are now.Leading up to Y2K, IT budgets ballooned and in many cases IT was seen as business innovation in and of itself. Analogy: before and immediately following Y2K the business innovation pendulum was squarely placed in the IT quadrant. However now, the pendulum is more in the Business Quadrant. Business feels that they are accountable for delivering value and want to be more involved in solution development. In some cases business has even formed their own internal IT/Development team to gain more control. This scenario created nightmares for IT. Image: Show clock pendulum and examples of where things were in 2000 and where they are now.

    10. Waterfall’s Shortcomings “Throw it Across the Wall” phases increases likelihood of delivering a solution that does not match requirements “Command and Control” approach not conducive to collaborative nature of BPM Projects Requirements are constantly shifting on BPM projects; Waterfall emphasizes measure twice, cut once Lack of feature prioritization increases likelihood of scope creep and increases overall project risk 9/1/2012

    11. Waterfall - Factors Impacting Failed Projects Agile Development has evolved over the last 5 – 10 years to provide a platform for the business and technical teams to collaborate on solution the development. Agile allows organizations to roll out solutions in very short time-boxed intervals. The idea is for the business and technical teams to work very closely together throughout solution development to ensure that the solution envisioned by the business is what is ultimately delivered. Common feedback after completing the first agile project: Technical – “I knew what I needed to do throughout the project”, “Development went much faster than I expected”, Business – “The solution turned out exactly as we envisioned”, “It was good to see the solution come on-line through rapid cycles and to be able to provide quick feedback on changes” Image: Target showing an arrow in it.Agile Development has evolved over the last 5 – 10 years to provide a platform for the business and technical teams to collaborate on solution the development. Agile allows organizations to roll out solutions in very short time-boxed intervals. The idea is for the business and technical teams to work very closely together throughout solution development to ensure that the solution envisioned by the business is what is ultimately delivered. Common feedback after completing the first agile project: Technical – “I knew what I needed to do throughout the project”, “Development went much faster than I expected”, Business – “The solution turned out exactly as we envisioned”, “It was good to see the solution come on-line through rapid cycles and to be able to provide quick feedback on changes” Image: Target showing an arrow in it.

    12. Waterfall – Actual Use of Requested Features

    13. Agile Development Principles Agile development emphasizes… Evolutionary requirements development Time-boxed, iterative development Client-valued functionality Feature and functionality prioritization 9/1/2012

    14. Agile vs. Waterfall Agile Development has evolved over the last 5 – 10 years to provide a platform for the business and technical teams to collaborate on solution the development. Agile allows organizations to roll out solutions in very short time-boxed intervals. The idea is for the business and technical teams to work very closely together throughout solution development to ensure that the solution envisioned by the business is what is ultimately delivered. Common feedback after completing the first agile project: Technical – “I knew what I needed to do throughout the project”, “Development went much faster than I expected”, Business – “The solution turned out exactly as we envisioned”, “It was good to see the solution come on-line through rapid cycles and to be able to provide quick feedback on changes” Image: Target showing an arrow in it.Agile Development has evolved over the last 5 – 10 years to provide a platform for the business and technical teams to collaborate on solution the development. Agile allows organizations to roll out solutions in very short time-boxed intervals. The idea is for the business and technical teams to work very closely together throughout solution development to ensure that the solution envisioned by the business is what is ultimately delivered. Common feedback after completing the first agile project: Technical – “I knew what I needed to do throughout the project”, “Development went much faster than I expected”, Business – “The solution turned out exactly as we envisioned”, “It was good to see the solution come on-line through rapid cycles and to be able to provide quick feedback on changes” Image: Target showing an arrow in it.

    15. 9/1/2012

    16. 9/1/2012

    17. Typical Phases of an Agile BPM Project 9/1/2012

    18. Key Agile BPM Project Roles Functional Lead – Develops and owns high-level requirements Domain Experts – Subject matter experts from line of business Architect/Technical Lead – Owns overall architecture, design, and development leadership responsibilities Programmers – Responsible for developing assigned features and functionality 9/1/2012

    19. Module Takeaways In this module you learned: Why agile development is ideally suited to implementing BPM initiatives How to evaluate the pro’s and con’s of popular agile development methodologies The key phases and roles involved with implementing Agile BPM projects 9/1/2012

    20. Module 2 Managing Process Discovery 9/1/2012

    21. Module Objectives By the end of this module, you will be able to: Understand and develop the key deliverables required during the Discovery Phase Host effective collaborative design sessions to quickly gain buy-in from business and technical teams Convert process documentation into concrete feature lists and feature sets Prioritize and categorize key features and functionality 9/1/2012

    22. Laying the Foundation Key Process Discovery deliverables include: High-Level Requirements Process Model Detailed Technical Specification Prototypes Feature List 9/1/2012

    23. High-Level Requirements Initial requirements sessions should be led by a skillful Functional Lead Create an early “Top 10” High-Level Requirements list with stakeholders and domain experts Assume requirements will change and shift throughout the entire project Use business case approach to keep stakeholders focused on KPI’s and ROI 9/1/2012

    24. Effectiveness of Communication Channels 9/1/2012 Traditional software development theory calls out for the creation of detailed documentation throughout the software development lifecycle.  Although this sounds like a good strategy in theory, in practice it proves to increase your overall costs and project risk. The reason why is that documentation is actually a very poor way to communicate, as Figure 5 depicts.  The implication of this diagram is that you should choose the best communication option available to you given your current situation.  Documentation options, in particular "paper specifications" are your least desirable choice, not the most desirable one.Traditional software development theory calls out for the creation of detailed documentation throughout the software development lifecycle.  Although this sounds like a good strategy in theory, in practice it proves to increase your overall costs and project risk. The reason why is that documentation is actually a very poor way to communicate, as Figure 5 depicts.  The implication of this diagram is that you should choose the best communication option available to you given your current situation.  Documentation options, in particular "paper specifications" are your least desirable choice, not the most desirable one.

    25. Critical Role of the Functional Lead Key traits to seek in an effective Functional Lead: Ability to manage conversations and remain on topic Trusted by both business and technical teams Negotiation and mitigation skills Fun, positive, and self-confident 9/1/2012

    26. Creating the Process Model Picture: Balance Documentation Needs vs. Need to Move Quickly Speed vs. UnderstandingPicture: Balance Documentation Needs vs. Need to Move Quickly Speed vs. Understanding

    27. Detailed Technical Specifications Convert process model and user interface requirements into a “pact” amongst the development team Describe how key technical components will interact and how they will be developed (i.e., web services, integration, portal interfaces, etc.) Should adhere to existing architecture and infrastructure guidelines established by organization and BPM initiative Technical Lead owns responsibility for developing the Technical Specifications 9/1/2012

    28. Process and User Interface Prototypes 9/1/2012

    29. Creating the Feature List A feature is defined as “client-valued” functionality that can be delivered in two-weeks or less Deconstructs the high-level requirements, process model, user interface design, and technical specs into smaller, manageable features Each feature is assigned an ID and is prioritized by the business stakeholders Similar features are grouped into a “feature-set” that represents a specific capability 9/1/2012

    30. Anatomy of a Feature Each feature should adhere to the following syntax: For example: 9/1/2012

    31. Defining Feature Sets A feature set is a grouping of business related features For BPM projects, examples feature sets include: process automation, views, BAM reports Feature sets provide business users with visibility into progress on key functionality and capabilities Feature sets can be grouped together into specific subject areas (e.g., accounts receivables management) 9/1/2012

    32. Prioritizing Features Conduct feature prioritization session with business and technical teams to identify which features are critical and which features are “nice to haves” Prioritization should be led and driven by the business Assign each feature a priority on a scale of 1 to 5, with 1 being “nice to have” and 5 being “must have” Set business at ease by explaining that the intent is to develop all features 9/1/2012

    33. Module Takeaways In this module you learned: How to develop the key deliverables required during the Discovery Phase Strategies for hosting collaborative design sessions to quickly gain buy-in from business and technical teams How to convert process documentation into concrete feature lists and feature sets How to prioritize and categorize key features and functionality 9/1/2012

    34. Module 3 Iterative Development 9/1/2012

    35. Module Objectives By the end of this module, you will be able to: Estimate and plan for iterative development Implement strategies to keep the business engaged and empowered throughout development Understand the importance of BPM development velocity and how it impacts return-on-investment for BPM initiatives 9/1/2012

    36. Creating the Iterative Development Plan Technical Lead and Developers work to assess complexity and level of effort for each feature Functional Lead and Technical Lead work to assign individual features to iterations Project Team finalizes plan for total number of iterations and number of days allotted to each iteration Project Team reviews final plan with stakeholders 9/1/2012

    37. Feature Estimation Tips Feature estimation sessions should be led by the Technical Lead Establish simple complexity or level-of-effort weighting scale with development team Avoid trying to estimate at a granular level (i.e., do not break out specific tasks required to complete the feature) Estimate using “man-days” Avoid estimating down to the hour 9/1/2012

    38. Low, Medium, High Complexity Weighting 9/1/2012

    39. Level of Effort Scale Weighting 9/1/2012

    40. Assess Project Level of Effort 9/1/2012

    41. Assigning Features to Iterations Imagine building a skyscraper using Legos You can build out each section of the sky scraper, Or you can build across the sections How does the business want to see it built out? 9/1/2012

    42. Feature Assignment Tips GUE (“Go Ugly Early”) – Assign the most difficult development tasks to the first iteration Complete the business’ high priority tasks in the first iterations in order to gain buy in and demonstrate critical functionality Include features in the same iteration when there is a tight dependency (e.g., the expense form feature needs to use the business rules provided by the per-diem calculation feature) 9/1/2012

    43. Assess Duration for Each Iteration 9/1/2012

    44. Finalize Development Plan Tweak plan to balance allotted time against overhead required for each iteration (e.g., testing, deployment, bug fix, etc.) Use MS Project or other project scheduling tool to establish Gantt Chart and calendar representation of project Review project plan and calendar with key stakeholders to confirm schedule and budget 9/1/2012

    45. Iteration Development – Sample Project Plan 9/1/2012

    46. Keeping the Business Engaged Successful BPM initiatives keep business domain experts and stakeholders engaged throughout iterative development Business should drive feature prioritization and planning sessions at the beginning of each iteration Business should drive feature certification sessions (i.e., user acceptance testing) at the end of each iteration Embed domain experts with development team, using “scrum room” approach 9/1/2012

    47. 46 Measure and Track Project Velocity Velocity Measures the Amount of Work an Agile BPM Team Can Complete in a Specified Period of Time Forces teams to evaluate lessons learned Improves overall project estimation Provides teams with a basis for improvement in definition and delivery

    48. Module Takeaways During this module you learned: How to estimate and plan for iterative development Strategies to keep the business engaged and empowered throughout development The importance of BPM development velocity and how it impacts return-on-investment for BPM initiatives 9/1/2012

    49. Module 4 Useful Agile BPM Tools and Resources 9/1/2012

    50. Agile BPM Project Plan Template 9/1/2012

    51. Open Source Agile Project Management Tool 9/1/2012

    52. Recommended Books 9/1/2012

    53. Websites Agile Modeling and Documentation http://www.agilemodeling.com Agile Software Development http://www.agilesoftwaredevelopment.com Craig Larman’s Website http://www.craiglarman.com Passion for Process http://www.passionforprocess.com 9/1/2012

    54. Summary and Wrap Up 9/1/2012

    55. Workshop Summary During this workshop, you learned how to: Leverage Agile BPM development strategies to minimize risk and speed time-to-value on BPM initiatives Manage the Process Discovery Phase using agile documentation and collaborative modeling principles Create a flexible BPM project plan that puts business stakeholders in the driver’s seat while empowering developers 9/1/2012 What tools and techniques teams are using to minimize risk and speed time-to-value in BPM projects? How agile methods can be leveraged in modeling and prototyping capabilities of BPM. How to leverage agile methods with key features of BPM suites. How leading organizations are driving to push solutions out in 60 to 90 days. How to leverage BPM as a "Rapid Solution Development" platform. How to standardize on an implementation methodology. What tools and techniques teams are using to minimize risk and speed time-to-value in BPM projects? How agile methods can be leveraged in modeling and prototyping capabilities of BPM. How to leverage agile methods with key features of BPM suites. How leading organizations are driving to push solutions out in 60 to 90 days. How to leverage BPM as a "Rapid Solution Development" platform. How to standardize on an implementation methodology.

    56. Questions 9/1/2012

    57. Thank You! Clay Richardson, Practice Leader Business Process Improvement Practice Project Performance Corporation 1760 Old Meadow Road McLean, Virginia 22102 703/748-7544 crichardson@ppc.com http://www.passionforprocess.com 9/1/2012

More Related