Most people are familiar with the Agile Manifesto and its Principles developed in 2001 by seventeen people engaged in the IT (software) industry. Requirements take the form of a Vision Statement, Epics, Features and User Stories. Agile is much loved by those who like simplicity (does that include you?), high user involvement, high visibility of work to be done and work in progress, continuous team collaboration, self-managed teams, minimal documentation, face to face communication and very fast turnaround of deliverables in pre-planned, fixed iterations, creating a project cadence that raises expectations for frequent showcasing of completed work.
You may concur that sixteen years is a very long time in the software industry. I suspect Agile approaches are already baked into many methods. There has been talk and action for a few years now to make Agile scalable to deal with large projects, and hybrid methodologies have appeared that take advantage of the best of Agile and the best of traditional and iterative approaches. I believe there is wisdom in this thinking - something about not throwing out the baby with the bath water.
But Agile was clearly meant for software projects. Can it be used in non-IT projects?
A recent rather unscientific poll I added here seems to prove that one of the Agile frameworks, Scrum, is sufficiently pliable that it can be used outside the software industry. About 1/3 of the respondents (OK - only 21 responded, but you can change that), said they had used it on non-IT projects already and another third said they were planning to do so. And there are plenty of industry posts about this. One of which I am particularly fond is by InfoQ, where they highlight some of the challenges with using Scrum on non-IT projects and provide some clues about how to convert from technical software terms to business terms.
I believe any project can benefit from Scrum methods. Who would not want to reap the benefits of high visibility of work to be done, progress being made, frequent communication, an engaged team and client, and work being presented in weeks instead of months or years? Wouldn't everyone want work to be broken down into chewable chunks when it is possible to do so? Remember what our friend Albert said: "If you can't explain it simply, you don't understand it well enough."
Maybe it is time to create an Agile Manifesto for non-IT business projects. What might it look like? I'll go out on a limb here to take a stab at it:
Okay - so what changed? Not a lot, really. I changed "processes" to "complicated methods" and "tools" to "software tools" in the first line; "software" to "deliverables" in the second line; and I didn't change the last two at all.
I chose the word deliverables since it is generic and could represent a process, a document, a change in the thinking of a group of people, a new product line - you get it - a business-focused item.
So we might think much of the change would be in the Agile Principles. As they say, the devil is in the detail, which is what the principles start to address. Let's take a shot at modifying those to be more business-focused and less software-focused:
Once again, not a lot has changed. Software becomes deliverables and some of the more technical terms are converted to more business-friendly terms.
Have you used Scrum on non-IT projects? How did it work for you? Did your business users embrace it? Was the high visibility too much for them? Did the team manage themselves? How was the business user interaction? And perhaps most importantly, were business requirements satisfied?
Weigh in with your thoughts!
There appears to be a bit of split in the use of terminology in defining the scope of a project through the creation of the Work Breakdown Structure. Some seem to take an activities-based view, as evidenced by the template on this site called Project Work Breakdown Structure Guidelines, while others seem to take a deliverables-based approach, as found in PMI's Guidleine to the Project Management Body of Knowledge, which says that creating a WBS is the process of "... subdividing project deliverables and project work into smaller, more manageable components". Still others take a hap-hazard approach - don't worry - we won't talk about that here.
I have long held that a deliverables-based approach to project planning, executing and, most importantly, progress tracking and reporting is key to creating a mindset on a project that focuses not on what you have done (the "activity"), but on what you have produced (the "deliverable"). Have you seen status reports that focus on activities done last period, and activities planned for next period? Are they effective? How about status reports that delve into what was produced last period and what is planned to be produced next period? See the difference? One pulls you down into the whirlpool of things people did, often with no relation to why they did these things and what they hoped to accomplish. The other is much more concrete - what you produced in relation to the project WBS. You can even get very black and white about these things using the done/not done approach - a given deliverable is done, or it is not done - 0% Complete or 100% Complete. Of course, this doesn't work very well with ill-formed project schedules where a deliverable can consume many months or even years of effort. But if deliverables are concise, well defined and restricted to maximum effort levels, it works very well. Or you can consider breaking large deliverables into work products, the "done/not done" of which determine an overall %Complete, and track your deliverables that way.
If you consider a deliverable to be the output of an activity, why not flip it around and relegate activities to those things you must do to produce a deliverable? You can structure your project schedule around deliverables, and you can measure your progress based on the deliverables you have produced, or the portion of a deliverable you have produced. This ties in very nicely to Earned Value Management, but that is another topic.
How do you define the scope of your project? Are you an Activities-based or a Deliverables-based thinker? Do you measure progress based on what your team did for a period of time? Or on what they produced?