• Save
Using agile for business process design and development oct 19, 2010 ottawa
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Using agile for business process design and development oct 19, 2010 ottawa

  • 3,118 views
Uploaded on

Is Agile Scrum just for software development or can it also be used to achieve great business process design and development as well? ...

Is Agile Scrum just for software development or can it also be used to achieve great business process design and development as well?

Presented to the Ottawa IIBA Chapter on October 19, 2010

More in: Business , Technology
  • 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
3,118
On Slideshare
3,027
From Embeds
91
Number of Embeds
6

Actions

Shares
Downloads
22
Comments
0
Likes
1

Embeds 91

http://ottawa-outaouais.iiba.org 53
http://ottawa-outaouais.theiiba.org 21
http://paper.li 12
http://www.linkedin.com 3
http://oo.iiba.org 1
https://www.linkedin.com 1

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. Is Agile Scrum just for software development or can it also be used to achieve great business process design and development as well? Ottawa-Outaouais IIBA Chapter October 19, 2010 Larry Cooper, B.Sc., M.A. (Public Administration) PMP, ITIL Expert, CSM, ISO 20000 Consultant, CPM, Project+ Hosted by: Global Knowledge May 2010 BSS Nexus Global © 2010
  • 2. Disclaimer • The content of this presentation is the commercial confidential property of BSS Nexus Global Inc used under license from its parent companies where applicable: Geo-Spatial Project Learning Institute, Blue Box Inc. and AltNexus Corporation • The approach presented was customized based on the project environment, organizational context, and evolving circumstances and may or may not work exactly as presented for another project context • What is presented is only a portion of the overall approach used in the project as it relates specifically to how process design and development was done using one of the adapted methods. An understanding of the overall approach (all adapted method’s) is needed for individual project success • No single method is a “Silver Bullet” – EVER May 2010 BSS Nexus Global © 2010
  • 3. The Professional Me • 30+ years in IT in public/private sector in Canada and USA • B.Sc. Computer Science, M.A. (Public Administration) • PMP, CSM, ITIL V3 Expert, ISO 20000 Consultant, CPM, Project+ • Background in: Software Development, Systems Integration, IT Operations, Business Process Design, Methodology Development and Adaptation Science-based, HR, Learning Management, Financial and Supply Management business areas • Author of industry articles, white papers, and in books • Top ITIL whitepaper download on www.Forbes.com in 2007 (written for Global Knowledge – “Implementing ITIL using the PMBOK in Four Repeatable Steps”) • Created the Capability Release Strategy for the worlds largest web-enabled Supply Chain system • Instructor since 2006 in ITIL/ITSM, Project Management and Soft Skills • Roles: Programmer, Programmer Analyst, Manager IT Operations, Director, PM, Test Manager, Instructor, Author, Business Process Designer, Courseware Developer, Strategic Advisor, Business Analyst, Capacity Manager, Configuration Manager, invited speaker Main trait: I LOVE VARIETY AND CHANGE! New Motto: “I never met a method that I could not adapt” May 2010 BSS Nexus Global © 2010
  • 4. Agenda • Project Context • Methodology • Agile • Typical Process (re)Design Approach • Agile Adaptations • Agile “Work” • Managing Process Design and Development Sprints • Project and Agile Results • Take Aways May 2010 BSS Nexus Global © 2010
  • 5. Project Context • Typical Project Direction was Given: “Buy and Implement a <tool>” • Direction Taken: We brought the project team and sponsor back to Strategic Goals, Desired Outcomes, Business Services, Processes and then the Tools May 2010 BSS Nexus Global © 2010
  • 6. Agenda • Project Context • Methodology • Agile • Typical Process (re)Design Approach • Agile Adaptations • Agile “Work” • Managing Process Design and Development Sprints • Project and Agile Results • Take Aways May 2010 BSS Nexus Global © 2010
  • 7. Methodology • [meth-uh-dol-uh-jee] (from Wikipedia) noun, plural -gies. • A set or system of methods, principles, and rules for regulating a given discipline, as in the arts or science • Philosophy – The underlying principles and rules of organization of a philosophical system or inquiry procedure – The study of the principles underlying the organization of the various sciences and the conduct of scientific inquiry • Education – A branch of pedagogics dealing with analysis and evaluation of subjects to be taught and of the methods of teaching them • In IT, Methodologies are like Standards in that “they are wonderful, there are so many to pick from!” May 2010 BSS Nexus Global © 2010
  • 8. Organization’s Method-of-Choice • Agile Scrum HAD to be used – but it had only been used on software development projects to date in the organization PM was given three days of Agile training and lead BA was given one day • Some folks in Agile space suggest project teams should follow the method “religiously”. This view ignores: Team member experience using other similar methods such as Spiral, Iterative, JRP/JAD/RAD, RUP Project was to procure and implement a COTS product as well as develop required business processes – NOT develop software Reality is an awful thing – it is littered with facts that confuse the “text book”… • What we did: We realized that to implement the method ‘as-is’ for our project would not work We favored Agile adaptation over adoption so we would not become “Method Lemmings!” • We did that for a number of other methods we needed to use, such as using IT Service Management practices to define the Business Services layer – I called our approach “Method Mash-ups” We (PM and Lead BA) both became Certified Scrum Masters (CSMs) May 2010 BSS Nexus Global © 2010
  • 9. Agenda • Project Context • Methodology • Agile • Typical Process (re)Design Approach • Agile Adaptations • Agile “Work” • Managing Process Design and Development Sprints • Project and Agile Results • Take Aways May 2010 BSS Nexus Global © 2010
  • 10. What’s Unique about Agile Scrum? • Introduced the idea of “empirical process control” That is, Scrum uses the real-world progress of a project — not a best guess or uninformed forecast — to plan and schedule releases. • Projects are divided into succinct work cadences, known as sprints, which are typically one week, two weeks, or three weeks in duration At the end of each sprint, stakeholders and team members meet to assess the progress of a project and plan its next steps This allows a project’s direction to be adjusted or reoriented based on completed work, not speculation or predictions May 2010 BSS Nexus Global © 2010
  • 11. Scum Principles • Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan May 2010 BSS Nexus Global © 2010
  • 12. Agenda • Project Context • Methodology • Agile • Typical Process (re)Design Approach • Agile Adaptations • Agile “Work” • Managing Process Design and Development Sprints • Project and Agile Results • Take Aways May 2010 BSS Nexus Global © 2010
  • 13. Typical Process (re)Design Approach • Document the old process in detail (“as-is”) • Identify the issues in the old process • Conduct Design phase for a new process (“to-be”) • Design the details for the new processes • Implement the whole thing as one giant project • Hope it works (and that the design is still relevant after so much time has passed) • This is pretty much a Waterfall Approach This is not very Agile! Though it could be Lean… May 2010 BSS Nexus Global © 2010
  • 14. Agenda • Project Context • Methodology • Agile • Typical Process (re)Design Approach • Agile Adaptations • Agile “Work” • Managing Process Design and Development Sprints • Project and Agile Results • Take Aways May 2010 BSS Nexus Global © 2010
  • 15. Adaptations made to Agile Scrum • Terminology • Determining Process Complexity • Team Availability • Team Composition • Determining “highest business value” • Process Development May 2010 BSS Nexus Global © 2010
  • 16. Terminology Adjusted Old Term New Term Description User Story Process Story Used to define processes rather than software. Epics were used where we knew it involved more than one sub-process. Processes were kept at a high-level User Role “As a <Role>” – Roles are groups of users who have a Responsibility (RACI) in a process Product Owner Product Owner as Main Product Owner not available due to other “voice of customer” commitments – used a “voice of the customer” approach to overcome. Assigned Product Owner participates daily but has to coordinate, consolidate, and arbitrate input from others. Escalated to project sponsor where needed – though it was rare. May 2010 BSS Nexus Global © 2010
  • 17. Terminology Introduced New Term Description Minimally Acceptable Processes In the spirit of Lean Process we only defined processes that (MAPs) were absolutely necessary. Also avoided having to do the “as-is” and jump straight to the “to-be” Measurement and Analytics Wanted measurement to be a “by-product” of work rather than Framework work itself (combines with process automation to achieve that). Defines what, where, how to measure and how to link to other measurements/metrics as part of an overall Analytics Framework Task Supports Defined the work instructions, KSA’s for the Role within the process step, which also has deep links into the LMS for any available Skills training modules. Basis for Learning-in-Context Framework™ Learning-in-Context Access to learning is built-in to processes and accessed at the time the skill is being applied May 2010 BSS Nexus Global © 2010
  • 18. Estimating Process Complexity Scale Level of Complexity • Each process assigned a level of 5 Very High complexity – we adapted over time by using comparable processes we 4 High had developed 3 Medium • Used empirical observation over 2 Low several sprints to determine team Velocity 1 Very Low • Epics used same scale • Velocity was also dependent on team member availability and other work May 2010 BSS Nexus Global © 2010
  • 19. Team Availability • Agile Scrum Premise • Project reality: – Project team must be co-located – Team not co-located – Must be 100% available – Team not available 100% • Adjustments made: – Created “war room”– meet same time every day – Scheduled business team members when needed – Business members of team could also drop in “ad hoc” and we would accommodate discussions based on who was available May 2010 BSS Nexus Global © 2010
  • 20. Team Composition • Agile Scrum Premise • Team Approach – Product Owner represents the – Product owner acted as “voice of business the customer” – Scrum Master • Provided with a custom ½ day training session – Team is mostly IT as it is software development – Scrum Master (PM or Lead BA depending on circumstances/ need) – “One team” approach for business and IT • IT brought business analysis, design skills, and systems thinking • Business knew subject matter • Whole of client organization participated • We were ALL “process developers” May 2010 BSS Nexus Global © 2010
  • 21. Determining Highest Business Value • Agile Scrum Premise • Team approach: – Do “highest business value work” – Used same rating scale for first (but leaves open to team to “highest business value” as we decide what is meant by “highest did for level of complexity business value”) – Focused on MAPs – Deliver working software – Used MAPs to determine what incrementally was needed to launch in – Product Owner decides production (based on original focus area for project) – Product Owner and core team decides May 2010 BSS Nexus Global © 2010
  • 22. Process Development • Identified the top level processes first – this is not BDUF as you need a roadmap (a major tenant of Agile Scrum) • Identified Process Stories for each major process area and assigned Business Value with Product Owner – in some cases first pass only identified that the Process was an Epic • Assigned level of complexity to each Process Story • Determined which Process Stories were needed for production of originally identified tool – these became the MAPs • Applied Lean process design approach – considered Flow, Motion, Unnecessary approval steps, etc. as processes were being designed • Used combination of “straw-man” approach and joint-process design and development with whole project team to define sub-processes Used “dumbed down” version of BPMN – started in Visio May 2010 BSS Nexus Global © 2010
  • 23. Collaboration • Agile Scrum Premise • Team Approach – Daily Huddles – One project team (single PM) – Product Owner – Product Owner – “pigs” and “chickens” – Daily meetings of core team (1 to – Sprint Planning meetings and 1.5 hours) to define processes or Retrospectives to review “straw-man” processes (only “pigs” present but which ones depended on topic) – Daily contact was critical to success – Weekly Sprint planning meetings Monday mornings and Retrospectives Friday afternoon May 2010 BSS Nexus Global © 2010
  • 24. Adapted Scum Principles • Individuals and interactions over processes (of the process) and tools • Working processes over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan May 2010 BSS Nexus Global © 2010
  • 25. Agenda • Project Context • Methodology • Agile • Typical Process (re)Design Approach • Agile Adaptations • Agile “Work” • Managing Process Design and Development Sprints • Project and Agile Results • Take Aways May 2010 BSS Nexus Global © 2010
  • 26. Agile “Work” of the Project • As work evolved, other organizational relevant initiatives that were underway opened up opportunities for the project specifically in the areas of: Workflow and process automation Content management • Result: “Agile behaviours and thinking” allowed us to adapt to these opportunities This was not a scope change. It simply affected how the developed processes would be implemented as it made implementation easier to do • Further adjustments made: Measurement could now be a by-product of work rather than being work Became “poster-child” for how to use new tools “out-of-the-box” Task Supports moved over to individual Wiki’s with SME moderators – updatable by people to do the work and can capture expert advisory and tips as they evolve May 2010 BSS Nexus Global © 2010
  • 27. Agenda • Project Context • Methodology • Agile • Typical Process (re)Design Approach • Agile Adaptations • Agile “Work” • Managing Process Design and Development Sprints • Project and Agile Results • Take Aways May 2010 BSS Nexus Global © 2010
  • 28. Managing Process Design and Development Sprints • Used VersionOne Team Edition (www.versionone.com) – on-line 10 user license for free • Changed title for “User story” to “Process Story” • Set up Sprint numbers to correspond to the MS Project Sprint timelines • Added a special Sprint called “Backlog” All Process Stories first get entered into the Backlog as they emerge and then get added to the Sprint during the Monday morning meeting Usually estimated for level of complexity at time of addition to the Backlog but can be adjusted along the way Sprints (and hence Process Stories) are closed on Friday afternoons May 2010 BSS Nexus Global © 2010
  • 29. Main Screen May 2010 BSS Nexus Global © 2010
  • 30. Backlog May 2010 BSS Nexus Global © 2010
  • 31. A Sprint May 2010 BSS Nexus Global © 2010
  • 32. Agenda • Project Context • Methodology • Agile • Typical Process (re)Design Approach • Agile Adaptations • Agile “Work” • Managing Process Design and Development Sprints • Project and Agile Results • Take Aways May 2010 BSS Nexus Global © 2010
  • 33. Project and Agile Results • Project Results: Processes were defined to support Business Services Tools identification and selection was based on Strategic Goals, Desired Outcomes, Business Services, and Process needs Original Tool that was requested ended up being one of five (5) sets of different tools that were actually needed for successful implementation • Original Tool, Workflow, Authoring Tools, Content Management, Measurement and Analytics Originally identified tool is embedded as but one of the tools needed to support just one of the four major process areas that are required for the business unit to support its defined Strategic Goals • Agile Results: • In spite of all that could be considered as additional, we have not in fact exceeded the original project budget or timeline outside of planned contingency • Agile thinking enabled us to adjust to facts as they became evident in the context of our overall roadmap May 2010 BSS Nexus Global © 2010
  • 34. Original Postulates Q1: Is Agile Scrum just for software development? A1: No! Q2: Or can it also be used to achieve great business process design and development as well? A2: Yes! May 2010 BSS Nexus Global © 2010
  • 35. Where are we going next? • Agile Learning Framework™ (ALF) • In-Context Learning Framework™ Adapting social networking tools to support Just-in-Time Learning • Agile Content Design and Development Framework May 2010 BSS Nexus Global © 2010
  • 36. Agenda • Project Context • Methodology • Agile • Typical Process (re)Design Approach • Agile Adaptations • Agile “Work” • Managing Process Design and Development Sprints • Project and Agile Results • Take Aways May 2010 BSS Nexus Global © 2010
  • 37. Take Aways • Agile Scrum is a Method but being Agile encompasses both Behaviours (i.e. way of acting) and a way of Thinking • Many methods need to get adapted for any project to be successful – “Method Mash-ups” • Collaboration is critical for any project to be successful – Agile is premised on collaboration • “We value method adaptation over method adoption” Don’t be a METHOD LEMMING! May 2010 BSS Nexus Global © 2010
  • 38. For more information Larry.Cooper@BSSNexus.com 11-300 Earl Grey Drive Ottawa, ON K2T 1C1 1-888-316-2745 (613) 868-0982 (cell) May 2010 BSS Nexus Global © 2010