We have 5249 guests and 8 members online
Home > Articles > Current Edition > Agile Methodologies

Agile Methodologies

E-mail
Written by CMC Media Staff   
Tuesday, 07 September 2010 01:00
 Agile Methodologies - September  2010

Ocean

Many enterprises and teams that aren't already applying agile-lean product (system-software) development are interested in doing so. But many of these enterprises and teams aren’t completely clear about what agile adoption really entails. As a result, enterprises and teams that adopt agile-lean product development are often surprised by the amount of change that's required.

This edition of the Agile Journal answers frequently asked questions about agile methodologies and processes and what it really takes to "be agile-lean."

Alan Shalloway, in his article An Overview of Lean-Agile Methods, describes if you want to go Agile, you have a great many choices: Not just about which method to use, but where to start, whether to go top-down or bottom-up, and what should be the scope of your effort.

In my article Is “Agile Methodology” an Oxymoron and Counterintuitive to Agile-Lean Product Development and Craftsmanship?, I’ll explore the differences between a process and methodology. Then discuss why the word process or methodology is a wrong word to use to label and encapsulate agile-lean product (system-software) development. I will also provide guidance how a team can move forward inspired and motivated to uphold the team’s agile-lean product (system-software) development approach, continuously improve and confident in the security such guidance provides.

Ken Clyne, in his article The Risk Management Game: Shared Accountability Through Collaborative Risk Analysis, why release planning is more than just stuffing the highest ranked stories into iteration buckets.  To be meaningful the whole team needs to participate.  He goes on to make the case that lightweight risk management techniques are not orthogonal to an agile approach They can be help proactively address previously hidden concerns and the planning process benefits all-around from shared dialog on release-impacting risks.

Graham Parsons, in his article Integrating Performance Testing into the Agile Development Process, describes the importance performance testing plays in delivering valuable quality software and how performance testing traditionally requiring weeks to set-up can pragmatically and effectively be reduced to within an Agile project’s iterations.

Jean Tabaka, in her article “Dear Agile” – A Love Letter, she cleverly and insightfully introduces a technique to help folks convey an agile-lean adopter’s attraction to Agile and reveal where they are concerned about it as well.

Your agile buddy and editor,
Russell Pannone
Editor
Agile Journal


Featured articles...


An Overview of Lean-Agile Methods
by Alan Shalloway
Life used to be simpler. In the 90s, if you wanted to go Agile, XP was the route of choice. And then Scrum became popular. And it was not too long before organizations began to hit the limits of these approaches due to their focus on teams. And then it became apparent that lean principles could be applied to software and Lean Software Development and later Kanban were added to the mix. Now, if you want to go Agile, you have a great many choices: Not just about which method to use, but where to start, whether to go top-down or bottom-up, and what should be the scope of your effort.
Read More >>


Is “Agile Methodology” an Oxymoron and Counterintuitive to Agile-Lean Product Development and Craftsmanship?
by Russell Pannone
Is “Agile Methodology” an Oxymoron and Counterintuitive to Agile-Lean Product Development and Craftsmanship?

"And faith unfaithful kept him falsely true." - Idylls of the King, Alfred Lord Tennyson

It is inherently difficult to codify/capture and hence transfer within teams and organizations system-software development craftsmanship. Simply put, the “essence” of agile-lean product (system-software) development is not a codifiable process or methodology. Believing so and calling it such conveys the wrong message, leads to confusion, misinterpretation, disappointment and waste. As an agile system-software development craftsman you focus on being agile-lean within dynamic real-time given situations and contexts with a strong reliance on tacit knowledge[1]; you do not do agile, you are agile.

Read More >>


2

The Risk Management Game: Shared Accountability Through Collaborative Risk Analysis
by Ken Clyne
Release planning is more than just stuffing the highest ranked stories into iteration buckets.  To be meaningful the whole team needs to participate.   Lightweight risk management techniques are not orthogonal to an agile approach They can help proactively address previously hidden concerns and the planning process benefits all-around from shared dialog on release-impacting risks.
Read More >>

More articles...

Integrating Performance Testing into the Agile Development Process
by Graham Parsons
One of the key purposes and benefits of Agile development processes (“Agile”) is that they emphasize working software as the primary measure of progress. To ensure that the current state of the software is working, every iteration includes unit and acceptance testing. Many organizations report that, following the adoption of Agile, the quality of their released systems has been improved.
Read More >>


“Dear Agile” – A Love Letter
by Jean Tabaka
Dear Readers,
Writing or receiving a break-up letter can be fairly daunting or shattering, depending on which end of the letter your name appears. That letter puts a pretty hard stop to a relationship. It’s communicating detachment and finality. It can create a lot of pain whether intended or not. In contrast, a love letter is uplifting. The endorphins fly! Someone is revealing their attraction for you, and their hopes and wishes for a future with you.
Read More >>






Last Updated on Wednesday, 08 September 2010 09:28
 
Cialis

Agile Marketplace - Announcements and Special Offers

The Business Case for ALM Transformation
Are legacy systems holding your company back?  Breakthrough these technical constraints with an open and scalable environment that meets your unique business need to transform. There is no reason to be locked into an obsolete platform. The output of a number of recent transitions from legacy systems, this is practical white paper shares lessons learned and illustrates how guidance and enablement can pave the way for change.
Download this Whitepaper