Injecting Agile into Group Projects (part 2)

With its roots in lean thinking as pioneered by Toyota, the Agile Manifesto expresses a project management philosophy and values that have underpinned software development for the last 30+ years. In my opinion, a few simple changes to that canon make it just as applicable to a wide variety of other group endeavours, from e-Learning development to, as in my case, students in a group project environment:

It is important to underline that our “leftist” manifesto’s values apply to both the group process (how it will deliver) and the assigned project (what it will deliver). The first is controlled by the students, the second by the instructor.

Assignments should therefore be constructed to maximize opportunities for students to experience the items on the left. Is a process or tool hindering team interactions? Then it should be modified or replaced. Does the project itself encourage meaningful interactions? Are students required to apply their learning, not simply to regurgitate facts and figures? Are expectations and how deliverables will be graded (e.g. rubrics) clearly communicated? And, finally, are some tasks ambiguous enough to require analysis and a choice of paths to success? Will students have an opportunity to respond effectively to changing priorities, or is delivery predicated on a single, linear step-by-step plan?

Let’s start by focusing on process. Picking up from our last post, how can a Kanban board help a team put our Agile Manifesto into practice? Well, for one thing, it is very visual. Brain candy. In this case, our board is a simple 8-1/2″ x 11″ sheet of paper with three columns. Every task is on its own sticky, and higher priority items are placed at the top of the “To Do” column. Who is doing what (initials on each card) is obvious as tasks are moved to the “Doing” column only once work on them has actually started. Everyone can quickly see all the tasks to be completed, and what has already been done. When unforeseen problems arise (Oh no! Sam’s sick and he’s got the spittoon!), stickies can be moved around to reflect changing priorities. And what can be more comforting than seeing the “Done” column grow (or worrisome when it doesn’t) as the other two shrink? Not only is the whole process refreshingly simple to understand, it supports one of the other energizing features of Agile, self-directed teams. Members don’t need to be told what to do. Outstanding items sit prioritized under “To Do” ostensibly crying out, “Grab me”, to anyone who is idle and able.

Nicely satisfying the first and last precepts of our manifesto, such highly visible and clear workflow supports focused and highly adaptive interactions. Team members confirm and prioritize tasks as a group up front, then divvy up responsibility for getting them from “To Do” to “Doing” and “Done” over the life of the project. Tasks can be easily re-prioritized by moving them up or down the “To Do” stack, or even moved back from “Doing” if necessary. Perhaps more importantly, new unanticipated but critical tasks can be injected into the flow at any point, further supporting adaptation to changing requirements.

While Kanban can nicely facilitate the mechanics of group work, it offers little to projects that are do not lend themselves to collaborative effort. Our next posts will consider the elements that transform an assignment into a reasonable group project.

Opting for Brain Candy (part 1) <<Previous post    –    Next post >> Smooth (part 3)