Agile development sounds great; what could go wrong? Matt Heusser examines some of the myths, mysteries, and classic mistakes in Agile development, including some things to consider before jumping into Agile with both feet.
Perils and Pitfalls of Agile Adoption
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Good programmers should not need pre-packaged “methodologies” like “Agile”, “XP”, “Rational Unified Process”, and so on. Their only purpose is to impress management by allowing mediocre developers to appear to be doing real work.
I would like you to justify your statement. Please provide more information.
Good programmers who take pride in their work may not need methodologies imposed upon them (although they may impose some on themselves). The other 90% (and that’s a conservative estimate) need a little more help.
Howdy
“Their only purpose is to impress management by allowing mediocre developers to appear to be doing real work.”
No their purpose is to keep everyone on the same page in a unified framework, sure it may not work for everything but there is nothing stopping you from thinking “outside the box” and taking fragments of all the available ideas and making your own.
Good programmers should not need …
I`d like to know your qualifications and how you know what “good programers” need, indeed maybe you should tell us about your development practices so that we all may be richer for the experience.
I suggest that “good programmers” are a little more modest than that.
1) Good programmers are honest enough with themselves to know that, _some times_ and in _some areas_, they *are* mediocre developers who are striving to become better programmers.
2) Good programmers realise that, even where they are good, there is always something more to learn, and that each of these methodologies has something to teach them.
3) Good programmers know that they need discipline and structure, and that each of these methodologies can provide that.
4) Good programmers realise that these methodologies are not designed to be exclusive nor restrictive, but serve to exemplify best practices.
5) Good programmers work as part of a team, and the team can benefit from being well orchestrated.
6) Good programmers know that they need to communicate with others, and these methodologies provide a shared language that enables this communication.
7) Good programmers often have to work with less good programmers, and that these methodologis can provide an environment in which (a) the experience is less painful and (b) the poor quality of a collegues’ work can be made explicit.
8) Good programmers know that, at times, impressing management is absolutely vital to the success of a project, a career or both.
I always thought a “good programmer” is simply open minded and gets the job done as efficiently as possible.
But then again, I’m certainly not a “good programmer”.
While I agree that all the discussion and hype around these methodologies is overkill, there’s still some practical use to them. Too bad they’ve been pushed too much from engineering into exec territory.
It’s probably important here to make a distinction between a project with 3 programmers on it. And something like MS Office with way over 50. For larger projects you’ll need SOME kind of organizational structure and testing approach. After all managing 50 brilliant programmers working together is like herding cats.
I’ve worked in a large group environment (150+ developers in an applications development center) where a PFS and PDS was created three years before based on JAD sessions with customers, where all changes were verified using formal automated (TTS) regression scripts and formally documented before sign-off, and where all kinds of metrics were kept regarding unresolved bugs, response times, I/O, etc.
I’ve also worked in small team environments (two or three people typically) doing specialized application support and development on key in-house applications, where the requirements were often created by flipping e-mails back and forth with a couple of end users, and where there were sometimes only a few days (or hours) between the initial reporting of a problem or feature request and the loading of the required code into the production environment.
One of those situations tended towards a more complex traditional waterfall development envirionment, and the other tended very much towards what is now known as “agile” development. Both situations worked well.
The main reason they both worked, I believe, is that the folks who were involved in each of those cases largely understood and bought into the methodology being used at each site.
Sometimes formal processes are good, and they can be useful in catching things which might otherwise escape onto a production system.
Sometimes they get in the way.
It’s really up to each programming group to figure out which types of methodology works for them given their people and the nature of the environment in which they are working.
Mandates from above rarely work without buy-in from those who are impacted the most.
that’s one to bear in mind, not just for Agile development.
If you are doing real work, beware of them since they have plenty of time to think about how to make anything you do look bad, should they ever need to.
Wow, an article talking about the real issues surrounding adoption of agile development instead of the usual argument of “Agile is Bad, because”. Thanks!
To the first poster: Methodologies, wether in a team of 1 or 100 are important and most good programmers recognized this. Otherwise your are simply doing code & fix, which is no good for a deployable project, only for a personal experiment.
It does seem like a lot of negativity for Agile stems from either embracing the mechanics without the philosophy. Extreme Programming Explained, which is vitually the agile handbook states that:
“‘. . Is that XP?’ I can’t answer thumbs up or thumbs down, nor is my judgement important. Are the team members doing all the things that make sense to them in a suitable way? That’s the question, but only they can answer it.”
So you can apply Agile perfectly and fail, or not at all and fail. The question is Does this Work for my team to develop quality software. All deveopers and managers should have to read Kent Becks book.
First I generally liked the article, but must offer a couple of corrections:
1. “Instead of specialists, they suggest generalists” This is really only partly true. People in each function probably need to be a bit more “general”, but you will still have people that are focused on requirements and analysis, some on architecture/design/development, and some on testing.
2. “responding to changes versus following a plan” again not strictly true. Most agile approaches DO follow a plan…but it is not specified down to the minute, and it is malleable (both in contrast to traditional development approaches).
P.S. In response to slava above:
Good programmers should not need pre-packaged “methodologies” like “Agile”, “XP”, “Rational Unified Process”, and so on. Their only purpose is to impress management by allowing mediocre developers to appear to be doing real work.
All I can say is…BUNK!
The article notes that rather than have a team of specialists, Agile consultants recommend generalists.
Surely Agile development falls on deaf management ears at this point.
The whole point of outsourcing to cheap overseas locations is to reduce costs.
Offshoring creates a massive communication drag on staff on both locations, and time is lost due to having to continually correct understanding of mis-interpreted or simply poor requirements documents. There are other deadweights involved, such as cultural differences etc.
But the per “resource” cost is lower, and management sees this only, not the reality of a cost versus quality & efficiency trade-off.
So how do IT organizations where outsourcing is all the rage have a hope of introducing “Agile” methodologies into their processes? How does an organization outsource to reduce costs while at the same time having technical staff in close contact with customers?