Applying Agile Project Management to a Customized Moodle Implementation

Applying Agile Project Management

to a Customized Moodle Implementation

November 6, 2013

Presented by:

Agenda

• What is CCLE?

• What is Agile?

• Overview of Scrum

• Moodle HQ and Scrum

• CCLE and Scrum

• CCLE Agile Retrospective

• Next steps - Automated Testing

• Questions

Goals:

• A basic understanding of Agile and Scrum

• How UCLA has applied Agile principals

• Get you thinking on how you can use these tools

What is CCLE?

 Common Collaboration and Learning Environment

•

 Supports: Instruction, Collaboration and Research

 Users: Faculty, Students and Staff.

 First successful, large scale, project that pulls together

Growth of CCLE

Total Course Sites

Logins per Day Total Users

LMS on Campus 2013

Humanities - CCLE

GSEIS - CCLE

Social Sciences - CCLE

Nursing - CCLE Arts and Architecture - CCLE

Public Affairs - CCLE

Public Health - CCLE Statistics - CCLE

Anderson – CCLE

Physical Sciences - CCLE Mathematics – CCLE Engineering – CCLE (2014)

Shared Governance Model

Academic Leadership, Deans, CIOs

Governance

Faculty Group Standards and Practices _Group Student Group

Operations Autonomous Department System Common Interest Group (CIG) Shared Campus

Operations CCLE Subgroups

Autonomous Department System Autonomous Department System CCLE Home CCLE Home CCLE Coordinator Lead Developer Support Coordinator

System Administrator – Shared System Programmer/Back-up Sys Admin

CCLE: Customized Moodle

Managing Code Divergence

 Technical Debt: Moodle is constantly changing

 Rework is a constant.

• Developing and “Evolving” a customized Moodle instance amounts to a series of projects - some large, some small.

• What is a Project?

• A temporary group activity designed to produce a

unique product, service or result.

• A project is unique; it is not a routine operation

• Project management is the application of knowledge,

skills and techniques to execute projects effectively and efficiently.

• Scope: Improvements, fixes, new functionality

• Schedule: Often dictated by academic calendar

• Resources: Existing staff, matrix staff, contractors

• One cannot change without affecting the others

• Two Methodologies to consider: Waterfall and Agile

Triple Constraint:

Compare Methodologies

“You know the least about a project at the start “

RE Q UI RE M E NT S Design Test Test Develop Integrate Test D EM O & F EED BAC K RE Q UI RE M E NT S Design Test Test Develop Integrate Test D EM O & F EED BAC K RE Q UI RE M E NT S Design Test Test Develop Integrate Test D EM O & F EED BAC K

Sprint 1 Highest Priority Features

Sprint 2 Highest Priority Features

 Agile projects are 3 times more successful than non-Agile projects.

Waterfall vs. Agile

The Standish Group defines project success as:

 Agile: “umbrella term” for Iterative, Incremental Software Development Methodologies.

 Agile methodologies include: Extreme Programming (XP), Scrum, Crystal, Dynamic Systems Development Method (DSDM), Lean, and Feature-Driven Development (FDD).

 Agile methodologies emphasize: small teams delivering small increments of working software with great frequency while working in close

collaboration with the customer and adapting to changing requirements.

 Promotes Sustainable Development

 Constant Feedback

 Customer Collaboration

 Iterative Development

 Co-located Dedicated Team(s)

 Daily Communication

 Resolve Defects Early

 Self Organizing Teams - Team Members Take Ownership

Key Attributes of Agile

RE Q UI RE M E NT S Design Test Test Develop Integrate Test D EM O & F EED BAC K

“Responding to Change” Over “Following a Plan” Primary Measure of Progress:

 Scrum is the most widely recognized Agile Framework for the

iterative development of software

 Note: Sometimes the term Scrum is used interchangeably with the term Agile, this is incorrect

 Scrum is comprised of a series of short iterations–called Sprints.

 Each Sprint ends with the delivery of an increment of

working software.

Scrum = An Agile Framework

 Product Owner

 Stakeholder Representative - priority setting, “business side”,

controls $$, sets strategy and direction,

 Accepts/Rejects the work from the Sprint.

 Could have a PO proxy, more on this later

 Development Team (7 +-2)

 Product Creators: programmers, UI experts, testers, etc.  Cross functional skill sets, self organizing and self

managing, ideally full time and co-located.

 Scrum Master

 Project Facilitator. Supports the team as a servant-leader,

removes obstacles, has intuitional knowledge, helps to build consensus.

 Process Coach - keeps the team true to Agile principles

 Product Road Map - overall view of Product requirements

 Themes, “epic user stories”, tentative release time lines

 Product Backlog - list of all User Stories associated with the

project – main source for project requirements

 Sprint Backlog - list of Users Stories associated with the

current Sprint, includes estimates in hours to complete tasks (max time should be one day per task)

 Increment - the sum of all the Product Backlog Items

completed during a Sprint and all previous Sprints

 Burn Down Chart - a publicly displayed chart showing

remaining work in the Sprint Backlog



User Story:

 Title <a name for the user story>

 As a <User or persona>

 I want to <take this action>

 So that <I get this benefit>

 When I <take this action>, this happens <description of

action>

 Outlines the test case(s) for developers

 Can form that basis of Automated Testing.

 Stakeholders have direct input – “Customer Collaboration”

 Sprint - a consistent iteration of time (1-4 weeks)

 At the end the Development team deliveries of an increment of

