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

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

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


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”


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


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


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!”


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)


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


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


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…

Adaptations made to Agile Scrum
• Terminology
• Determining Process Complexity
• Team Availability
• Team Composition
• Determining “highest business value”
• Process Development


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.


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


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


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


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”


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


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


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


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


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


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


Main Screen


Backlog


A Sprint


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


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!


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


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!


For more information
Larry.Cooper@BSSNexus.com
11-300 Earl Grey Drive
Ottawa, ON K2T 1C1
1-888-316-2745
(613) 868-0982 (cell)


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

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

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

Semelhante a Using agile for business process design and development oct 19, 2010 ottawa (20)

Mais de AdaptiveOrg Inc.

Mais de AdaptiveOrg Inc. (8)

Último

Último (20)

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