Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

Re^5: Nobody Expects the Agile Imposition (Part VIII): Software Craftsmanship

by mr_mischief (Monsignor)
on Jun 15, 2015 at 17:20 UTC ( #1130505=note: print w/replies, xml ) Need Help??


in reply to Re^4: Nobody Expects the Agile Imposition (Part VIII): Software Craftsmanship
in thread Nobody Expects the Agile Imposition (Part VIII): Software Craftsmanship

Scrum, for one agile methodology, is not at all about replacing people with cheaper people. It's all about getting a tighter feedback loop on smaller chunks of work. It's meant to deal with specification drift, scope drift, and people talking past one another about the customers' needs.

Having two weeks or four weeks to deliver a minimum viable product, then increments of the same for new features to be added, is not something one should ask of a team of plug-in commodities. It takes a team some time to work together to even be able to estimate properly what they can deliver in that amount of time. Once the team is built, it should be left in place as much as possible.

The practice of specifying every little thing up front can be handy if those specifications are done well and won't change. If the customer's needs or which needs take priority over other start to drift, then getting that feedback every few weeks becomes really valuable.

  • Comment on Re^5: Nobody Expects the Agile Imposition (Part VIII): Software Craftsmanship

Replies are listed 'Best First'.
Re^6: Nobody Expects the Agile Imposition (Part VIII): Software Craftsmanship
by BrowserUk (Pope) on Jun 15, 2015 at 22:16 UTC
    It's all about getting a tighter feedback loop on smaller chunks of work. It's meant to deal with specification drift, scope drift, and people talking past one another about the customers' needs.

    RAD can and is achieved without the dogma, process-heavy intrusion, and the dumbing down of Agile/Scrum/whatever.

    I've been practicing RAD for nearly 30 years quite successfully. As an individual developer; a lead of a small team; and as the architect of a large team of teams; the practice is essentially the same:

    1. Mock up the top level of the application to provide the application flow, leaving the next levels as apis to be fulfilled.

      The top level can then be demonstrated to the users, feedback taken and adjustments made whilst each of the apis at the next level are being implemented.

    2. Each of the next level apis are treated in essentially the same way. They are initially mocked up in terms of their internal apis.

      Once they are mocked up and compile; they can be plugged into the top level. Which verifies they accept the inputs it wants to give; and returns (mocked) values of the type/order that it expects.

      As each of the apis moves from mocked to implemented; the previous level acts as the test suite for this level; and this level acts as the test suite for the previous level.

    3. If a third or more levels are required; they are started as soon as the previous level has defined its requirements.

      Again, the lower levels are mocked up -- just taking and verifying inputs; and returning plausible values as outputs. Nothing more.

      And as soon as they are able to fulfill the interface to that limited level; they are plugged into the previous level.

    The feedback loops between levels are short; change requirements feed down from the top as they happen; inconsistencies are detected immediately they arise; and are corrected immediately.

    It works for any type of application; no matter how complex; or how large the overall team.

    Individual teams are small, and only interface with those immediately above and below, so the typical humongous status meetings don't arise.

    The design evolves as required and in parallel; loose coupled interfaces are enforced -- but fall out naturally; overnight integration builds tell everyone where things are and what needs immediate attention without all the extraneous process and paranoid navel inspection.


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority". I'm with torvalds on this
    In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked

      So you're building in small pieces with frequent feedback and rapid adjustments? I hate to tell you this, but that is very similar to bespoke agile development.

      I don't think you are against the goals of "agile" or against the principals espoused by the writers of The Agile Manifesto. It seems you share mostly the same goals, and dislike the pomp, ritual, zealotry, and rapacious consulting fees of the training coaches. Well, that's true I think of most people.

      As a method for estimating work and protecting developers from marauding stakeholders outside the team, I think having a company-wide buy-in to Scrum for example is a good thing. It's not going to make your developers produce better software. It just gets them clearer specs and more chance to focus on delivery. They can still deliver utter crap if that's what they are capable of producing and what your customers accept.

        I hate to tell you this, but that is very similar to bespoke agile development.

        That was my point exactly. Except that it was being done for a decade or two whilst the Agile manifesto, and all its derivatives, were just twinkles in the eyes of their evangelists.

        And it doesn't need silly buzz words; uncomfortable meetings; violent transparency or coding by numbers to work.


        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority". I'm with torvalds on this
        In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked

      ... paranoid navel inspection.

      But you still do that in the shower?

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1130505]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (10)
As of 2019-10-22 11:09 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Notices?