Agile development only goes so far in enterprise

Agile development only goes so far in enterprise

Summary: Enterprise developers are talking on wikis and collaboration tools, but IT still isn't connecting to end user requirements well.


Enterprises have adopted agile development techniques---stand up meetings, incremental changes and rapid rollouts---but corporate IT still has trouble delivering workers what they want.

That conclusion was the key takeaway in a Serena Software survey. Serena surveyed 1,000 IT workers---architects, engineers, project managers and executives---and found:

  • Enterprise developers think their core development processes are generally strong;
  • Customers aren't getting what they want and meeting requirements is hard;
  • Agile development gives IT orgs more software but not necessarily better applications.

Serena said:

These findings are consistent across all industries that were surveyed. Nailing what customers really want and actually getting it into their hands without many bugs are the things that IT organizations need to focus on going forward.

In a nutshell, the developers are talking on wikis and collaboration tools, but IT still isn't connecting to the end user well.

Here's a look at the benchmark survey results, which were based on a 1 to 4 scale.

Topic: CXO

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Agile just doesn't work period

    You can use it to create crappy little apps but for any useful and valuable application you need a strong design and architecture otherwise you end up with a soft foundation with patch work. Designing and Developing software is no different than building a house or a skyscraper. If you don't spend the proper time to ensure you have a solid foundation and a good understanding of what the end result is going to look like, you end up with a building built on a clay foundation using wood instead of steel or perhaps only concrete not reinforced concrete. End of the day what you build has a lot to do with just how well thought out it needs to be.
    • Agreed

      Agile is a sure road to software that is completely unmaintainable. All software tends to arrive at this state eventually but it happens far more quickly with agile.
    • Just don't understand agile

      After reading your post it is clear that you just don't under agile or the agile process. You start by stating that you need a strong design and architecture and then assume that agile prevents this from happening. It doesn't! Creating a strong design and architecture takes a little time up front so that you stay ahead of the developers but there is no reason it can not be completed in pieces. You just have to be willing to accept that what you produce can and probably will change a little as you move down the road.
  • Understanding agile

    Some people think that agile is hard to understand, but the principles are quite simple:

    1. Throw a story into the scrum.
    2. The scrum fight over the story and eventually it's thrown out and some hapless developer picks it up and runs with it. Everyone else chases after him. The developer's run for his life is known as a sprint.
    3. By the time the developer has implemented the story everyone else has caught up with him, they knock him over, trample him in the mud and hit him with backlogs.
    4. Afterwards the burn out chart is updated to show how many members of the team are on the verge of a nervous breakdown.
  • Agile the death of development.

    As a programmer the single worst nightmare of Agile is pair programming. There are two likelihoods with this horror.
    The programmers have similar skill levels. There will be hours of time wasted in arguments over the minutia or one of the programmers will insist in being the lead and totally negate any of the expected gains of having two programmers.
    The other horror is that the drones that infest IT will fix on the uber coders, leach off them and claim credit for the work
    In either event it is a way for the useless parasites two deny any credit to the programmer who have been carrying them.
    There is no I in team. That is why teams cant do real work. Real work is the product of individuals.
    • Just because you've never seen something, doesn't mean it doesn't exist

      I won't say that pair programming isn't abused, nor will I claim that it is suitable for every person. However, I have been a member of very productive pairs.

      If you use a moving metaphor for programming. When it comes to the sofa problems, you need another person - but it has to be someone that you can trust to hold up their end.
    • Agreed!

      I'll start with the little personal thing that I hate working with someone else over my shoulder. To me, the proper solution for needing vetting of code is two-fold: provability with unit tests that attain full code coverage, and peer review of both the code and the tests.

      But let's go deeper! People wonder why the U.S.A. is losing ground to other nations? Over-emphasis on being a "team player", and insufficient recognition of individual success is a HUGE cause. We seem to be on a path of disliking individual success in this country lately, not just on seeing a peer excel at their craft or profession and get a promotion, but the whole socio-economic class warfare thing that current government is getting involved with waging.

      Penalizing individual excellence leads to mediocrity, PERIOD.
      • Given the impact of ethics in "individual success", or perhaps the lack of,

        some people are sufficiently astute to not glibly generalize success as being a good thing to those who don't deserve such praise because they engaged in deeds most of us would agree are unethical.

        That's the difference.

        And it's a big one.

        And it's management that decides "team player" vs "individual achievement", amongst other issues. Try telling your boss you don't dig the "team player" mindset and see how long it takes before you're slapped with "insubordination"...

        What's going on is far wider than your claim, which is refreshing despite its being grossly incomplete. (Nor is my response covering every base, as there are other elements to consider...)
    • But individuals are expensive...

      Plus, all the colleges that teach Agile are probably ran by liberal elitists who say their way is right... (or what's what I keep getting told...)

      But in more seriousness, skill level is not the same thing as having creative ideas. Two people know how to program similarly, but the thought behind the need to program may be quite different...
  • Agile-Shmagile. The point of the story: Can't get requirements!

    The previous posters (and the flack who wrote the headline!) are completely missing the point of the article. It has nothing to do with Agile. What's the worst score on the survey? GETTING REQUIREMENTS. It's GIGO all over again, folks. Agile or waterfall, lack of requirements coming in = crap software coming out.

    At least the agilists emphasize having a stakeholder embedded in the team!
    • So the challenge is

      to express the requirements in language the business can understand but is formal enough to be used as the basis for an implementation.

      One of the problems I have with agile is the idea of the code being definition of the problem. The definition has to be in language that business people can understand - otherwise they cannot test whether the requirements have been implemented or not.
      • Agile doesn't say that!

        Where does the Agile Manifesto say that code is the definition of the problem?

        It says we value "working software over comprehensive documentation". Not to be construed as imprecise documentation, nor insufficient documentation. Combined with the value of "individuals and interactions over processes and tools" and "customer collaboration over contract negotiation", the implication is that the business comes with a decent framework of requirements, which will need refining and fleshing out, and that during the agile development of the system, personal interactions and collaboration will refine those...every detail is not to be expected in a Word document...or likely the project will never get off the ground!
      • Code is overemphasised in Agile


        All I am saying is how do you express the requirements in a manner that is comprehensibile to business people but formal enough to be the basis for well designed processes. I would agree that using documents like Word is wholly inadequate to this task.

        The well designed processes may or may not involve a computer system. Agile places too much emphasis on code.

        As for individuals over processes and tools, it depends what kind of tool you mean. If you mean a software tool then I would agree. If you mean intellectual tools for defining problems then no.
    • TIP: don't ask the users

      Identify the process / problem.

      Speak with people that understand the issues, develop (adopt) this solution. Have user to adopt new process.

      No point asking the end user to define the problem and/or solution. They'll describe their understanding, often far short of whats required.

      Agile isn't the issue. Often it has the advantage of identifying the solutions failures early so the project can be dumped, or knowledgible people brought in.
      Richard Flude
  • Agile with no process = burnout ...

    I couldn't avoid to have a good LOL when reading +jorwell comment since that reminds me a lot several corps that I have worked at, therefore, I have to agree with +techboy_z where agile does not say that code is the definition of the problem.

    Agile is just a simple way to force the process to be from requirement to development with quality and build strategy (nothing hard right !?).

    Anyway, if the process is not defined, it will surely not work...
    • re: Agile with no process = burnout ...

      Let's call a spade a spade and say out loud what Agile really is:

      Agile was developed by a bunch of developers many years ago (at the beginning of the globalization period that's overtaken the industry now) with a laundry list of gripes, that:

      - Feared for their jobs because of the emergence of offshoring (hence Co-Location)
      - Hated dealing with incompetent business analysts (hence direct business user contact)
      - Hated documentation and just wanted to code... Immediately...
      - Hated being constrained by schedules... and HATED project managers
      - Did not want to be held accountable personally for bad code (which is why in Agile, the Scrum Master and Product Owner have direct accountability, but the "Development Team" lives or dies as a collective. How convenient.

      This isn't that difficult to decipher... Agile is a developer-created framework... FOR the developer.

      It has nothing to do with building the RIGHT product. It has to do with elevating the stature of the onshore programmer.

      And in today's reality, it's all about enriching the pockets of Agile advocates. How much do they make each time they certify a completely unqualified group of drones? hmm?
  • Apps, and more apps...

    ...delivered where they are needed by a Computer Services App Developer who works for the team needing the help, NOT the IT department. Anything else is whistling Dixie!
    Tony Burzio
  • Agile seems to make stressed staff and noisy offices

    10 years ago, stories were a few weeks and everyone was involved from the start.

    Now the average is a few days and a couple of key people make all the initial decisions before the bulk of the workers are called in to plough through a task list.

    Adding to that, open plan offices are now home to niosiy standups where a bunch of poor sods are required to publicly explain why they are having problems with what has been dumped on them without much discussion or choice.

    In other words, the egalitarianisn and collective reasoning goals of Agile are being subverted for pragmatic cost-cutting and authoritarianism. Sort of 'we know what needs to be done, so we do not need to discuss it with you, but will tell you what we need you to do, and to make sure you perform, we will make you humiliate yourself in front of your fellow slaves if you don't.'

    Reminds me of the lofty ideals of Communism gone downhill to dictatorship (almost).
    • Dialog and reality checks between business and IT are what is needed

      Plus need the understanding that IT does NOT solve problems, it helps implement the technology side of solutions business has resolved are needed.

      It is asking:
      1) Is it needed?
      2) Is it possible?
      3) Will it fly in the organisation?
      4) How do we do it?

      IT can be a consultant on 2, and be the workers in 4, but ALL are the RESPONSIBILITY of business.
    • Absolutely intentional on the part of management

      Agile is seen as a means of exterting very tight control over the development process.

      Tasks come in, code goes out, the whole thing looks just like a factory production line, management love this.

      Do you get good quality software that can be maintained in the long term this way? I don't think so.

      I think there are some interesting ideas in agile ( though I don't buy the whole packet) but I definitely think the original spirit has been subverted.