working software.

 Sprint Planning - beginning of the cycle, select the work to be done

 Turn User Stories into Tasks - detail time and work estimates.

 Daily Scrum - ~15 min Coordination - Not Problem Solving

 What did you do yesterday? What are you planning to do today?

 Any impediments/stumbling blocks?

 Sprint Review – Demonstrate the working product

 Sprint Retrospect – Post mortem done after ever Sprint.

 What went well?

 What would we like to change? How can we make the change?

Moodle HQ and Scrum

 Moodle HQ’s move to Scrum

 Martin Dougiamas announcement December 10, 2010

 https://moodle.org/mod/forum/discuss.php?d=164057

 Moodle Tracker = Product Road Map : bugs and new features

 Major releases happening every 6 months (starting June 2012).

 Scrum Roles:

 Product Owner - Martin Dougiamas

 Representing the voice of all Moodle users

 Scrum Master - Michael de Raadt

 Two Development Teams: FRONTEND and BACKEND

 Most Moodle HQ developers are in Perth

Moodle HQ and Scrum

 Since 2.5 release both stable and dev work is achieved using Scrum.

 Prior to 2.5 just stable

 Backlog for FRONTEND and BACKEND teams ranked by Product Owner

 Three week Sprints - teams select issues from their relevant Product Backlogs.

 Retrospective held at the end of each Sprint

 Two Sprints are followed by a project week

 Developers are free to work on their own Moodle-related projects.

 Daily Scrum meetings (remote people via Google Hangouts)

 Product Owner

 CCLE is highly collaborative and consensus driven

 Two “Product Owner Proxies” represent the group.

 Development Team (7 +-2) … Just short of 7

 CCLE Home Team: 1 lead developer, 1 programmer/UI expert, 1 tester application expert, ~4 part time student developers/testers,

 .5 FTE matrix assigned programmer

 ~.5 FTE “Contributed” testing resources

 Scrum Master

 CCLE Coordinator (me): servant-leader, removes obstacles,

has intuitional knowledge, helps to build consensus.

 Process Coach : CCLE Coordinator and Lead Developer

 Product Road Map

 Features and Functionality Matrix (FFM)

 Captures input from stakeholders

 Reviewed and updated monthly

 1-2 years of work

 Product Backlog

 Prioritized items from the FFM

 User Stories captured in Jira

 Sprint Backlog

 Entered and edited in Jira, Kanban board

 Increment - Captured in FFM and Jira

 Burn Down Chart - Not used

 Sprints - 1-3 weeks, varies

 Sprint Planning – Turn User Stories into Tasks

 Consistent and Useful.

 Sprints include Bug Fixes and New Features

 Daily Scrum

 Done virtually with Jabber

 Varied schedules and not all co-located

 Sprint Review

 Released to stakeholders on Test and Stage environments

 Weekly meetings of key stakeholders

 Sprint Retrospect

 Not held consistently; mostly discussion after major releases

 Not much time between Sprints

Requirements and Priorities

CCLE

F&F Matrix “Product Road Map”

Reviewed Monthly

CIG and SPG

F&F Matrix

Faculty Survey

Faculty Advisory Group

Student Survey

Student Advisory Group

CCLE

Development Team and “Product Owners”

Features and Functionality Matrix (H, M, L) Feature Types: • System Operations • CCLE Archival • User Interface • Functionality Improv. • Integration with Campus Systems • Other CCLE sites • Staffing Resources • Admin/Support Tools • Mobile • Copyright • Documentation • Merge Code to Moodle .org • Contribute to Moodle .org • Governance • Other

Prioritizing Feature Requests

 2010-2011 FFM created for Moodle 2 migration – Waterfall

 Fall 2011 - move to Agile approach

 June 2012 launched Moodle 2.0 with all critical functions working

 “less important” items iterated over summer and fall

 An Agile approach was key to the smooth transition

 Focus and Re-focus on the top priorities

 Remember and Communicate the Triple Constraint

 Nothing is perfect on day one

 Make sure the most important things are

 Lessons Learned and Things to Work On

 Staffing falls short for true Scrum

 Product Owner Proxies are really representatives and have

limited “power”

 Some aspects of Scrum have not been implemented

 (Burn down chart, rigorous Scrum estimation techniques)

 Scrum is a skill - you get better as you do it.

 Testing is our Achilles heal

 It happened again moving to 2.5 …

 Common Agile Pitfall : Lack of Automated Testing

Automated Testing

 Behavior Driven Development (BBD) – Test Driven Dev.

 Behat is a ‘behavior driven’ testing framework

 Behat scripts are human readable stories that describe the

behavior of your application.

 Behat scripts are called ‘features’

 Each feature contains a scenario

 Scenarios are basically Agile “User Stories”

 Code may change over time, but the expected behavior should not.

 If the expected behavior has changed during a test, your code

Automated Testing

 Moodle.org supplies Automated Testing scripts in 2.5

 A custom Behat environment built to work with Moodle.

 Functions that generate data (like courses and students)

 A large set of predefined step definitions

 Example: “And I turn editing mode on”.

 Challenge for UCLA - heavily customized version of Moodle

 Edit Moodle supplied scripts

 Agile Project Management for Dummies, Mark C. Layton

 Platinum Edge Agile Training platinumedge.com

 http://agilemanifesto.org/principles.html

 http://agiledictionary.com

 http://docs.moodle.org/dev/Process

 http://docs.moodle.org/dev/Process#Sprints

 Project Management Institute http://www.pmi.org/

 http://en.wikipedia.org/wiki/Behavior-driven_development

 http://behat.org/

Curtis Fornadley, PMP

CCLE Coordinator

[email protected]