Tracking change and innovation in the enterprise software development community
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Free Book Offer
SOA Demystified
$40 Value
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
Posted by Deborah Hartmann Preuss on Aug 19, 2006
Peter Coffee, eWEEK's Technology Editor for over a decade, has 23 years experience in evaluating information technologies and practices as a developer, consultant, educator and internationally published author and industry analyst."Participants reported the greatest value provided by Agile development is the ability to respond to change. This is exhibited in the form of challenges in managing scope, increasing the speed of delivery, responding to unclear business requirements, or responding to changing requirements."But then, he wondered, "Why isn't Agile development becoming so much the norm that it no longer needs a name?" His observation, while looking at survey results: The factors that make an organization a tough sell for agile development seem to be precisely the factors that are likely to make development a problem for that organization, by any means.
Technical Debt and Design Death
VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.
Coffee's list sounds about right. Agile can cause problems for an organisation because it surfaces these problems. Some people may not want these problems brought to the surface.
Although the first bullet (lack of skills) could be a worry about not just the organisation, but also about agile development.
Requires too much business involvement of organization
So the techies aren't just allowed to get on with it? You have to actually speak to lots of the business, possibly even establish a consensus? Is that realy a big worry for a large organisation. Isn't this what every other department has to do when looking to implement change programmes?
Projects are too big for agile practices
Again surely this is an issue for agile as much as the organisation. Bulding an Air Traffic control system is hard and its big. Equally establishing a new set of standard procurement processes for a global business is liable not to be the sort of thing whacked out in a mashup. N.B. this doesn't mean "big bang" it means iteration, specification, review, and probably quite a decent degree of ceremony at the programme level.
Projects are too technically complex for agile practices
Again is this a problem for the organisation? If you are doing something like demand forecasting it really is pretty damned hard maths (I certainly don't understand it), this doesn't mean they fail, but that you have to understand what you are doing.
Distrust of agile practices for mission-critical systems
Where has agile proved it self for mission critical systems?
N.B. I'm not saying that sometimes agile doesn't work, but that there are lots of times when projects are done sucessfully, respond to change and to vague requirements, when agile approaches just wouldn't have worked. Iterative development (a 70s invention) is critical, agile/RUP/DSDM/whatever then is about what works for your project. If you are doing iterative delivery in short bursts then you can attack and succeed at all of these problems.
The real question is why the hell are organisations still doing Waterfall in 2006?
Coffee's list sounds about right. Agile can cause problems for an organisation because it surfaces these problems. Some people may not want these problems brought to the surface.
Are these examples of problems in organizations or with Agile. There seems to be a knee jerk reaction to use Agile at all costs when it's Agile that has shown deficiencies to adapt to added complexity.
I hope we're not saying here that "your organization doesn't fit my management style so you're deficient". Agile has to adapt to reality(see above) just as much as organizations need to be more flexible.
Agile has its place like other methodologies, but Agile isn't the first management technique that has enumerated these painpoints in organizations.
Part of the problem with adoption with Agile or any other management technique in my experience is that you are going to management and saying, "You're screwed up, look at all these problems". Managers are a little touchy with that type of assessment of their management domains. That's why the status quo usually wins.
I didn't read the linked article, so I apologise if my response is inaccurate, but based on the summary posted here, it basically seems to say that if you can't use agile, your business is broken.
This is exactly the sort of nonsense that ensures that the non-agile crowd continues to ignore the agile crowd and dismiss them as a bunch of pompous asses.
The goal of any business is to function as a business. The goal of IT in any business is to serve that function as best as it can. IT is, and always should be, secondary to the goals of the business itself. 'Requiring too much business involvement' or having projects that are 'too big' or too 'complex' are all ludicrous claims to any well functioning business. Why on earth is IT dictating to the business how it should be run? A successful IT department will ensure that the business can do what it wants to do, without religion or a blind obsession with one approach or another.
Blaming the business for agile being a bad fit and one that many people seem to dislike is somewhat like blaming an xray machine for any broken bones one has.
I read the linked article, and what I understood is:
- Requires too much business involvement of organization
Agile requires constant involvment of the business, because of the shorter development cycles and frequent re-assessment of the scope. That can be a problem for some organizations that are used to involve the business at the beginning, and the end of the project, not all along the way. They are not able to change these practices, even though waterfall creates monster projects extremely difficult to manage and that often fail after spending millions (instead of detecting the issues earlier with agile practices). That is a serious organizational dysfunction.
- Projects too big, projects too technical
I think the author was being sarcastic here. Quote: "My reaction to these is that they sound a lot like "Our projects are too big, our projects are too complex, and our mission depends on systems that are too big and too complex to evolve as quickly as they should." You get the idea, I hope. I've seen that in many organizations: whatever the real underlying complexity is, teams always try to make the problem look bigger than it is, and are very reluctant to change. Whatever solution you propose, it would never fit their environment. In some organizations, entire departments can be uneffective and hide that behind a theoritical complexity. Proposing to accelerate developments and reveal the companies' real assets might not appeal to everybody...
I think these are serious organizational dysfuntions. I don't think the author advocates Agile for any context, but rather explains that when trying to introduce Agile, you may discover underlying symptoms that are very worrisome (that Agile won't solve btw).
Well, I worked on an agile Air Traffic Control project. 8 people in the core team, 13 total. Nobody told us it was too big, nobody told us it was too complex; so we just went ahead building the system. I guess there might be projects too big and too complex, but from my ATC experiences I'd say if it can't be done Agile, it can't be done. A given team or organisation might not be able to do a given project agile because of size or complexity. That's another matter.
...it basically seems to say that if you can't use agile, your business is broken.
Yes, it basically seems to say that.This is exactly the sort of nonsense that ensures that the non-agile crowd continues to ignore the agile crowd and dismiss them as a bunch of pompous asses.
If it were nonsense, then agreed. Perhaps it isn't nonsense, though.The goal of any business is to function as a business. The goal of IT in any business is to serve that function as best as it can. IT is, and always should be, secondary to the goals of the business itself. 'Requiring too much business involvement' or having projects that are 'too big' or too 'complex' are all ludicrous claims to any well functioning business. Why on earth is IT dictating to the business how it should be run? A successful IT department will ensure that the business can do what it wants to do, without religion or a blind obsession with one approach or another.
Agreed. Yet you do say "a well-functioning business". What happens where the business is not well functioning? Is it possible that the IT department, in trying to be agile, will surface some problems? Of course it is possible.Blaming the business for agile being a bad fit and one that many people seem to dislike is somewhat like blaming an xray machine for any broken bones one has.
Blaming agile for agile being a bad fit and one that many people seem to dislike is somewhat like blaming an xray machine for any broken bones one has.
What the original article says is that if agile appears to be a bad fit then there are problems somewhere. One of the problems may be that what is claimed as agile isn't; unfortunately that is a common problem. On the other hand, the problem may lie with the business.
A reference for that ATC system would be pretty good and impressive. Given that most ATC systems require radar processing, conflict detection/resolution, flight data processing, voice comms, flight strips (unless pure electronic), and of course the main display screen including views like radar, flight, status screen. Radar processing alone is, to say the least, a bit of a bugger even before you hit conflict detection/resolution
My direct references would be Eurocontrol & NATS with simulation experience from about ten others and secondary experience on a bunch more.
Being clear here, and I'd say this also applies to the Canadian system that is sometimes quotes as being agile, these successful systems had extensive automation of testing, had massive amounts of iterative delivery, but also had lots of design and formalisation around reviews. The key was always to break the problem down into its smaller bits (where small always IME had more than 13 people on each bit) and then to have lots of deliveries into "production" (obviously not "real" production) and get tight and accurate feedback at all stages. This involved working directly with the end-users, often using "prototypes" aka as full scale simulations, to determine the best way to do it. Simulations were often developed by small teams in very quick turn around times with active tailoring of the solution during simulations.
But I have to admit delivering a full ATC system into production from conception with 13 people and meeting the safety standards expected by the likes of Eurocontrol or the FAA would be just a tad impressive, hence a reference would really help.
Hi Hani. I'm not sure of your meaning in this sentence, can you clarify please? Thanks.
> 'Requiring too much business involvement' or
> having projects that are 'too big' or too 'complex'
> are all ludicrous claims to any well functioning
> business.
We had radar data processing cracked before the major customer dropped out. The multisensor tracker passed Eurocontrol tests. I don't have the project data, it commenced 1996 and used something akin to FDD but pre-dated FDD. All radar data processing was done with a feature team of 5 folk in elapsed time I think about 7 months. That included 3 positional data input formats, multiple comms formats, basic false track elimination, integration of GPS positional data, integration with pre-existing radar display software; prototype system management, health check and hot switch functionality.
Oh, and - one piece of data I do recall - our projected core team total for the basic ATC was 35 man years. This didn't include ground control but did include approach; included electronic strips but not printed. We hadn't done radar quality control yet. Didn't include integration of radio or datalink to aircraft except GPS which was already done.
So it never went live....
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
12 comments
Watch Thread Reply