Project managing your learning projects with AGILE

For the first 7 or 8 years of my career, most learning projects were either (in the first few years) delivery of content someone else created or in the later few years, a vertical within some sort of product development cycle. In the latter case, there was usually some sort of project management methodology applied (small or grandiose) that I worked within alongside other services and teams like documentation, sales, development, etc.

It wasn’t until the latter half of my career, when I started broadening my scope, that my learning development projects were unfettered from other processes within an organization. Then I tackled competency programs like leadership, sales or customer support for example where the inception of the program stemmed from a current state issue or future state vision.

The value I took away from working within a properly project managed project focused mainly on the quality of output and structure for milestones and deadlines. When working towards a common end, it was important that all teams pass their gates and dependencies to ensure the deadlines were hit and that any due diligence (FDA, ISO, etc) tasks were done. I loved the structure of the roundtables where updates were made, discussion around obstacles were had and everyone was on the same page. The role of the project manager was so important and ultimately, could result in the success or failure of the project overall.

But what about those competency programs. Many organizations use tools like MS project or time/task trackers to drive these. Many more organizations rely on the discipline of the individual learning practitioners to apply their own varied PM skills to organize the other project participants and stakeholders and drive towards the goal.

One tool I was introduced to and came to really love was SCRUM. SCRUM is an AGILE project management methodology who’s intent in a nutshell is to drive quality and milestone hitting. It works in an AGILE way rather than a more waterfall based PM approach where it allows for scope to change throughout a project. Learning projects are notorious for being forced to shift and change. There are always stakeholders who demand additions or the organizations shift structure that you hadn’t anticipated on. SCRUM not only is able to cope with this, but thrives on it. For a learning project, it was adapted very little and was very easy to implement.

The project manager for a SCRUM project is called a Scrum Master. This person performs all SCRUM functions and helps facilitate the project for the team. I found for moderate sized projects this was about 15-20% effort tops for the resource once they had the steps down, so you could (and should) rotate the responsibility to people on the team (no need to hire a PM). That said, and to avoid getting rocks thrown at my house, some of the best Scrum Masters I’ve worked with were more traditional PMs but it’s not required. A very good Scrum Master I worked with was coached for a few months and facilitated a very large project alone, managing 4-500 hours of effort every 4 weeks. (Way to go Stephanie!)

Basically, SCRUM works in four steps:

The scope phase of a SCRUM project entails capturing all the details of what needs to be done for the project. I love using Mindjet MindManager for this, It allowed for me to let a group of stakeholders or SMEs go pretty wild in the brainstorming phase. We’d capture the output of the needs assessment, and organize via dragging the items into themes. In SCRUM, you would used “User Stories” that capture the intended result of experience for the software user. For a learning project it was a super fantastic way to start discussing learning objective and intended behaviour change. Personally, I would gather both stories and learning topics into logical buckets. Don’t worry about duplicates or wild ideas yet, let it flow.

Once all items are captured and organized into pretty firm scope. The team will size each “bucket” or scope item relative to each other. Practically, I start with the first and rate it out of 5 (MindManager allows you to do this easily). When I get to the next item, I ask the team if it’s smaller, same or bigger than the last. The project team and SMEs often have me go back and forth between items until they are happy with the result.

Lastly is to prioritize. Each item is rated numerically in regards to what we have to do first. This is most important if you plan on releasing modules or courses before the whole program is ready. It can be a really nice way to show results quickly. SCRUM also understands that priority can change too.

Once this is all done, you have created a “Product Backlog”. I liked to review it periodically with the team to calibrate any changes in priority, scope items or sizing. (monthly, bi-monthly or whatever). It should be handed to a Product Owner. This is a stakeholder on the team who can make some decisions. Mainly, if scope has been added/subtracted to a project, and determine priority changes to Product Backlog Items. Product Managers, Architects and or audience specialists can make great Product Owners.

In SCRUM each project is divided into smaller milestones called Sprints. This is typically from 1 to 4 weeks. At the start of each Sprint is a “Sprint Planning” session.
Sprint planning takes a couple hours tops at the start of a project and should get faster.

