agile

As professionals, we are always looking for ways to improve the way we work. We encounter ideas and methods that we start to implement, but often we fail. Does this sound familiar to you? How should you avoid this? You should focus on implementing the changes that have the highest benefit versus effort ratio for you and your team, or as the title of this article puts it, the low hanging fruit. To facilitate this, we suggest the following steps: Make a change backlog, Find your low hanging fruit, Establish a raiding party, Establish a success story, Go to war, Celebrate! And Start over.

Amr Elssamadisy presents one way to share our knowledge that is more specific than full methodologies and processes, more general than war stories, and will help new agile adopters get beyond the mantra "It depends!"

Every system has an architecture, even systems developed using agile methodologies. Whether you attempt to define that architecture up front in detail or whether it emerges over time is up to you. My experience is that most agile teams follow a strategy somewhere between these two extremes. That strategy, combined with proving your architectural ideas as soon as possible through working code. This article summarizes a collection of strategies for addressing architectural concerns on agile projects and discusses how such strategies can be applied to scale agile methods to large development efforts.

Conventional wisdom is that complex projects involving large groups of engineers can not benefit from the application of Agile techniques. Certain Agile practices, when properly used, can benefit even relatively large development projects with large teams. What's even more interesting, these practices can be introduced in "mid-stream" with little preparation to large teams of "old school" developers. These developers may initially resist the methodology, but the Agile practices still win people over and bring tremendous results in productivity, product quality, and team morale in a very short period of time.