I have a client who uses lean and agile-like processes outside of IT on research and development projects. They have been doing this for a number of years to help optimize constrained tools (drilling platforms) and resources (specialist inspectors). They like the agile concepts of prioritizing based on business value, working in short cycles, expediting rush jobs and frequently validating results and adaptation.
Recently they asked for help with some improvement initiatives that use multi-disciplinary teams to investigate and improve cross-department processes. These groups are staffed by senior engineers who volunteer to help make improvements, but the work is low priority and their time extremely limited. They are also geographically dispersed. Obviously that creates problems for agile practices like daily standups if team members get on average of two to four hours per week to contribute on an initiative.
At first I saw lots of challenges--agile promotes dedicated teams (co-location where possible), daily conversations with business stakeholders, etc. These groups had none of those things, yet three months later they were pleased with the successes they had. It seems when you are trying to coordinate the work effort of distributed, low-availability resources, the structure and visibility of tasks that agile brings is a great strength.
This somewhat counter-intuitive application makes more sense when you consider how such improvement committees traditionally function. Historically, similar work groups had faltered and failed to deliver benefits. The company was mature enough to look for inter-departmental improvement opportunities, but because it was no one’s full-time job (and they spanned departmental jurisdictions), work started but then failed.
Often, tasks waited on someone for input; one week, people had no time to work on the initiative and so had nothing to report in the way of progress. Traditional Gantt chart-based plans became hopelessly out of date, and priorities and benefits were soon lost from sight. When everyday work is within your span of control and you have what you need, a back-burner improvement initiative that is waiting on Bob in Planning (or is it still with Mary in Finance?) quite quickly gets pushed so far down your To-Do list that it never gets worked on.
In contrast, some basic agile-inspired ideas brought a number of benefits. A prioritized backlog of work was created focusing on the “low-hanging fruit” (quick, low-effort, high-value items). People were encouraged to volunteer for tasks they could complete rather than be assigned work. This had the dual advantage of setting people up for success by allowing them to choose items they felt they could realistically deliver, while also encouraging them to make a social promise to deliver these items in the presence of their peers (which is much more effective than assigning work to people).
Bi-weekly standup reviews were completed by video conference. The short, 15-minute commitment made them easier to schedule than a traditional status meeting. While daily or even weekly standup meetings would have communicated progress more often, they would also have resulted in more “no progress this period” responses for when people had not had time to contribute.
While bi-weekly reports on progress (or lack of) might be enough to keep time-constrained people informed, it is not acceptable for reporting impediments to progress--so an agreement to inform the project coordinator (aka Scrum Master) at the discovery of any issue was made. This worked well, and if anyone did report an impediment at the bi-weekly standup meeting, they were reminded to inform the coordinator of such issues when they first arise in the future.
Actual progress was compared to forecast progress and release plans updated. Velocity statistics were calculated and displayed on the project’s SharePoint site that was used to coordinate work, display the backlog and predict the completion date. Every other month, participants would get together for a review and retrospective.
My expectations were low for how a geographically dispersed team would function on a project where the work is effectively everyone’s lowest priority (and people work on it for maybe a couple of hours a week--if they get some free time). However, compared to a legacy of failed initiatives and fizzling commitments, the results were remarkable. (I guess against a backdrop of failures, progress always looks good.)
The client was happy, and once the results of these inter-department collaborations began to deliver rather than fail two things occurred: First, more ambitious projects were conceived since the original projects were no longer good-willed but now doomed initiatives; second, people started getting time assigned for their involvement since they were now delivering value. With improved visibility and assigned time, more work got done--and bi-weekly standups were replaced with weekly standups.
It is no silver bullet; work still takes a long time to do when using a part-time, volunteer, distributed workforce. There are delays and issues as people wait for input, but this is better than the days of no credible plan, a lack of focus and general confusion.
Purists will say this is not agile, and that’s fine--it does lack many of the empowered team and collaboration elements agile methods recommend. However, backlogs are more resilient to change and delay than Gantt charts, which tend to get abandoned when they become too far out of date. Task boards showing work done and work remaining are effective tools for intermittent workers; they quickly bring people back up to speed on what has been accomplished and what still needs doing. This is very helpful when task switching between projects.
Time and spatial fragmentation slows project progress and usually prevents people from achieving that sense of “flow” when they are immersed in productive work. However, if that is your reality, consider some of the lightweight, visual controls offered by agile and Kanban. While sourced in the dedicated, co-located team world, they can be useful alternatives to the email badgering of checking progress that characterizes many part-time initiatives--and only really ensures people find the whole experience miserable and then don’t volunteer again. Instead, agile’s high visibility reports keep contributors abreast of progress, better enabling them to spend 30 minutes contributing rather than finding out where people are up to.(Note: This article first appeared at ProjectManagement.com here. Mike Griffiths is a project management consultant focussing on pragmatic agile and lean techniques. His blog is www.LeadingAnswers.com)