The outputs of this meeting are:

  1. How long is the Sprint in weeks?
  2. Each resource on the project (developers, IDs, SMEs) deciding how much time they will dedicate to the project (I like % per 40 hour work week)
  3. Based on the number of hours available, the Product Owner will decide which scope items (goals) to work on (Typically these are “courses or modules”)
  4. Each resource will provide all the tasks they need to do over the sprint (I like to get pretty granular, basically anything they need to do on the project in 8 hours or less blocks. (create graphic(s). create storyboards, gather content, etc). If a task takes longer than 8 hours, break it up into type, topic, etc. Trust me the effort is worth it to think about this for the first project for each role. After that, I tweaked and re-used tasks for successive sprints and projects so the time for this step was minimal.
  5. Lastly, define done for the Sprint. This could be a course reviewed and deployed to the LMS, this could be skeleton outlined and ready to add content, whatever. Take the time and think about it.

When ready to go, the Scrum Master should have a nice spreadsheet of goals, tasks/effort for everyone (including him or herself) for each goal.

Next is to just get started. Each sprint needs to have “Standups”. These are really short project meetings (10 to 15 minutes) where everyone on the project team gets together (virtually works well) and gives a status update. Personally, I liked twice or three times a week first thing in the AM. It’s not a discussion forum and should really be brisk.

The three questions the Scrum Master should ask are:

  • “Since last time we met, what did you complete?”
  • “what are you working on next?”
  • “Any challenges or obstacles?”

The whole team is responsible to always attend and participate, and everyone is responsible to help clear anyone else’s obstacles. This can be from helping with a task, finding a SME, to fixing a computer problem. The team has to work together.

At the end of each sprint, the team get together again for a “Demo”. This is simply a chance for the team to share the result of their labours. I would show a course, demo an eLearning module, walk through a storyboard, whatever. Each goal is presented. It should be short and sweet and is NOT intended as an opportunity for major feedback (it’s not a review). It should keep people motivated, ontrack and the juices flowing. It’s also very important the client is there if possible. Show them how you are proceeding and that the team is focused.

The “Retrospective” task is a chance for the team to have a lessons learned for the previous Sprint. As a timesaver, I often would have the Demo and Retrospective in the same meeting. (The client might not be appropriate to attend, depending on the project). The idea is that each sprint should get better. It’s not about the content or the scope items, so stay away from quality discussions, those shouldexist within tasks that ensure collateral review and feedback are occurring. This meeting is about the flow of the project and SCRUM activities. I recommend the Scrum Master send out an email to all team members before and ask they come prepared with any of the following:

  1. What went well (What we’ll keep doing)
  2. What did not go well (What we’ll stop doing)
  3. What are we going to do differently next time

Go around the table (or virtually), and gather the feedback. Put action items in place immediately. (for example, one of my “What did not go well”s: “I found the Sprint Planning took way too long, people should think about their typical tasks before and bring them rather than brainstorm in the Planning session.” This retrospective item turned our Sprint Planning sessions from 2-3 hours long to 30-45 minutes!!)

That’s it, then you do the next Sprint Planning session for Sprint 2 and continue through the steps until the project is complete. “Project completion” will vary based on a specific date targeted or scope completion and the same rules apply for SCRUM as any project management methodology in regards to the basic elements of Time, Resources and Scope (Where modifying one will impact the others).

This methodology can be done with very small teams, and is very nice for any project that will take more than a month. It will definitely keep the team focused and can capture tasks/participants from outside the learning team (invite your SMEs or for projects requiring technical integration, your IT resources!).

SCRUM is easy, can drive quality and milestones, has tons of online resources and really fosters a team environment.


About Andrew Ambrose
I am passionate about the learning longtail for formal and informal learning solutions, leveraging social media and networking technology for learning projects, innovation through mLearning, collaborative learning and applying solutions that fit within the learners personal learning environment.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: