On the Principles behind the Agile Manifesto

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.
短い期間に重点を奥が、2、3週間から2、3ヶ月のスパンで、正しく働くソフトを度々と提供する。

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