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)
