visible artifacts

By: Chris Malek

Jan 02 2009

tags: screening_exam

Category: Articles, Exam Essays

2 Comments »

Since 2000, agile software methodology has been much discussed and adopted by firms.  Describe Agilism.  Give an overview of the process.  Show when it is indicated, and counter-indicated, How does agile software methodology impact business?

Agile software methodology is not one methodology but a set of methodologies that share common characteristics.  According to Alastair Cockburn, agile methodologies are fundamentally about closely aligning software development to business goals at the time that the business still values those goals, especially in contexts where those goals may be changing.  Examples of agile methodologies are Extreme Programming (XP) and Scrum.  Agile methodologies are iterative and incremental.  By iterative I mean that when using an agile methodology, one produces regular working versions of the software being worked on, presents those working versions to someone for testing and feedback, and use that feedback to adjust our design and implementation accordingly.  We thus converge onto the final product in this manner.  Each time we produce a working copy is called an interaction, and iterations in agile methodologies are typically fixed length and short (1-3 weeks).  By incremental I mean that we don’t start out our software project by implementing every requested feature.  Instead we build a few features in each iteration, thus incrementally building the final product.

Agile methodologies are low ceremony, small size methodologies that emphasize user participation in the development project and small, co-located teams.  They are designed to embrace change both in software requirements and the development process itself through the use of feedback.

By user participation I mean that agile methodologies all incorporate users heavily into the development process. Agile methodologies have some equivalent to RUP’s use case (descriptions of something a user will do with the system to achieve a specific goal), although these are all typically much lighter weight than RUP use cases.  They try to put even more power into the hands of users than RUP does.  XP, for instance, replaces the RUP use-case with the user story, a short (two paragraph) story of a user achieving a goal via the system written by a user in the user’s own words.   Contrast this with RUPs use case which is written by the developer in the developer’s words with input from users.   Secondly, with agile methodologies users may be expected to participate in many stages of  development.  XP requires a user representative to be effectively a member of the development team and be collocated with the team.   This so that that representative can provide immediate feedback throughout the design and implementation parts of an interation; in RUP, by comparison, we have user participation only in the beginning and end of the iteration.  In waterfall, user participation occurs only during inception and requirements gathering.

Agile methodologies use small co-located teams as a fundamental matter of methodology.  Typically, these teams are all situated within one large room with partitioning between team members (cube walls or structural walls, I mean).  This so that information and knowledge can flow freely between team members, and so all team members can be informed about all aspects of the project through ambient information transfer.  The room environment is set up with many whiteboards and display areas which are used for informal team brainstorming, design sessions and for displaying persistent information related to the project (information radiators).  The reason for all this is that agile methodologies trade intermediate work products (documentation and specifications) for team synergy, saying such work products detract teams from achieving their real goal: producing working code to offer up for review by the users.  Co-locating the team in such an environment of rich information flow is a compensating mechanism for the coordination functions that the intermediate work products serve in other methodologies.   We’re setting up an environment which encourages good flow of tacit knowledge and a high level of conceptual consensus without resorting to intermediate work products.

Agile methodologies embrace change.  Agile methodologies expect requirements to change, and so have mechanisms built in to accommodate that.   As I’ve said above, embedding user representatives into the project team allows continuous feedback throughout the design and implementation.   Importantly, a working version of the product is produced at the end of each iteration, is tested by the users and feedback from the users is incorporated into future iterations.   Some agile methodologies incorporate rigorous testing procedures, dictating unit testing (pieces of code which test a function or method against expected results) for all code.  Pervasive unit testing allows developers to change existing code with more surety, because they’ll know when their change broke something they didn’t expect.   In addition to expecting the software to change, agile methodologies expect developers to change the methodology itself!  At the end of each iteration, team members reflect on what worked and what didn’t and attempt to change procedures for the better for the next iteration.

Agile methodologies are best used in case where requirements are not stable or are not known in advance (everyone needs to see some working code in order to see where to go next).  They are especially applicable to new product and ideas.  They have been used with success on many web development projects.   Agile projects should be faster than waterfall and RUP in converging onto a final product due to the theoretical high conceptual consensus and tacit knowledge transfer among team members, and not spending time producing intermediate work products.   Shorter development time can help to cut project costs, even though the agile team members (being expert generalists) may be expensive.

Agile methodologies demand expert developers who are generalists.   They must be expert to be able to flourish in this environment of changing methodology and requirements, little documentation and  the need for a generalist skillset.   Developers need to be generalists because typically, all team members participate in all aspects of the project: requirements gathering, design, implementation and testing.  As such, agile methodologies are not suitable for junior developers.  Secondly, agile methodologies demand quite a commitment from the users; if you can’t such a commitment then agile methodologies might not be suitable for your project.  There is a large risk associated with agile methodologies due to their disdain for documentation: knowledge transfer.  Agile methodologies are a creational, intended for creating new software and as such does not include a software maintenance component.  Handoff to a maintenance team can be difficult, and if the agile team is disbanded, knowledge of how the software was designed may  be lost.  They are not indicated for projects of high criticality, where requirements need to be specified in great detail and must be implemented with few or no bugs because the cost of flaws are high: think medical instruments.  This same lack of documentation makes agile methodology a hard sell in regulated environments – banks, for instance – in which Sarbanes-Oxley requires clear audit trails and project documentation.

Agile methodologies emphasize the quality and time aspects of the quality/time/cost triad.   Due to their iterative and incremental nature and their expectation of change, estimation of agile projects is difficult. Given qualified staffing, due to the low ceremony nature of these methodologies they are very suitable in business environments where bringing innovative products to market quickly gives competitive advantage.