Using Agile with Non-Software Projects

Part of the reason for writing my last blog was to show the essence of Scrum and how it could be extended to other types of non-software projects.

Agility is the ability to both create and respond to change in order to profit
in a turbulent business environment. - Jim Highsmith, Agile Project Management

I read a fun interview with Alistair Cockburn about how he used Scrum to build and add on to his home a few years back. Obviously this is a non-software project and was very successful. The main portions of Agile that he took advantage of were:

• Work Incrementally
• Willingness to make changes on the fly as needed
• Open Communication
• Feedback to help guide next steps
• Daily Standups
• YAGNI - "You Aren't Going to Need It" - do only what's needed, change later if necessary
• Time and material contracts
• Venture Capital Funding (funding as you need it)
• Customer Involvement and steering
• Small wins
• Process miniature
• Developing Collaboration and Trust

Agile Practitioner and Coach Robbie Mac Iver used the concepts of Agile to manage a complex business process in the supply chain domain. Some of the tenets discussed there relating to how they used Agile were mentioned before.

• Focus the team on the real business value
• Clarify the work streams and the alignment of the team
• Enforce what “done” means
• Make progress and issues visible (sometimes “painfully”)

Iver also mentions in his About section on his website that he belives that using Agile for business really provides three important deliverables.

• Effectiveness - Teams are working from the top of list of work that the business leadership has characterized as the most important, the highest priority. As these solutions are delivered, the business sees immediate gains and doesn't have to wait for "everything" (stuff that could have been planned for with longer planning) to be done.
• Information - The business learns very quickly what works and what doesn't. Information is discovered quickly and decisions can be made rapidly without significant loss (as compared to traditional projects).
• Control - The business is given more control because they can see quickly the state of situations and make decisions about which direction to go. They can work on projects that actually produce value, not just projects that might produce value, and stop whenever they have made "enough" progress to provide that value.

<><

References:

• http://www.agileadvice.com/archives/2006/06/interview_with.html
• http://www.swdecisions.com/documents/WP-ScrumForNonSoftware.pdf

Agile Essentials

Agile is a process framework most typically used in software development projects ideally suited for projects with high uncertainty. However the basic principles of Agile can apply to just about any type of context. The founders of Agile have developed a "Manifesto" that describes the basic tenets of Agile.

The four tenets are as follows*:

1. Individuals and interactions over processes and tools
2. Delivery of value over comprehensive documentation
3. Customer collaboration over rigid contracts
4. Responding to change over a detailed plan

Some other aspects of Agile are:

1. Early and continuous delivery of value
2. Adaptive insted of predictive to give maximum flexibility
3. Visibility for good and bad
4. Inspect and Adapt frequently
5. Become iteratively better
6. Result driven tasks
7. Face to face communication
8. Cross disciplined, motivated, empowered teams
9. Sustainable pace
10. Continuous attention to Quality

Agile Scrum (a particular flavor of Agile) arose from proceses that were designed to increase speed and flexiblity in the delivery of business or social value. It is a collaborative and change embracing method that cross-functional teams use to produce high quality deliverables through iterations of work time.

Scrum itself is specifically a lightweight process framework that is designed to focus the teams on delivering the highest priority items first. The fact is, that most projects or programs spend much of their time attempting to deliver some less-than-well-defined artifact, only to find that by the time it's done it's no longer relevant or needed. Scrum defies this by demanding that the highest priority items are addressed first, exposing issues, forcing the understanding of risk and dependencies, and in general bringing visibility to the team and the rest of the organization it lives in.

Read more information about the details of scrum. How would Scrum apply to your context?
<><

References:

1. http://www.agilemanifesto.org/
2. http://www.scrumalliance.org/articles/22-scrum-delivers
3. http://www.mountaingoatsoftware.com/scrum

*For the purposes of abstracting Agile out of the software world I have changed the wording slightly from the original, but it carries the same connotations (1).
* The focus on the first half of the statement doesn't mean that we don't care about the second half and need to consider them.