I’ve been banging on about increasing agility in the way we run our projects for quite a while. Some of the key reasons are;
- We are working in small silos, which are interlinked. So an agile approach enables the creation of self-organizing teams by encouraging co-location of all team members, and verbal communication across all team members and disciplines that are involved in the project. This also puts the customer at the centre of the process, as well as meaning they have a very active role.
- For most of the projects we work on are … the problem cannot be fully understood or defined, so focusing instead on maximizing the team’s ability to deliver quickly and respond to emerging requirements is better than simply creating a long, inflexible linear project plan.
We’ve had a few success in e-learning with an agile approach.
The first is the QR Code’d assignment cover sheets which is about to be rolled out as an institutional service. This involved the rapid development of the software against a broad (high level) set of requirements.
The second is the user needs gathering exercise (which would be the input into the development) for the Moodle4iPhone project. This exercise clearer identified the requirements, and mapped these requirements to the existing product. An output (deliverable) would be what we would need to enhance the tool to meet our users needs and the selection of a power user group to be part of the developments (short sprints).
This model has been repeated with the requirements for assignment submissions. We are clearly is a position to compare need with Moodle 1.9 & 2.0 to identify if we needed to develop the assignment tool we could build the case, and prioritise.
A similar success story is the involvement of Hannah South as the user representative for the Moodle TurnItIn integration.
Of course, me being a hard man to please sees a few problems with all these developments, the man one being they all overlap, it becomes very difficult to unpick where we are with the project, and to bring closure. For instance, the QR Code work was small iterative changes over a long period which then competed with other projects and works. This final point is a clear problem.
So, I’m going to force Vic and James (and the rest of the team) to work in a more structured “agile development” approach for the Mahara pilot, and the next wave of QR Code Submissions. This new beginning will start after the first week of August when the Moodle work is complete.
The aims are to get us to work in an agile development way (building on the successes of the last few months) but have more discipline to deliver stuff within clear development windows. Also to apply the model to a non-software development projects (the principles should transfer very easily).
So if we where to apply a scrum-esk methodolgy to the Mahara project, what might it look like?
Roles (pig roles)
ScrumMaster (or Facilitator): Scrum is facilitated by a ScrumMaster, whose primary job is to remove impediments to the ability of the team to deliver the sprint goal/deliverables. The ScrumMaster is not the leader of the team (as the team is self-organizing) but acts as a buffer between the team and any distracting influences. The ScrumMaster ensures that the Scrum process is used as intended. The ScrumMaster is the enforcer of rules. A key part of the ScrumMaster’s role is to protect the team and keep them focused on the tasks in hand.
Team: The team has the responsibility to deliver the product. A team is typically made up of 5–9 people with cross-functional skills who do the actual work (design, develop, test, technical communication, etc.).
JAMES, VIC & NITIN plus wider user testing team (D4LLL, PHARMACY, PGCAPP – these will be the chicken roles)
Product Owner: The Product Owner represents the voice of the customer. He/she ensures that the Scrum Team works with the “right things” from a business perspective. The Product Owner writes customer-centric items (typically user stories), prioritizes them and then places them in the product backlog. A Product Owner can be a member of the Scrum Team but cannot be a ScrumMaster.
Why would Vic being the Product Owner and not the Scrum Master given she’ll get named responsibility for the project? The answer is … as the project (pilot) manager she’ll be liaising with the pilot user group, the vendor (ULCC), she’ll be drawing up the broad pilot aims and evaluating if these have been achieved. Therefore, she’ll be very user focussed and the perfect person to draw up the user stories. While, the scrummaster just makes sure things are done.
A workflow might be …
June – get software, Vic tries it out
July – creates a number of user stories (1-2-1) meetings with chickens, then gets them together to prioritise any requirements for stuff being developed; i.e., technical integration, design and themeing, system back ups etc., support material (FAQs),
August – 2 week sprint to deliver the prioritised work. Includes, sprint planning meeting etc., The work is undertaken by the pigs. The scrum master brings it together as a sprint retrospective meeting. Andy will need to book 2 weeks out in all parties diaries. Once the work is allocated, no other “development” work can take place. Once the work has been spec’d, with this project there should be lots of space to fit other work around the edges. At the end of the session, Vic will take this back to the users and identify further requirements for the next sprint. Finally, a date will be set for the next Mahara sprint.
The approach will be repeated for the QR Code Submission work, except the roles will be changed. Andy will become the Product Owner, and Vic or Nitin the Scrum Master.
The question is, what are we trying to achieve? The aim is relatively simple, it is to take the next step along the road of getting us (the team) comfortable with the agile development approach and the discipline which needs to come with it. The rationale being, Moodle Development Plan 2011, Moodle 2.0 upgrade and ARS data visualisation project will be managed through this approach. So bye bye long, linear, project management where the users are relatively detached from the project and feel like silent bystanders. Welcome, agile development focussed on user voice / needs.
Oh, SAMIS integration I hear people scream … this is a big project, how is this going to work in the new approach? Well, it will work perfectly, get the product owner to gather the user requirements, compare with the current integration, then fix a sprint (4 weeks), with two ESSD people, and BUCS reps and do it. No distractions, no other work, only stop if moodle falls over. This will be over 250 person hours on the project – enough to complete the integration
Moodle 2.0 upgrade? Well just plan the project as a number of sprints based around technical and non-technical themes. Lots of 2-4 week sprints, downtime, and next sprint will get the work completed over the time period. The key is people working together as a team effort, not allocating work to one individual working in isolation/