Agile Principles, Good Practice for Any Project
April 3rd, 2003 by HalThe latest issue of Projects @ Work (March/April) has done a good job exploring the concern for collaboration on project teams. One article offers a summary view of an agile approach to projects. (This issue will be available online later this month.) Get your free subscription.
File Under Agile: Seven principles for keeping your software projects from bogging down, Ed Hartnett
In one page Hartnett offers a sense of what it is like to deliver a software development project on an agile basis. The description could apply to any engineer-to-order (design, architecture, or engineering) project. The article is written for project managers. Hartnett describes agile in terms of seven key characteristics:
- First things first
Understand as a team what is most important to the customer. Organize project work to deliver those functions first. - Release quarterly
Put the project on a regular cycle of delivering working product to the customer. - Test weekly
Validate the functions completed are actually working. Don't queue up acceptance or assurance activities to the end. - Refactor ruthlessly
Expect the architecture can be improved through time. Make changes to it with an eye towards doing it again. - Work collectively
Go out of your way to have people working together — on the same task — for all the work of the project. Pair programming is one example. People learn from each other in the midst of the work while catching flaws in design and execution and being more innovative. - Review religiously
Start reviews at the very beginning of the engineering effort. Keep attention on producing what the customer values. - Listen to the market
Changes external to a project can significantly impact what is of value and when it is valued. In extreme cases market changes could make the project valueless for the customer.
Agile methods currently operate at the fringe of acceptable practices for projects. In many ways agile is responding to what is not working (for whatever reason). Many projects are contracted in ways that require CPM methods, earned value reporting, and other classical methods. This does not preclude the team from adopting a disposition towards agility. The above seven characteristics read as good practice for any project.
Related Posts
- Comparing Lean and Agile Scott Reynolds writing at Tales from the SharpSide, "Lean forces you into a culture of quality. Agile is about interacti...
- Another Carnival What I like most about the Carnival of the Agilists is the self-organization for publishing. It's quite agile. Don't m...
- Cross Appropriating Agile Project Management Agile Project Management (APM) arose in the software world. The lean construction community has investigated APM to s...
- Better is the enemy of good I keep seeing people pursuing the best solution. In the process they delay receiving any benefit from the good solution...
- Combining Lean and Agile in Construction Agile and Lean theories were used to design the mechanical and electrical construction processes. The success of a lea...
April 5th, 2003 at 2:00 am
Damn, Hal…You beat me to this one. I just put the magazine down an hour ago and planned to point to exactly what you said about characteristics that could be good practice in most projects.
April 5th, 2003 at 5:20 pm
Frank,
I got lucky this time. Projects@Work just happened to be on the top of my unread pile.
Perhaps there’s more in common between Lean and TOC than has been identified.