Beefy Boxes and Bandwidth Generously Provided by pair Networks
Come for the quick hacks, stay for the epiphanies.
 
PerlMonks  

Thoughts on the Agile Imposition

by talexb (Chancellor)
on Dec 11, 2010 at 19:45 UTC ( [id://876626]=perlmeditation: 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

Replies are listed 'Best First'.
Re: Thoughts on the Agile Imposition
by GrandFather (Saint) on Dec 12, 2010 at 01:31 UTC

    Sounds like you are looking for something close to the way we manage projects at work. We start with a Software Requirements Specification which is mostly a non-technical list of features that may be included in the project and is signed off on by the team manager after consultation with the stake holders. It is the stake holders who provide the requirements in the first instance. The key to the SRS is that it lists three categories of requirement:

    1. Essential: Items that must be completed and will push out the completion date if need be.
    2. Conditional: Items that can be dropped to meet the completion date.
    3. Optional: Items that can be included if the project is running ahead of time.

    The key here is that project should be scheduled so that the essential items will almost certainly be completed on time and allowance should be made for the conditional items in the schedule.

    The difficult part of course is the scheduling, but it is something that you get better at with experience. In our experience at takes between one and two years before you get fairly good at scheduling. We've been doing this for about five years now and my manager reckons that our schedules now are generally right within about 10%! That doesn't mean that every item in a project schedule is right within 10%, but that over the course of the project we hit the time within 10% of the scheduled time.

    We do do the scrum thing. We do have a project supervisor for each project who is the person responsible for overseeing the project. We do not a allow additions or alterations to the SRS without reassessing the project's schedule. The SRS is a great tool for waving in the face of the stake holders and saying "This is what you signed up for. If you change your mind we will alter the schedule to suit.". It turns out to be a powerful document that we don't need to use in that way very often.

    After we have sign off on the SRS the project team leader prepares a specification document which is technical and provides the detail required to guide the implementation of the project. This document is for the team only and tends to be rather mutable. If the specification document turns up issues that weren't foreseen in the SRS, we go back to the stake holders and sort the issue out up front.

    True laziness is hard work
Re: Thoughts on the Agile Imposition
by eyepopslikeamosquito (Archbishop) on Dec 11, 2010 at 23:52 UTC

    Don't try to cram in some half-baked code and hope to catch the problem in staging.
    Indeed. This should be covered by your Definition of Done. I strongly recommend that your team tape their "Definition of Done" to their Scrum board -- and get buy-in from the Product Owner.

    Now comes the tricky bit though. In many organizations, the ScrumMaster and the team come under intense pressure to ship from the stakeholders, the product owner and upper management. Do they buckle and distort the meaning of "Definition of Done" to save face, please the stakeholders, and perhaps even save their jobs? Or do they have the integrity to openly admit that they mis-estimated, hit unforeseen problems, and no, they are not done yet -- and that it is not sustainable and not in the company's best interests to keep accumulating Technical Debt like this. Whether that happens or not in practice depends principally on the personal characteristics of the ScrumMaster in my experience. A clueless ScrumMaster won't even know whether the team is being truthful re Definition of Done.

    Scrum co-founder Ken Schwaber highlighted this "ScrumMaster Problem" in a Google tech talk:

    You will have, if you use Scrum, someone on each team whose name is, it's called the ScrumMaster, also known as "The Prick". And this person's job is to make sure that you don't cut quality. D'oh. And they have no authority but they, what they can do is if we've defined that an increment has a certain level of quality for it to be demonstrated to our product management, their job is to make sure that quality's there. And if the quality isn't, not to let you demonstrate it, but instead to say to the product manager, "Hmph, we lost our heads, we're not done, it's gonna take us another month to finish this".

    This person is probably the least loved person in the world because they stand right at the nexus between product management believing that any amount of stuff can be done and our willingness to help them cut quality to support that belief.

    The burnout rate on these people is usually, like, 13 to 14 months. Throw 'em away. We often get them from hopeless, professional areas like QA. People in QA are used to doing incredible things with no authority, no respect, and no hope of success, so that's where we take these people.

    -- Ken Schwaber, Google tech talk on Scrum, Sep 5, 2006 (46:34)

Re: Thoughts on the Agile Imposition
by eyepopslikeamosquito (Archbishop) on Dec 12, 2010 at 00:41 UTC

    It doesn't cover production emergencies, high level features that *must* be implemented right away...
    Scrum works best when the team cannot be interrupted. If your organization does not have that luxury (i.e. if you don't have dedicated support teams to handle production emergencies), I suggest you abandon Scrum and switch to Kanban instead. The definitive Kanban reference is this Kanban book by David Anderson. FWIW, I've used both Scrum and Kanban and, like The BBC, much prefer Kanban.

Re: Thoughts on the Agile Imposition
by Anonymous Monk on Dec 11, 2010 at 23:44 UTC
    I have doubts any time ideal, burn-down, Post-It, scrums, imposition... appear on the same page.

    A little later I read there is a ScrumMaster and I no longer doubt the Masters of Disaster had something to do with it. Not MoD from the comic book, but the fictional cyberhacker gang from that #1 NY bestseller circa 1990 something ... and they're all masters of squatting weasel style kung fu

Re: Thoughts on the Agile Imposition
by sundialsvc4 (Abbot) on Dec 13, 2010 at 21:11 UTC

    One of the most interesting projects I ever did was for a city in Arizona ... refurbishing the database that they use to track routine projects like, say, the repaving of a section of city street.   First of all, you’ll be stunned to learn exactly how much those projects cost.   Second, you will also be stunned to be presented with a break-down list of projects (most of them subcontracted out) which might be several hundred line-items long.   All this, “just to repave a street.”

    Now, you might argue, “but everybody knows how to repave a street ... this is (tahh dahh!!) software development.”   And to this I would but reply, “horse-(!).”

    By now, the world has witnessed hundreds of thousands of software development projects, both big and small.   We actually know very well how to design and execute them.   It is, or it should be, a robust and repeatable process.   Like putting in a new street where no street has gone before.

    We grant college degrees in “software engineering,” but that does not mean what “civil engineering” means, nor “mechanical engineering.”   There is no professional licensing and certification.   Perhaps this is part of the reason why so many things that we build, fall down.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://876626]
Front-paged by Arunbear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others musing on the Monastery: (4)
As of 2024-03-29 10:39 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found