ME2011 presentation by Hoppenbrouwers


Published on

Agile Service Development: A Rule-Based Method Engineering Approach

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Main vision, base framework Design the methods based on the situation at hand Construct a process - Process execution
  • These practices originate from various literature sources.
  • ASD game is bedoeld om aantal
  • ME2011 presentation by Hoppenbrouwers

    1. 1. Agile Service Development: A Rule-Based Method Engineering Approach Stijn Hoppenbrouwers, Martijn Zoet, Johan Versendaal, Inge van de Weerd
    2. 2. Context: Agile Service Development project <ul><li>Applied research collaboration on “Agile Service Development” </li></ul><ul><li>Will run until Dec 31, 2011 </li></ul><ul><li>Includes WPs concerning: </li></ul><ul><ul><li>WP1 Agile Way of Working (“the processes”) </li></ul></ul><ul><ul><li>WP2 Model-based Service Development (“the languages”) </li></ul></ul><ul><ul><li>WP3 Model-based Communication with Stakeholders </li></ul></ul><ul><li>Continuous collaboration with & cases in industry </li></ul><ul><li>Today: </li></ul><ul><ul><li>Method Engineering aspects of WP1: “ways of working” </li></ul></ul><ul><ul><li>“ Operationalization of Methods”, related to WP1 and WP3 </li></ul></ul>
    3. 3. Framework for construction and execution of a tailorable agile process Resources Roles Tasks Activities Artifacts Rules filled in down to operational level Communication Situations Situational Method Engineering Process Specification Process Execution Goal-driven selection of method fragments Goal-driven execution of process activities Practices that fulfill goals Business Requirements Management with ArchiMate extension <ul><li>Tools like </li></ul><ul><li>AgileFant </li></ul><ul><li>Rational RTC </li></ul><ul><li>Xplanner </li></ul><ul><li>Tools like </li></ul><ul><li>EPF </li></ul><ul><li>Method Composer </li></ul><ul><li>In a standard language: </li></ul><ul><li>SPEM </li></ul><ul><li>UMA </li></ul>Process goals are not met
    4. 4. Main distinguishing principles (1) <ul><li>Based on Practices approached as Patterns expressed as Rules set for the metaphorical ‘game of ASD’: more liberal and light-weight than strict “flow + metamodel” approach </li></ul><ul><li>Strong emphasis on goals in selection & structuring: business goals, system goals, project goals, communication goals, … </li></ul><ul><li>Continuous change of practices (as well as goals) is rule, not exception: ‘rules of the game may be changed every round’ as situation requires; strong user influence; ‘enforcement’ not taken for granted </li></ul><ul><li>Identification by means ‘ agile scan ’ of ‘agile areas’: some aspects/deliverables/phases cannot be agile because of e.g. compliance, architecture, legacy </li></ul>
    5. 5. Main distinguishing principles (2) <ul><li>Situational selection of practices: primarily ‘ negative selection ’ (cancelling out practices) based on broad range of situational factors. Also positive selection mostly based on goals. </li></ul><ul><li>Elements of self-organization : if situational factors do not lead to selection of exactly 1 practice, or even lead to 0 practices: leave choice/solution to project members. </li></ul><ul><li>Minimal selection /representation: only include in the method what you expect you really need/want. Functionality of methods? Guiding; constraining. </li></ul><ul><li>Postponing of selection: ‘operational’ practices (aiming at micro planning and specific communication situations ) to be filled in much later than ‘general practices’ </li></ul>
    6. 6. Inventory of agile practices Self-organizing team Deliver frequently Test everything Architect also implements Measure value Clear the path Unity of purpose Engage customer Domain expertise in roles Architect controls product Function owner and component owner Unity of purpose Team Product owner Sprint planning Burndown chart Product backlog Daily standup Model storming Active stakeholder parcticpation Document late Just barely good enough Architecture initiated business goals Focus on value stream Jim Coplien Agile and Lean Scrum Scott Ambler Agile Advice and many more …
    7. 7. Practice template
    8. 8. Communication situations Method execution in project Selection Situational factors Method Base Method (rules) SME Selection “ Comm. Setup Base” Communication Setup Situational factors “ OME”
    9. 9. Direction for selection mechanism <ul><li>‘ Situational factors scoreboard’ </li></ul><ul><li>Indicate current and desired situation </li></ul><ul><li>Select practices by exclusion </li></ul><ul><li>Example </li></ul><ul><li>Practice legacy analysis not relevant in greenfield situation </li></ul><ul><li>Practice iterative architecture development not relevant when architecture known and service simple </li></ul>
    10. 10. ASD Game <ul><li>Ingrediënten </li></ul><ul><li>Multiple stakeholders </li></ul><ul><li>Various stakes </li></ul><ul><li>Team goals and individual goals </li></ul><ul><li>Selection of practices </li></ul><ul><li>Sudden events </li></ul><ul><li>Agile process approach (scrum-ish) </li></ul>
    11. 11. Tooling <ul><li>Looked at IBM Method Composer, but found it too rigid </li></ul><ul><li>Be Informed (decision modeling & technology) is now building a tool for practice selection: </li></ul><ul><ul><li>Repository of practices & their distinguishing features </li></ul></ul><ul><ul><li>Selection mechanism based on situational factors </li></ul></ul><ul><ul><li>All in the spirit of ASD principles </li></ul></ul><ul><li>Looked at process management tools like AgileFanth, Rational RTC and Xplanner </li></ul><ul><li>Experimenting with semantic wiki-based “Method Management System” combining goal-based method visualisation and log </li></ul>