Becoming Agile 193
IraLaefsky writes "The appropriately titled Becoming Agile: In An Imperfect World by Greg Smith and Ahmed Sidky offers a realistic path to the family of Agile practices which have become prevalent in software development in the last few years. This family of approaches to software development has been widely adopted in the past decade to replace the traditional Waterfall Model of software development, described in a 1970 article by Winston W. Royce 'Managing the Development of Large Software Systems.' The Waterfall Model stressed rigid functional and design specification of the program(s) to be constructed in advance of any code development. While the this methodology and other early formal tools for Software Engineering were infinitely preferable to the chaos and ad-hoc programming-without-design practices of early systems, these first tools ignored the fallibility of initial interviews used to construct initial design and often resulted in massive time and cost overruns." Read below for the rest of IraLaefsky's review.
The Agile methodologies which are described in this text stress an iterative approach to software development, with the continuous involvement of users (or user surrogates). These iterations consist of several week periods (to at most two month intervals) where a concise partial design requirement, story, is translated to a complete executable version of the program which can be demonstrated to users, for their immediate and anticipated criticism and controlled feature addition. These practices have undergone various codifications since the Agile Manifesto of 2001. Among the more popular Agile Menthodologies are Extreme Programming (XP), Crystal Clear and Scrum.
| Becoming Agile: In An Imperfect World | |
| author | Greg Smith and Ahmed Sidky |
| pages | 408 pages |
| publisher | Manning |
| rating | 9/10 |
| reviewer | IraLaefsky |
| ISBN | 1933988258 |
| summary | provides the tools to introduce and adapt agile practices in a variety of corporate cultures |
In describing these development methodologies this practical handbook takes an approach sorely needed in descriptions of Information Technology (IT), it assumes that the purchaser is considering employing the technologies described within the context of a real corporate environment with existing strengths and limitations, an existing approach to the problems addressed, and cultural biases concerning the adoption of new technologies. This approach enables the book to be used as a virtual consultant, taking the experiences described in a case study based upon the authors' advisory experience, and the test of organizational readiness for adoption and needs for customization of the technology as true guideline for introducing these practices in culturally and technology appropriate fashion. During the mid 1980s I served as an internal consultant at a large insurance firm, at the time we were considering the introduction of Expert Systems methodologies into the IT organization. I purchased several handbooks which were intended to introduce this new from academia technology to companies in the financial industries. Most of these books did an adequate job of describing the nature and basis of this technology to IT and Business Analysts trained in existing technology. But, all of the available books failed to chart a path for an IT organization with traditional development practices to successfully migrate to the new technology and appropriately translate this technology for business management. Becoming Agile, introduces a new effective method for describing the risks, benefits and appropriate adaptation of a radically new technology to organizations with existing successful and unsuccessful software development practices and a particular business culture.
Important features of this guide include the Sidky Agile Measurement Index (SAMI) which provides guidelines in moving your particular organization to Agile practices, the non-religious presentation of multiple Agile methodologies and approaches (specifically XP and SCRUM), appendices on organizational readiness assessment, phased development within the Agile context, an overview of the Agile process (suitable for business presentation), and the author forum. The importance of recognizing that new technology methodologies such as Agile Practices must be introduced and carried out in the context of a specific organization, with its own strengths and foibles, cannot be overemphasized. Step-by-step directions and illustrations are given for choosing an appropriate target application for the initial introduction of these methodologies, and each stage of implementation and their possible stumbling blocks are carefully outlined.
That it provides the tools to introduce and adapt these practices in a variety of corporate cultures, with varying degrees of technical sophistication is an invaluable advantage over other Agile texts and will save the organization many thousands of dollars in consulting fees. My only minor nit with this exceptionally fine introduction to Agile Methodologies is that some of the illustration appear to have been formatted in PC-based tools such as VISIO and PowerPoint and require a bit of squinting to study in the smaller book format. With this trivial exception I would award this excellent guide and virtual consultant, an almost perfect nine out of ten review, and recommend it to any organization seeking to intelligently adopt Agile Practices.
The print edition is available at all retailers, while the ebook can be purchased exclusively through the Manning E-Book Storefront.
You can purchase Becoming Agile: ...in an imperfect world from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Re:Oh, THAT strawman (Score:5, Informative)
I'm uncertain as to what waterfall means where you work...but despite loud protestations from several developers...where I work, it means precisely the caricature that we Agile folks oppose. And it's basically mandated that a formal, pre-planned, no-iterations "waterfall" approach is used, as per the guidelines pushed by PMI and CMMI. I wish you were right...but it ain't a strawman.
Here are a few criticisms... (Score:5, Informative)
of agile software development.
http://www.softwarereality.com/lifecycle/xp/case_against_xp.jsp [softwarereality.com]
http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html [blogspot.com]
Re:Methodology fads (Score:1, Informative)
I miss the Extreme Programming fad.
Coding while bungee jumping was really cool.
Re:Oh, THAT strawman (Score:3, Informative)
If your CMMi consultants are pushing waterfall as official CMMi canon, you might want to find yourself a new batch of CMMi consultants. CMMi is about being able to measure and manage your work, not about using a specific methodology to do so.
But a lot of it depends on the size of the company and the average project size. If I have an estimated 2-month effort and 4 programmers (all internal), it's unlikely in the extreme I'm going to deal with the complexity of an iterative model. Plain old waterfall fits that bill pretty well. If the project is a lot larger, I'm either going to break it into phases/subprojects (waterfall's "iterations") or go with a more flexible approach.
Re:Methodology fads (Score:3, Informative)
We're a small company, so we can probably get away with it, but I require my coders to show up twice a week to the office for regular meetings and then be available if something comes up. All our code is either in SVN or Git repositories depending on the project. (Our Java team likes SVN, the web development team likes Git. Usually one isn't dealing with the other). We just come up with a list of milestones and due dates and then I get out of their way. Once a new feature is added, we test for bugs, and usually the last week of the month is documentation.
Re:Oh, THAT strawman (Score:5, Informative)
Shows what you know about PMI then. In fact, right up front in PMI's definition is that a project is "progressively elaborated."
Both are perfectly at ease with an iterative model, simply noting that
1) each iteration is itself a project (or at least: a project phase which requires most of the same initiation, planning, execution, monitoring & control and closing disciplines as a whole project)
2) if you're changing your mind as you go along, there's a real Risk that you'll have to rework earlier outputs to suit later decisions, with impacts to some or all project constraints.
But of course, handling Risk within a mature framework - like PMI's - you'll be able to assess this against the Risks of not doing this, and understand which - in any given situation - is the better option.
In fact, I'm still trying to see one Agile practise that is unique and couldn't be applied to any other project:
* Daily standup meetings? Check
* Ongoing stakeholder involvement? Check
* Defining tests as a way of validating Quality (ie that the product meets requirements)? Check
* Delivering end to end working software each release/iteration? Check
* Late changes in requirements? Check, but each one has a real decision about whether the impact of it is worth the benefit
* Trust of the individuals & Self-Organising teams? Check - good old McGregor's Theory of Y (as described in PMBoK)
* Co-location? Check
And far too often, I've seen Agile used as an excuse for cowboy coding and sheer laziness in producing any documentation (try getting your AMS team to support a complex system and diagnose a production outage based on Googlechat records); I've seen developers rush for it as a simple power grab (but hey, everyone thinks they should be in charge), which is slightly better than rushing for it because it's trendy; I've seen Agile projects swallow 10s of millions of dollars with no business benefit (and yes, I've seen waterfall projects do the same).
While Agile is a particularly useful approach when dealing with customers who genuinely can't know their destination until they're along the track of discovery, and so evolving requirements within the project lifecycle are really called for (User Interfaces being a major example), generally it's not development's responsibility to cover up for customers' failure to plan and decide.
And to anyone who's done a few Agile projects with teams of 5, or 10, or 50... come back and boast when you've done something *hard*. As the classic book on the PMP exam says: it tests from the perspective of a large project, that involves 200 people from many countries, takes at least one year, has never been done before in the organisation and has a budget of US$100m or more.
When you've done that kind of project, come back and complain about PMI's methodology.
Re:Here are a few criticisms... (Score:2, Informative)
Also for a guy at Google, it's a great perspective on how to do Google-like apps, but do you think Google could build a flawless flight control, power plant control or embedded system?
Nope, especially with the process he calls "good agile". That's why they hired the ex-danger guys to develop Android for instance and now applying Agile likely. Agile excels when you're framework is already written, otherwise it's a crap shoot as the lower level code (embedded, OS, driver, etc..) you go.