For the last half of 2010, I conducted an “Introduction to Lean IT” class for new hires into AT&T’s IT group. In every class I taught, someone asked about “Agile” and if Lean IT is the same thing as Agile. While Agile is not lean per se, there are many similarities. Here’s a pretty good overview of the framework from http://www.paradigmaseminar.org/
What is the Agile software framework?
Agile software development embodies methodologies and practices that facilitate an evolutionary approach to software development. Agile also advocates developing software in shot time periods, i.e. 4 to 6 week cycles. In addition a face to face communication model is also advocated by Agile. Although there is nothing new in these methods the Agile Manifesto seeks to bring together all of the best practices that create software:-
The Agile Manifesto is based on a set of principles that include:-
What is new about Agile?
In practice there is little new in the components that make up Agile, many of the principles are embodied in previously defined Joint Application Development (JAD) and Rapid Application Development (RAD) techniques. What Agile brings is a consolidation and discussion around those tools and techniques that advocate a leaner more iterative software development process that does not rely on a complete set of requirements being produced at the beginning of the cycle. In addition Agile, as a discussion forum, positions some of the newer software methods within this leaner\faster environment. These newer development methods include:-
The definitions of the above can be found on the web, but the point of the list (which is not complete) is to convey the fact that there are many evolving software development techniques that seek to address the essential difficulties of the software medium (that is software is not tangible and is defined as abstract models).Agile is best thought of as a mindset or forum under which certain methods and techniques are understood in relation to each other and in relation to solving the problems of software development.Agile is not a cure all or one size fits all and at some level it is easy to criticize. At the very least, however, Agile brings a fresh look at the software development process and is a positive forum for software process improvement discussions.
Where does Agile work well?
One area where Agile methods work well is User interface design. It is very difficult to sit down with a user and produce screen shots or Mock ups that depict the final software product in a way that the user can make a judgment as to the usefulness of the screens (interface). A working prototype, of just the user interface (i.e. no functionality behind it), has proved to be the best way of obtaining what the user really wants in terms of screen design. In short the user is saying I can’t tell you exactly what I want but when I see it I will know. This approach to software requirements works well when there is flexibility within the solution, or when there are a large number of alternative solutions to the requirement.
Where does Agile not work well?
Consider a financial application that has to satisfy some legal accounting requirements or a stock control system that needs to calculate re-order levels in a prescribed manner. Software applications that require certain functionality to be implemented may be able to use some Agile methods but they will require the specification to be produced in full before the design and coding can start. For these kinds of applications the functionality of the software needs to be fully documented and understood by the developers prior to any coding. An iterative approach to implementation will work but only if the whole system functionality is specified otherwise the structure of the system would be evolving as the requirements where fully understood. In short Agile works best when there is choice over the solution or when a non-functional requirement (i.e. usability) is difficult to document.
No guarantee (or claim) is made regarding the accuracy of this information.