The Frog and the Octopus go to Snowbird
On February 11, the Frog and the Octopus will go to a celebration of the 10 years of the agile manifesto. As usual the Frog will remind everyone it can connect with that all software development projects are fundamentally the same, so there no need to get too excited about revolutionary new approaches, while again and again the Octopus will continue to say “all wrong, froggy, it all depends; it depends on the context, the context, the context!”:
Slides:
… on their way
The frog’s view point (=the elements that are common across all software projects I know).
Conceptual model of software project management: commonality
See more in this Frog’s point: conceptual model
The octopus’s viewpoint (the contextual factors that make the spectrum of software projects so vast and interesting):
Contextual model of software project management: variability, context
See more here: Contextualizing software development
And in summary: we need both to really understand software development project.
Note: we love to eat frogs and octopus. The ultimate fusion between French and Japanese food.
Philippe Kruchten 
The Horror The Horror! They both live in Water.
Hi, I read through the frog and octopus and found the model simple and yet very effective. We are doing both traditional and agile. Sometimes we mix and match. Recently, I am doing some reflection and blogging on development methodologies. Of course, one size cannot fit all but also be careful of neither fish nor fowl. No matter which size you select, very often, the frog is to be sacrificed. Ironically, the frog is the primary author of the codebase, on which the successfulness of the product depends.
In my last blog, I asked the question why a project can’t have multiple tracks. If we divide and conquer properly, the frog can stay on its own track while each arm of the octopus can has its own track. In software projects, it is the team structure. It is not hybrid-agile or Water-SCRUM-fall. Some teams are waterfall all the way through while some are purely agile. I believe that both extending agile by adding waterfall elements and forcing waterfall to adopt some agile practices are unnatural and unnecessarily confusing (sort of neither fish nor fowl).
(http://leungkm.blogspot.com/2012/10/the-new-team-structure.html)
I am relatively new to this topic. Any advices are welcomed.