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 13, 2006
Mitch Lacey is a Program Manager at Microsoft in Redmond, with a passion for Agile software development. When appropriate to the work, he loves to help a team get fully agile - practicing XP and Scrum, absorbing and living the principles. Lacey recently blogged about the XP core practice of "Sustainable Pace", which has also been adopted by ScrumMasters and other Agile practitioners, because Agile work, when done in a disciplined, creative way, tends to be very intense.Lacey goes on to say: "I used to get hung up on this and even today I continue to see others getting hung up on this. I used to think that I had to work at a sustainable pace and that I would fail if I worked overtime." He now understands it differently, and makes some suggestions on determining the value of overtime (rather than rushing ahead and doing it for the usual reasons) in his MSDN blog entry called Breaking the Rules of Agile - WorkingExtreme Programming teams are in it for the long term. They work hard, and at a pace that can be sustained indefinitely. This means that they work overtime when it is effective, and that they normally work in such a way as to maximize productivity week in and week out. It's pretty well understood these days that death march projects are neither productive nor produce quality software. XP teams are in it to win, not to die.
More features will always bring more revenue, more customer satisfaction, other good things. Therefore there is always pressure for people to work harder, longer hours. This is demonstrably a Bad Idea. Here's some evidence, and some ideas about how to know if pressure is too high.and along the way he covers topics such as these:
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.
Isn't feedback based iteration supposed to expose problems , so the team can find a way to fix a problem or re-adjust estimation?
Yes, Stephane, I agree with you. The inspect-and-adapt cycle is a good place to react to such problems and head them off. There really isn't any excuse for a deathmarch on an Agile team that is doing retrospectives.
But I've also seen teams that don't perceive overtime as a problem so it doesn't come up in the retrospective. Or perhaps there is organizational pressure from outside the team, and they can't shake the feeling that they should comply, so it gets swept under the carpet.
These teams need some leadership - someone (a team member, a scrum master, a manaer) who encourages them to discuss it, as the author suggests. This can reset expectations and reveal options that can then be dealt with over time in retrospectives.
What do you think?
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.
Oren Teich 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