Guest post by InfoWorld offers a look back at the first decade of agile programming. Forged in February 2001 when a group of developers convened in Utah to find an alternative to documentation-driven, ‘heavyweight’ software development practices, The Manifesto for Agile Software Development sought to promote processes that accommodate changing requirements, collaboration with customers, and delivery of software in short iterations. Fast-forward a decade, and agile software development is becoming increasingly commonplace, with software firms adopting agile offshoots such as Scrum, Extreme Programming, and Kanban – a trend some see benefiting software development overall
There isn’t any conclusion, just a few comments by kent beck and ward cunningham surrounded with background and history.
There have been many, many crimes committed in the name of agile. I think overall we are better off then we were though, since nowadays people at the very least pay lip service towards doing things the right way, rather then having their programmers completely isolated from everyone and everything else in the business. Unit testing is normal now in enterprise development, again, not unit testing _well_, but anything is probably better then nothing.
Not sure I agree.
Bad unit testing can be worse than no unit testing. Wasting your developers time writing a test that doesn’t test anything properly is just a waste of time. Or worse, it tests that the code does what the code does thus making the test fail when you fix the code.
Even worse, an unit test is often described as the holy solution to all bugs, which again makes a lot of developers stop thinking about how to write resilient code. The unit test is supposed to find the bugs in it anyway. When the program then crashes at the customer, they conclude the unit test wasn’t good enough instead of the way the code was written.
This is not to say that unit tests don’t make sense, but I find the very overrated personally in the same way code reuse is often considered more important than any other requirements.
In my experience there are a lot of companies that say they use Agile methodologies and do TDD when all they’re doing is paying lip service to the buzz words that make them feel better.
In order for agile methods to work the developers and managers need to actually understand the how, and why of each step and do it right otherwise it’s just adding extra overhead.
I’ve worked at several places that will SCRUM but then never do burndowns and calculate velocities. Or think that because they didn’t get everything done in a sprint they can just add the missed tasks to the next sprint and end up in the same place at the end of the next one.
Bad management is bad management no matter what the buzzword methodology being used. And bad developers will always be bad developers if they don’t try and learn how to become better.
Edited 2010-11-03 05:06 UTC
I would have voted this up but I already commented…
I can see that agile has benefits but only if it is done right and if everyone involved in a project knows and understands the process and tools well.
I come from the “old school” ways… it has been difficult but not impossible for me to latch onto this, but even I, with my minimal knowledge, see the process totally abused on a day to day basis… And let me tell you… a project run under the “agile” moniker but not REALLY is PAINFUL. I am in one of those right now.
Scrums break down into technical discussions, sprint planning becomes “this is what you all need to have done for this sprint”… etc.
I’d much rather do it the old way, spend time up front to use the old input-output requirements, functional specs/flow charts and design specs BEFORE we start coding so that it is clear as to what needs to be done.
No fancy terminology, meetings circumscribed by their purpose as they always were, development cycles demarked simply by deliverables, etc.
Now, I KNOW the agile process defines these things, but unless a company commits 100% to learn and implement it, it’s useless.
Sure the methods can be abused and lead to horrible results, but i don’t believe focussing on the burndown or velocity is really all that important.
Sure it is nice to know if you are on track or not, but what really matters IMO is breaking the projects into more mangeable sprints in the first place, dividing the developers into smaller groups that can have rapid communication, and the daily scrums that help catch problems before they get big, and of course the ability to quickly react when conditions change. Communication is the key word.
Test driven development unit testing cant find all errors and is not meant to find all errors, if you try to make them do that, then you are doing it wrong. (not that there is anything wrong with systematic testing, but lets not confuse that with TDD or other agile methods)
The tests are mainly supposed to help you drive the code forward and let you refactor code while maintaining a reasonable belief that you have not broken anything.
No it hasn’t.
I don’t know. Chaos maybe?
Where I work, Agile means being like a woman who can’t decide on what to wear for the day. When she has, the weather has changed but it’s too late to change (until you rinse and repeat the following day).
Then if you try to introduce common sense things like TDD into the equation you are treated like a heretic and people start wantingto burn you at the stake.
… on the customer. If the customer also lives agile, agile delivers perfectly well. If not it fails.
So what does it mean “live agile”. Agile is communication intensive. The supplier meets the customer once a week or at least every second week. The supplier presents what has been done. The customer gives feedback and reprioritizes tasks if needed.
That constant, low latency feedback steers the project. There is no developing a year or two things the customer does not need.
That is in brief the bright side of agile. But agile has also an ugly backside.
First point is the customer. Agile fails miserably if the customer refuses to visit the meetings. Last decade I had some customers that just said: “Just deliver what I want at the end of the project.”. This kind of customers is not interested in weekly meetings. You can not live agile with them. You have to fall back to the classical phase model.
Second point: Agile heavily focusses on the product (e.g. the application to be developed) itself. Documentation often is omitted. Simply because it is out of focus.
Third point: How do you do calculate fixed price, agile projects? How do you convince your financial controller? The controllers I have met so far, want to see “function point” counts. COCOMO II seems to be widely accepted.
Ugly side aside, I personally prefer agile 😉
pica
Agile can turn into a nightmare, if you don’t know how to use it
Other than that, it may serve a good purpose, but I’m totally convinced that with the right people you can create whatever you wish, even though not using a specified process. Yes, Agile is trendy these days …
I yet have to get handed over a specification or an assembly of requirements which proves completely correct as well as neither under- nor overengineered.
In my experience — I live and work in Europe — specifications and requirement sets tend to be largely overengineered. Almost all stakeholders, I had to deal with, simply were unable to realize what their requirements imply. Even if I told them the implications, they often refused to face them.
Beside this conclicting requirements are the rule. Different stakeholders have different views. That is why a requirements engineer asks several stakeholders. The different views sometimes produce conflicting requirements. Sometimes the conflict is not detected in the requirement engineering phase. So it ripples through the specification phase into the design phase or even further.
This poses another problem: I yet have to meet a stakeholder who remembers why (s)he formulated a specific requirement half a year or a year ago. They also are not aware of the context they did it.
IMHO the “classical” phase models do not face the human nature. Humans can not grasp hundreds or even thousends of requirements at once. Humans do not remember why they decided the way the did a year ago.
The time frames to dea with in agile projects are more human. In an agile project conflicting requirements are normally detected within a week or two. Plus the number of requirements the team has to deal with at a time is significally lower.
That is why I prefer agile. It is more human.
pica
Agile is yet another great reinvention of the trademarked practices of software developers/managers to keep their jobs via specialized training trips, seminars and of course the all important job security via obscurity.
I hear you!
The success of agile development heavily depends on developers keeping on top of things and constant follow-up. It works if you have the right people.
It was nothing new though……..
Edited 2010-11-03 18:56 UTC
I have lived through 2 projects where managers tried to use agile (different managers, btw).
In both cases, agile methodology fell down very fast, especially unit testing.
If you are working in videogames of AAA level (or aspiring to AAA level), your code must deliver: performance must be comparable to that of your competition, and you are not going to find a recipe anywhere explaining how to achieve it.
Therefore, if it’s not fast enough, it must be optimized, or rewrote, or totally eliminated to change the focus. Also, memory footprint is usually a problem.
And releases must be provided in very tight deadlines.
At the end, reality wins. You can’t write unit tests for code which is changing and even disappearing in front of your eyes. Especially when you have to deliver “this Sunday!”.
It’s ironic, but agile development is not agile enough for videogames.