Rails in the Large: How Agility Allows Us to Build One Of the World's Biggest Rails Apps
Neal Ford shows what ThoughtWorks learned from scaling Rails development: infrastructure, testing, messaging, optimization, performance.
Tracking change and innovation in the enterprise software development community
Posted by Deborah Hartmann Preuss on Sep 26, 2006
Siddharta Govindaraj is a software engineer with a Singapore startup, who has noted how Agile is being adopted by more mainstream enterprises, and has blogged on 5 dangers when adopting agile processes - and what to do about them. In a separate post, Simon Baker, taking up the theme, relates these dangers to his experience as an independent agile coach and consultant in a large organization.Like any work, it has its ups and downs. The ups generally relate to the project, the people I'm working with and not having to compromise on our team's use of Extreme Programming, Scrum and Lean thinking. The downs are moments of annoying frustration when we encounter the wider program and its organisation, bureaucracy and dysfunction.Baker goes on to relate Govindaraj's "5 dangers" to his own experience in his blog entry: Relating to the dangers when adopting Agile, where he shares some anecdotes that support Govindaraj's observations and suggestions.
Agile Development: A Manager's Roadmap for Success
VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.
The title of the article shows another danger. We should be talking of agile approaches rather than agile processes. Valuing the process over the people or the interactions is explicitly not agile.
Oops! there's another of my touchstones for people who really 'get it' blown (if folk read this, that is...).
Similarly, "Learn about agile"; good advice, but to follow the manifesto, 'doing' is more value than 'learning'.
Similarly "Incomplete Implementation"; tailoring the process is inevitable, because no 'out of the box' approach provides a complete process. This is deliberate; the freedom to choose how we bridge the gap gives us the flexibility that underpins agility.
Don't let these minor criticisms taint the good aspects of the article.
The top piece of good advice is missing - ensure you have some way of finding out rapidly when you go off track (as you will, repeatedly). Advice from a good agilist can help in this; a robust, tight iterative "Inspect and Adapt" cycle coupled with blame-free openness can help. Using both would be good.
the article is okay, but is not really touching on the real problems and dangers of agile...
At a high level I believe agile has some serious consequences including
-a serious impact on the environment
-a threat to world health
-an offense to anybody with any sense of fashion
Feel free to take a look at my rationalization for these comments here.
Sincerest regards
Jeff Anderson
my blog on agile development
Neal Ford shows what ThoughtWorks learned from scaling Rails development: infrastructure, testing, messaging, optimization, performance.
Stuart Halloway discusses Clojure and functional programing on the JVM in depth, and touches on the uses of a number of other modern JVM languages including JRuby, Groovy, Scala and Haskell.
Orion Henry and Blake Mizerany talk about the technology behind Heroku and the benefits of the new add-on system.
Chris Riley presents security issues threatening service based systems, examining security threats, presenting measures to reduce the risks, and mentioning available security frameworks.
This talk investigates technical issues encountered when moving to an Agile process.
Don Box and Amanda Laucher present “M”, a declarative language for building data models, domain models or external DSLs. Don Box's demos show some of M’s features and latest changes of the language.
It is four months since the SOA manifesto was announced; InfoQ interviewed the original author’s to get insight into the motivations and the process behind the initiative.
This article explains the impact memory barriers, or fences, have on the determinism of multi-threaded programs.
2 comments
Watch Thread Reply