Looking at the basics of Agile in more detail to help me apply it to general, non-development project management, the principles behind the Agile Manifesto are readily available for us to read and learn from.

Agile Principles, with Japanese Translation

First, to help my Japanese colleagues understand this better, I’ll translate these principles into Japanese here, under the original English from the Agile website. The Japanese translations and any mistakes therein are solely my responsibility.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicity–the art of maximizing the amount of work not done–is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

My Read of the Agile Principles

In my article about Reading between the lines of the Agile Manifesto, I made some points about what the Agile Manifesto seems to be saying or indeed not saying. The above-cited principles behind the Manifesto are indeed reinforcing what I thought originally. Here’s a couple of points I think are relevant to mention:

Lazy or Sloppy Need Not Apply

Nothing in the principles suggests an anything-goes attitude is OK, but I can see why one might mis-interpret these statements. I think rather, that in return for the trusted position and self-organization of processes and methods, a high level of professionalism and technical skill is implied. I’d venture to say that an inexperienced team might easily fail attempting Agile, because decisions need to be made quickly and effectively.

“Continuous attention to technical excellence and good design” implies that the team is capable of indeed producing technically excellent software and good designs, and that they know what those are. I’m quite sure that is not the case for every team, and that certain self-organizing teams are quite capable of happily producing poorly-architected, weakly-specified, and ill-designed software.

Business and Technical Members, Face to Face

In the principles, the emphasis is on face-to-face meetings, and on getting the business and technical members together daily. This implies a daily “scrum” like meeting, as well as the key ability to be able to communicate between the two sides. To do that well, experience is required but I agree wholeheartedly that it’s a must. I wonder, are technical teams ignoring the need to continually bring in the business side? That’s critical.

Results are King

Working software. This is the keystone, and it’s biased toward results and results only. This is not to say that the method you use to get from requirement to working software is not important. Rather, it’s an admonishment to not spend too much time writing volumes of documents, and to get down to the main point. Giving customers what they demanded quickly is much better than activities that don’t really add value.

Fight the Power

I can imagine that the principle of allowing teams to self-organize is interpreted in an extreme way by some Agile practitioners, and opposite from what a typical “chain of command” top-down management style organization would demand. That said, given the right “motivated individuals” and proper mentoring from a benevolent coach-like figure, and given time, even somewhat inexperienced teams can succeed. Ignoring the point about the right environment for success being required, at your peril.

Bring us your Changes

This one is interesting to me, because many years ago when I taught the “IBM” project management method (basically waterfall with a little Boehm spiral sprinkled in by me) to the UBS IT department here in Tokyo, there was a point the client wanted me to make which was that “changes are evil”. Seeing many projects since then fail, when trying to define requirements and then disallowing changes, I believe the statement in the Agile principles about bringing on the changes is perhaps the starkest and most important of the differences between Agile and, say, waterfall.

That summarizes my current feelings about the Agile principles, but it’s pretty obvious that there are gaps in what the principles do not specify or leave to the team to specify. For those, it might be necessary to turn to other thinking processes like GTD or Lean, to fill in some of the blanks. Please contact me, as I would love to hear from you, or post your comments in the blog post introducing this article.

Rick Cogley
Japan, Winter 2009

Previously Published Here