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.
Methodology fads (Score:5, Insightful)
Every decade or generation management and process fads change. All of them have their faults and all of them have their benefits, and none are ideal for all situations.
I wonder what the fad of the 2020s will be?
Oh, THAT strawman (Score:5, Insightful)
Oh, right, yet another valiant effort at demolishing a strawman of the Waterfal Model... which never really meant the carricature opposed by the "agile" crowd, and wasn't applied that way. Ever heard of iterations? Right. Apparently the agile crowd still never heard that anyone else uses those.
Re:Methodology fads (Score:4, Insightful)
I see changes in the software development process as more of an evolution than a fad. The needs of management and end users change, so the process changes with it.
Ah, a new entry (Score:3, Insightful)
A new entry for you Buzzword Bingo cards. The big question is whether "Agile Computing" and "Agile Development" should be separate squares or lumped under "Agile"?
I vote for a single "Agile" square.
Ad hoc is best (Score:5, Insightful)
The best programmers utilize domain specific knowledge gained through years of experience to perform the project design and development tasks that make sense. Trying to generalize one model to fit all domains is doomed to failure. Mainframe COBOL screens work differently than web screens which work differently than low level screen drivers and so on.
If you're starting work in a new domain, no methodology is magically going to make things work. New domains of development require plenty of experimentation and failure. How to best build the project is going to depend on what comes out of that experimentation.
And above all, the most important factor is people. You need smart people. No amount of clever methodology is going to make mediocre programmers create a great project. And for smart people, SDLC usually stands in the way of what they already know works best.
Re:Methodology fads (Score:2, Insightful)
Re:Methodology fads (Score:3, Insightful)
They even seem to come with the weird religious rhetoric, too, promising that if only you embrace $Methodology, your life will change. Well, except the ultra-oppressive ones like CMMI: it demands that you accept CMMI or be destroyed.
It seems to be a fact of life that these things are going to float around, so I guess what makes sense is figuring out which ones are relatively better or worse, and what ideas from them are relatively useful or not. As (excellent tech blogger) YosefK put it [yosefk.com] in a review of an Extreme Programming book:
Re:Methodology fads (Score:2, Insightful)
I wonder what the fad of the 2020s will be?
I'm almost certain that the language fad will be functional programming, unless of course something even bigger and sloppier comes along to counteract Moore's Law. The management and process fad? Who cares? Except for a lucky few, we'll all have to nod and smile and suck it up until the next silver bullet comes along.
Evolutionary Prototyping (Score:3, Insightful)
This approach is horrible for things that have to work perfectly the first time (e.g. rockets to Mars), but for web development seems to be a decent approach. It's also hard to estimate how long something will take, as the requirements aren't known up front. Still, it's what I've been using for years. I don't think I knew what it was called until our organization brought in a consultant to talk about this stuff.
Re:Methodology fads (Score:5, Insightful)
The only Agile Programming method is to trust your workers, and give them what they need to get it done.
My company said it was agile, but every process was waterfall with the names changed. More gates, more reviews, more layoffs and offshoring.
I could support my application 100% and have time for other development, but instead I have to train other teams (10 people at least at this point) and produce enough documentation that they can fire me when I get too expensive and hire a homeless guy to replace me.
Trust your coders, give them access they need. Then, when someone inevitably breaks your rules, hold them accountable. That's the key. Don't change the rules for everyone so you can answer "What have you done to prevent this from happening again?" The answer should be "We enforced our current policies, the person has had all access stripped, then terminated, and a reminder sent out."
I can't do agile development if .NET has built-in limitations which require a change request to an offshore server admin support group that doesn't even work my hours. So I sit idly until the workday ends, wake up the next morning and realize the sa team wants more information. I just bypass the whole thing and develop locally, but I can't always demo locally. If I could configure the box myself, I'd be able to document what I did so I can make an implementation guide, but I can't even do that - the dev servers are locked down. I am expected to document steps that I can't perform myself, nor test. That adds time to development.
Trust your coders, work closely with them, and get something working. Then plan for changes, because there will be design updates as well as requirement updates.
It all boils down to hiring people who can code either quickly or generically, so that when something changes they can respond - and then allowing them to respond.
How to turn your skilled employees into cogs (Score:5, Insightful)
I think the appeal with agile development is that it removes any barriers that programmers might have, such as rigid milestones, etc, and basically allows management to do what they want in terms of setting goals. It also is appealing to management because the knowledge sharing implies that they can get rid of their most expensive employees after a period of time (once the knowledge has dispersed). Specialized knowledge is an anathema to management, as it means that you have to pay that person more, and it's critical to the business, it's harder to fire them.
We have to evaluate agile based on it's real world results, not what the books describe. In the real-world, agile creates a very high-pressure work environment, where personal space is non-existent, everyone is watching you, and your work is constantly on display. This pressure can produce productivity gains but I would say that in the long run these gains aren't sustainable. I think agile is a very poor fit for your average introvert, which, imagine that, describes most programmers very well. What I believe will happen is that over time the better developers will move to a work place where things aren't quite so agile.
In the mean time, throwing out such ideas as design first, is going to cost us, big time. I think that software quality will drop, but it won't be obvious, as "quality" and "productivity" aren't things that are easily measurable. Often times, managers walk through a room, and if they see a bunch of people typing away or debating some design issue, then they see that busyness as productivity. No, I think the drop in productivity will become apparent when non-agile competitors clean their clocks, but then it will be too late.
Re:PyPy - crashing and burning with "agile". (Score:5, Insightful)
Yeah but I'm sure someone here can point to hilarious failures of any methodology, or tool, or language.
Let's face it, software sucks. Writing software is hard.
The users are the problem (Score:5, Insightful)
Me: Here's the prototype. It's black and white, but the finished product will be in full color.
Them: This menu item is supposed to be green.
Me: That's because the prototype is in black and white. We're just trying to get the text and spacing correct
Them: That item is supposed to be red...
Managing user's expectations during the prototype phase can be a full-time job. (:-(
Re:Methodology fads (Score:3, Insightful)
That is a "throw it over the wall" approach which time and countless failed programs have shown *DOES NOT WORK*.
Re:How to turn your skilled employees into cogs (Score:5, Insightful)
Very true.
The biggest surprise I had in my professional life was when I was stuck on a particular problem. Completely stuck. So I tried doing other stuff in the mean time. Then I rand out of stuff to do. Posted on newsgroups and forums, but still no answers.
So I asked my boss if he had anything else I could do, while waiting. "Go play solitaire, read a book, go for a run. But not too far, and keep your cell on you if we need you."
He knew that some things cannot be forced. So I got paid to sit on my ass and read books for two days until the answer popped into my head. Sometimes the best way to be productive is to just sit back, relax and do nothing.
Agile is good for GUI/web projects (Score:3, Insightful)
Scrum has one good point - show your code to your customer often and apply his comments. But that works only for GUI or web. I cannot imagine that in, say, medical software. For instance, one of my colleagues had to optimize crucial piece of code (some heavy math for CAT scanner). It took him several months. Only thing he could say to the customer was like "it is now two times faster" or "it is now 3.45 times faster". Not something you can really get some useful feedback on.
In another company, we were supposed to do a project for GE, and there was some serious GUI there, but their office was some several thousands miles from us and I really didn't know how we would make regular meetings with them as Scrum required. Also, they had some very elaborate specs and they did not see too much point of Scrum methodology. In some other situation, that project would be a perfect one for Scrum.
PS One thing I don't like with Agile evangelists is that Agile (Scrum in this case) is always right. It's either "what are you doing is not Scrum" or "you did not adapt Scrum to your needs", but its never the problem in Scrum.
Re:Methodology fads (Score:4, Insightful)
That's the point when the process needs to back off and let stuff happen.
If you think you can just ignore all the design work when you start coding I'm afraid you are not going to be very successful. You seem to have a 'go away and I'll get you the answer' approach which is the same as throw it over the wall.
Good developers need to learn how to work cooperatively in teams. Too many times I see people that *could* be good developers but have this isolationist attitude and dont want to be involved in the big picture.
Re:I wish it were a fad. Agile means rewrite (Score:3, Insightful)
I must agree. As a Project Manager my boss has sent me off to several of the "Agile" development workshops and I came to the same conclusion I do about most buzzwords - it's a solution looking for a problem. Too many PHB's walking around looking for a way to keep themselves busy.
Re:How to turn your skilled employees into cogs (Score:1, Insightful)
We have to evaluate agile based on it's real world results, not what the books describe.
As the third or fourth biggest game studio in the world, I can assure you about real world results. :)
In the real-world, agile creates a very high-pressure work environment, where personal space is non-existent, everyone is watching you, and your work is constantly on display. This pressure can produce productivity gains but I would say that in the long run these gains aren't sustainable.
Not true. Your work is not constantly on display, the advancement of the is. The client is happier this way and if he chooses to change requirements around, it is less of a deathblow to the project deadline than using the "waterfall" approach. Also, in the long run, productivity gains are the same, as after 2 years of using agile development, I can attest to it.
I think agile is a very poor fit for your average introvert, which, imagine that, describes most programmers very well.
Then you should review your hiring practices. If your employee can't follow daily stand-up meetings or scrums, then why is he working for you? If he can't express his ideas properly, how is he going to advance and evolve as a developer?
Often times, managers walk through a room, and if they see a bunch of people typing away or debating some design issue, then they see that busyness as productivity.
Then those managers are crap. Thanks to agile development, a manager can actually see if stories are getting done and how much time was spent on it. And with agile development, over time, stories can be more precisely poker-planned when finding out how much time tasks will actually take.
Agile development is one thing, actually doing it right is another. It does work well, I can attest to it.