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.
Waterfall (Score:2, Interesting)
Waterfall crushes a piece of my soul every day.
From one end to the other (Score:5, Interesting)
So we've gone from over-designing systems to under-designing systems.
How about right-designing a system based on the complexity of the scope and the key personnel involved?
Is that crazy?
Agile development in engineering? (Score:5, Interesting)
But our company software has a large installed base and we need to fix bugs in existing code and somehow graft new functionalities into existing architecture with full backward compatibility for old saved data. And the skill set of coders varies widely. There are just a couple who can even touch isoparametric element stiffness matrix code, to name just one example. I still dont know how agile is going to change the way those two guys work.
I see the advantages of early feedback, and early testing, testing partial implementations etc. But at some point for some kind of code development, Agile may not be the best way to do the code. And I am hoping the training will shed light on where I can use Agile and where I should stay clear of it. I don't want to jump on a band wagon because it is the latest and then have a minor revolt among my padavans.
Re:Waterfall (Score:3, Interesting)
PyPy - crashing and burning with "agile". (Score:5, Interesting)
The attempt to write a Python implementation in Python, PyPy [codespeak.net], turned into a death march. The project has been underway since at least 2003 (when they had their first "sprint"), never produced a usable system, and the European Union pulled the plug on funding. But the project limps on. There's a released version. It's slower than CPython. There's supposed to be a "just in time" compiler Real Soon Now. (This is try #2 at a JIT, not counting the schemes for outputting Java bytecode and Javascript.) Six years in on a compiler project, and no product.
The PyPy project is very "agile". They have "sprints". They have "flexibility". They have nightly builds. They have mailing lists and trackers. They support multiple output back-ends. They have about 50 contributors. What they don't have is a usable product.
Meanwhile, one programmer produced Shed Skin [blogspot.com], which compiles Python to C++, with a speed gain of 5x to 50x over CPython.
When the problem is dominated by design and architecture, "agile" doesn't help.
Actually, yes, it's a strawman (Score:4, Interesting)
Actually, I hope you realize that -- since it's referenced even in the review here -- the 1970 article by Royce which described it (albeit not actually using the term "waterfall") was a description of a dysfunctional process which doesn't work right for software. That article wasn't a formalization of the waterfall model, but a critique of it. (And a modification to something that works better, at that.)
It's not even the only one. Several authors and books exist about making software development work, _long_ before there even was such a thing as the XP manifesto or the word agile.
So at the very least we have the first strawman: that we needed the Agile crowd to come along and wake us up to the fact that the waterfall doesn't work. It was widely known that it doesn't work, at _least_ since 1970. You know, the fun times before microprocessors and personal computers and when even Unix was still just a cutesy personal experiment.
The model actually doesn't come from computing but from RL construction and partially manufacturing. That's the place where the costs get prohibitively higher if you discover a mistake after you built the whole building. And while _some_ misguided MBAs have always tried to treat programming like a generic assembly-line operation -- including using methodologies like this one, which are utterly inapropriate -- it's hardly been the standard, de facto and de jure methodology in computing. The pretense that somehow if you're not doing a crap^H^H^H^H agile job, you're one of those using the waterfall model (never mind that it was discredited for 3 decades already) is the strawman that irks me the most. Yes, some islands of insanity exist. You have my sympathy if you work for one. No, it's not the standard in programming. No, we don't need a wakeup call or extreme methodologies to know it doesn't work. We knew that already. At least since 1970.
And in reality even the places which go somewhat waterfall-y... well, let's just say that any place that's ever had a change request or made a version 2.0 of a product, essentially has iterations. Not the best form of them, to be sure, but it is iterations. Requirements change after code has been written too.
Agile and embedded systems? (Score:3, Interesting)
Who here has actually used Agile for embedded systems work? What were your experiences?
Re:Methodology fads (Score:3, Interesting)
Fully agree with you on this. What the Agile process has shown me so far is that its a very fragile process, where the management want to break down the developers to the point of making replaceable parts of even the very best programmers. Add the war room to the mix, keep poking developers to "what I did yesterday, what I'm going to do today, whats holding me back" daily even when there is no work planned, so that you keep every one in check, all the time. Every job in the world has some slack built in, so you get to try something new, learn a new tech, etc, but with not Agile. They treat you like a disposable contractor that can be replaced any time. Working in a war room is not only very distracting, but also makes it very hard to look for other jobs since answering phone is going to be hard without causing suspicion.
Re:Agile development in engineering? (Score:2, Interesting)
Re:Here are a few criticisms... (Score:1, Interesting)
Agile has turned out to be the worst of Micromanagement. Make replaceable parts out of every developer. I doubt developers will be motivated to dig their own graves.
http://en.wikipedia.org/wiki/Micro_Management
Re:Methodology fads (Score:1, Interesting)
As a technical writer, I can see producing user documentation in small software projects using Agile is possible, but my experience in large, enterprise projects is that Agile is outright hostile to multi-layered user documentation.
Providing estimates on how long it will take to write and produce podcasts DURING THIS SPRINT -- for a feature the developers may or may not deliver, ... meh.
Methodology is like cooking (Score:5, Interesting)
Methodology books are like recipe book. Good chefs own many of them, and draw on the knowledge and ideas inside.
But buying and following a cookbook does not make you an expert chef.
Re:Methodology fads (Score:1, Interesting)
Yeah, cause they will get laid off first. Most coders actually end up sabotaging the whole project, cause in the Agile "way", no one but the product owners gets the blame of failure. So if the project fails, the whole team usually gets the boot.
Someone show me one agile success that has been around for 5yrs? A real success (e.g. it runs the Boeing 787 flight computer "level") Google and MS are exceptions, cause they do Agile, but their main products are not done in the Agile way anymore...
Also, it is democratic coding, everyone's agenda's come out to play and you'll find not everyone is willing to tackle everything at full speed: some coders don't want to work much (slackers/job hoppers), some want to take all the cool work (resume builders), some want only specific problems (the PhDs), some want the critical-path problems (the prima donnas and corporate climbers), and some want the quickest tasks (the integrators/business coders). With no real schedule, index cards that only team members with the same domain knowledge know how to interpret and no responsibility (it's done when it's done mentality)--it just creates a game environment (coding is fun!) that ends up being a sweat shop from the 10K view.
And yes, agilista is a stupid name that conjures up religious/fanboy fantasies-- there, I said it.
Re:How to turn your skilled employees into cogs (Score:4, Interesting)
If anything, Agile requires high quality developers to be very successful: Since the design process is diluted, you can't get away with having one or two people that run the show technically and a bunch of drones: Bad developers that can't shape up throw a wrench into the system, and send quality down to the toilet.
An agile system where the developers are actually talented raises their skill levels as they go along, and it can be very rewarding to everyone involved. Eventually management can just set them loose on a project, knowing not just that the end result will be good, but that most issues with requirements will be dealt with before they become a serious problem.
If anything, the problems I've had getting Agile implemented is getting management to accept the budget issues that come from leaving behind a model of two very good developers/architects and a bunch of bums paid a pittance.