BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Delivering Value Content on InfoQ

  • Discussion: Measuring Success of an Agile Project from the Customer’s Perspective

    A recent discussion on the Scrum Development list looked at: “How does a customer measure the success of an Agile project?” Emphasis on: “measure”. The discussion seemed to agree that clients do need a way to track success in their terms, and various metrics were suggested, though it was agreed: it depends on the situation and the customer.

  • Prefer Broad Design Skills over Platform Knowledge

    In his latest article Martin Fowler suggests that what matters most while building a team is not experience or thorough knowledge of the specific platform and business domain, but rather some broader skills that allow building quality software and delivering value.

  • Is Velocity Really the Golden Measurement?

    What value do teams get from measuring velocity, beyond the ability to reasonably estimate commitments for the short-term future? J.B. Rainsberger proposes that teams spend less energy scrutinizing velocity and more energy thoughtfully identifying and eliminating areas of waste in their projects.

  • Doer vs. Talker: Working Software over Comprehensive Documentation

    In Are You a Doer or a Talker? Jeff Atwood of Coding Horror echoes the agile manifesto's 'Valuing working software over comprehensive documentation.' Noting an article by John Taber, Atwood draws parallels between transportation studies and transportation construction projects.

  • An Agile Developer's Responsibility

    What is a developer's responsibility when a customer asks for a quick and dirty solution? Should they listen to the customer and take the short cut because, after all, they are paying the bill? Should they instead always do what is technically the "best" option in their opinion? Or is there a middle road that should be taken?

  • Charming the Army: the Power of Delivery

    Here is a story about Agile's use in a governmental organisation: at the 2006 APLN Leadership Summit Mark Salamango and John Cunningham looked at the problems and opportunities of introducing Agile in Army environments. True Agile practices cannot be 'commanded' or 'directed’ but frequent delivery offers Agile leaders a "soft" kind of power that is, in fact, very effective.

  • Can architecture create a gap between developers and software they build?

    Many software project management and architecture approaches tend to parcel out work on a project in a way to create hierarchical layers. This helps simplify both developers’ work and management. However, the underlying information shielding among layers can potentially create a gap between developers and the software they are building, if their tasks are totally taken out of functional context.

  • Big Architecture Up Front - A Case of Premature Scalaculation?

    Taking a look at the reaction in the blogosphere to the idea of "premature scalaculation". The question is - when designing your application, how much time should you spend on building out for scalability?

  • An Agile PM Walks a Mile in a Customer's Shoes

    Last year Ternary COO Alexia Bowers walked a mile in a project customer's shoes, and told us how it felt in this Agile2006 Leadership Summit presentation. She stressed the need to meet deadlines through creative solutions, instead of simply cutting scope.

  • Religion driven industry? Buzzwords and checklists vs. thinking and inspection

    James O. Coplien has recently argued that today’s industry is based on buzzwords and checklists. The use of some techniques and methodologies, TDD for instance, has become “a religious issue”. This prevents from inspecting possible tradeoffs and focusing on finding solutions that would be the most appropriate and the most cost-effective for a given project.

  • Opinion: Do Agile Development Practices Always Help?

    Are our efforts in Agile development really helping the organizations we work for? What does it mean to ‘help’ our organization anyway? That depends on our organization's goals – if what we are doing moves our organization towards its goals, then the answer is “yes”, otherwise the answer is “absolutely not”, we may even be inadvertently hurting the organization.

  • Software Development Insurance

    The motion picture industry insures completion of their motion pictures via a performance bond, where an insurance company guarantees satisfactory completion of a project by a contractor. Laurent Bossavit ruminated on what it would take to do the same for software project.

  • Failure to Learn Stifles Productivity

    Amr Elssamadisy and Deborah Hartmann have written an article asking us to consider that there may be one common attribute to all software development projects that, if focused upon and improved, can make productivity soar.

  • Has Agile Crossed the Chasm?

    Carrying on from last year's survey, Scott Ambler published the 2007 Agile Adoption survey this month. InfoQ provides some analysis of his findings and asks readers how they would approach getting a single view of Agile trends from across the community.

  • Code reuse highly overrated?

    Dennis Forbes bucks the conventional wisdom that has caused the industry to trend toward architectures focused on asset reuse, asserting that code reuse is highly overrated and rarely pans out as advertised.

BT