in reply to Re^3: Beyond Agile: Subsidiarity as a Team and Software Design Principle
in thread Beyond Agile: Subsidiarity as a Team and Software Design Principle

In many cases requirements won't change between beginning on a particular release and the release date, but in many cases they will. Either way, from one release to the next things almost always change. Otherwise, why release again? You actually get fewer of these changes per release if you release more often. That minimizes scope creep during the release.

Also, people who think a UI is not part of the requirements obviously are not responsible for UI or UX development.

  • Comment on Re^4: Beyond Agile: Subsidiarity as a Team and Software Design Principle

Replies are listed 'Best First'.
Re^5: Beyond Agile: Subsidiarity as a Team and Software Design Principle
by chacham (Prior) on Jul 27, 2015 at 13:19 UTC

    in many cases they will

    But what changes? The approach, the rules, or the UI?

    Otherwise, why release again?

    To ensure the team's existence. It is sad how often this is the primary motivator in large companies.

    You actually get fewer of these changes per release if you release more often. That minimizes scope creep during the release.

    Customer fatigue over changes? Customers generally do not like change in their routines. Release more often and they dread any changes that aren't the bare minimum of what they asked for. New releases also tend to break things.

[reply]

      Why give the customer more than the bare minimum they asked for? Why spend more time developing software than you're getting paid to spend?

      If your new releases break things, that's a process problem. Try unit testing and integration testing. Everything that works in the old release should work in the new one.

[reply]
        Why give the customer more than the bare minimum they asked for?

        I understand this is definition issue but communication is often terrible with customers so it invites this theater.

        Customer: I want a door.

        Contractor: Here's your door.

        Customer: It doesn't open.

        Contractor: Oh, you didn't specify that you needed it to open. We'll add a handle.

        Customer: It doesn't lock.

        Contractor: Oh, you need it to lock? We'll add that.

        Customer: We just tried the door. You put it on the second floor without steps. No one can reach it.

        Contractor: Oh, you wanted an entry door...

        The bare minimum the customer orders must be balanced with forethought and good design. I'm not saying you don't know this already. I'm quite sure you do. Just wanted to say that doing more than the bare minimum has saved me a lot of trouble in the past and when it cost more than it returned, the cost was generally quite a lot smaller than the trouble saved in the other cases.

        Update: I meant when it cost me extra, not the customer. I have a strong work ethic and I put in extra time to make things right or above and beyond when I think it needs to happen.

[reply]

        Why give the customer more than the bare minimum they asked for? Why spend more time developing software than you're getting paid to spend?

        In general, teams are paid to support the customer. The bare minimum is not what they are asking for; they are asking for a lot more. As problems arise, they begrudgingly settle for the bare minimum.

        Try unit testing and integration testing.

        Full tests are expensive in both time and resources. Usually, a quick test, if anything at all, is done instead. Unfortunately, for all the teams i've been on, the testing environments were either used for more development or were not actually production-like.

        If we're talking about an ideal environment where things are actually tested properly, why not wish for applications that are actually designed properly from the beginning?

[reply]

In Section Meditations