Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

comment on

( #3333=superdoc: print w/replies, xml ) Need Help??

Brother eyepopslikeamosquito has written extensively and passionately about the Agile Imposition (1,2,3,4), and I've been thinking about it as well, as my employer has promoted its use in development.

A sprint is planned ahead of time, with stakeholders being consulted on which bugs and features are their highest priorities, with the goal being a correctly working release, delivered on time. Scrums are the daily meetings that let the team keep each other up to date in the current sprint, and also keep the scrum leader and the stakeholder up to speed on what challenges they have.

The scrum area contains a burn-down chart, with the number of days across the bottom, and the number of hours for the total effort on the left side. A straight line is drawn diagonally from the first day and total hours, to the last day and zero hours, showing the ideal burn-down rate. Post-It notes with bugs and features (tasks) that define the sprint are placed in the first section of a wall area waiting to be claimed. The two other sections are Claimed and Finished; as tasks are finished, the burn down chart is update to reflect the team's progress.

But is this the ideal setup? It doesn't cover "production emergencies, high level features that *must* be implemented right away, or when someone is sick" (5) And if the scrum starts to fall behind, should features that were part of the scrum get tossed, just to stick to some ideal release date? (Seeing no way out, I asked the ScrumMaster for advice. He solved the problem simply by removing some features from the Sprint. Well, I couldn't see the point of being ceremoniously asked for commitment if such a commitment could be so easily broken. (4))

I do think the daily meetings are a great idea, but I'm not sure that having all these pieces of paper on the wall are that instructive. I don't have a lot of faith in the burn-down chart -- I get suspicious when the team's ahead, and I worry when the team's behind. And these numbers are based on software developers estimating how long something is going to take. If those numbers are off by 100% (you should be so lucky) your scrum's in trouble, and if they're off by 200% (a task takes 4.5 days instead of 1.5 days, say), the burn-down chart starts to look horror show.

One solution I think would work would be to estimate jobs in ranges of time, but use the rest of the scrum approach. Instead of a knife-edge of "We're on schedule" and disaster on either side, let there be an area of "We're in good-ish shape" in the middle. If there's a reason for a development release to come out on a particular day, then plan to cut development off as that deadline approaches. Don't try to cram in some half-baked code and hope to catch the problem in staging. And if the release is done early, that's fine too -- perhaps the scrum master will start to get a feel for whose estimates are more accurate.

At the bottom, scrums rely on some level of micro-management and on accurate estimates for work required. And I'm not sure that's a good way to develop software.

Comments welcome.

References:

  1. Nobody Expects the Agile Imposition (Part I): Meta Process
  2. Nobody Expects the Agile Imposition (Part II): The Office
  3. Nobody Expects the Agile Imposition (Part III): People
  4. Nobody Expects the Agile Imposition (Part IV): Teamwork
  5. Re: Nobody Expects the Agile Imposition (Part IV): Teamwork

Alex / talexb / Toronto

"Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds


In reply to Thoughts on the Agile Imposition by talexb

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.
  • Log In?
    Username:
    Password:

    What's my password?
    Create A New User
    Chatterbox?
    and the web crawler heard nothing...

    How do I use this? | Other CB clients
    Other Users?
    Others studying the Monastery: (4)
    As of 2021-01-24 16:36 GMT
    Sections?
    Information?
    Find Nodes?
    Leftovers?
      Voting Booth?
      Notices?