Opinion: Inability to Adopt Agile May Signal Bigger Problems

Posted by Deborah Hartmann on Aug 19, 2006 06:32 PM

Community

Agile

Topics

Delivering Value ,

Methodologies

Tags

Statistics ,

Introducing Agile

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. 

On the eve of his keynote address at Agile2006, Coffee reflected on an advanced copy he'd received of the Digital Focus survey of the state of Agile practice, and blogged about some danger signs he observed.

Coffee affirmed, from his own experience, survey conclusions like this:

"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.

Coffee cites the following attitudes as worrisome, symptoms of serious organizational dysfunction which will not evaporate with the application of a methodology:

• Organization lacks internal experience and/or skills
• Requires too much business involvement of organization
• Projects are too big for agile practices
• Projects are too technically complex for agile practices
• Distrust of agile practices for mission-critical systems

1. Back to top

   Inability to adopt agile may signal bigger problems

   Aug 20, 2006 9:55 AM by Paul Oldfield

   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.

   Reply

2. Back to top

   Worrisome ?

   Aug 20, 2006 12:22 PM by Steve Jones

   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?

   Reply

3. Back to top

   Re: Inability to adopt agile may signal bigger problems

   Aug 20, 2006 12:24 PM by Frank Bolander

   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.

   Reply

4. Back to top

   Ohdear

   Aug 20, 2006 1:13 PM by Hani Suleiman

   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.

   Reply

5. Back to top

   Not sure I understood this the same way

   Aug 20, 2006 6:52 PM by Tanguy Crusson

   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).

   Reply

6. Back to top

   Never too big, never too complex.

   Aug 21, 2006 6:15 AM by Paul Oldfield

   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.

   Reply

7. Back to top

   Re: Ohdear

   Aug 21, 2006 7:31 AM by Paul Oldfield

   ...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.

   Reply

8. Back to top

   Re: Never too big, never too complex.

   Aug 21, 2006 8:36 AM by Steve Jones

   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.

   Reply

9. Back to top

   Re: Ohdear

   Aug 21, 2006 10:11 AM by Deborah Hartmann

   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.

   Reply

10. Back to top

    Re: Never too big, never too complex.

    Aug 22, 2006 7:36 AM by Paul Oldfield

    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.

    Reply

11. Back to top

    Re: Never too big, never too complex.

    Aug 22, 2006 7:55 AM by Paul Oldfield

    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.

    Reply

12. Back to top

    Re: Never too big, never too complex.

    Aug 28, 2006 11:21 AM by Steve Jones

    So it never went live....

    Reply

• Older >