Loading ...
Sorry, an error occurred while loading the content.

Re: Scrum, and Revolution

Expand Messages
  • Kay
    Rob, this is exactly the kind of thing I wanted... Thanks so much!! Kay
    Message 1 of 167 , Dec 28, 2012
    View Source
    • 0 Attachment
      Rob, this is exactly the kind of thing I wanted...

      Thanks so much!!

      Kay

      --- In extremeprogramming@yahoogroups.com, "Rob Myers" <rob.myers@...> wrote:
      >
      > Kay,
      >
      > --- In extremeprogramming@yahoogroups.com, "Kay A Pentecost" <tranzpupy@> wrote:
      > > > Most of my first-person XP success stories involve avoiding horrors, so
      > > > I'm not sure if they meet your criteria.
      > >
      > > I was thinking of problems that existed before implementing agile practices,
      > > that the agile practices solved... but success stories are great, too.
      >
      > Ah, okay. Let's see, I started programming for a living around 1984...
      >
      > In 1997 I was looking for a way out of the software industry. I was disillusioned in so many ways. Then in 1998, our team was abruptly introduced to Extreme Programming, and I haven't been the same since! :-) So, problems that Agile has solved for me:
      >
      > 1. Top of my list is TDD, a technique that encourages us to write the other half of the problem/solution equation, thus making sure our solution solves the right problems, and continues to do so in perpetuity. What it did for me is provide safe refactoring, so I could update functionality without having to ruin my design with ugly retrofitted code. The old way, trying to carefully retrofit by creating entirely separate code-paths, was either challenging to maintain later, or was error-prone. Or both.
      >
      > 2. Given #1 above, we could allow Product folk to alter the trajectory of the product and respond to market forces. This was invigorating for everyone, and allowed for stratospheric levels of innovation. Since we could build and demonstrate working software incrementally, we avoided what I had seen in the past: We'd get the whole thing completed, and have the client cancel on us.
      >
      > I even had one client pay the whole invoice after telling my team that they could no longer use what we had spent a year building for them (an elaborate, mainframe-driven coast-to-coast HyperChannel remote printing protocol). We were at the client site installing the software when they told us. Was that a success? Even though we were paid in full, I call it a failure. Great development teams want to know their software is being used to provide value.
      >
      > With Agile, we can know within two weeks, not 12 months, whether or not we're on the right track.
      >
      > 3. Working in collaborative teams, rather than separate offices, allowed many of us to discover that we knew more than we thought, and that it was okay to not know something, because you could learn on-the-job from your peers. E.g., I had taken early "OO" courses, which taught the "subclass-to-improve" aka "subclass for specialization" school of OO design, which was a big load of horseplop. By pair-programming, we quickly noted that good OO was mostly common sense, and--behold!--GoF Design Patterns emerged from merciless refactoring and were identified with the help of our wise XP coach, Fred George.
      >
      > Contrast that with sending me to a security and encryption conference in the mid-90's, where I learned about Kerberos and RSA public-key encryption. I returned excited with my new-found knowledge, of course. The only use I got out of it was a lingering awareness of the foolishness of password-based security and algorithmic "randomness."
      >
      > 4. Doing things the "Agile" way showed us very early on how crappy some of our dev tools were. In 2001 we started with JBuilder, which was--at that time--a challenge. We discovered IDEA, which seemed to be uniquely tuned to Agile development. In many other areas, Agile teams have encouraged, or built, replacement tools that are not themselves bottlenecks to real productivity: Resharper, Rails, Cucumber, SpecFlow, Git, et cetera.
      >
      > > > http://www.quora.com/Does-test-driven-development-TDD-really-improve-
      > > > software-quality/answer/Rob-Myers
      > >
      > > Unfortunately, this site wants me to sign in with Facebook or Twitter, and
      > > I'm limiting my connections to Facebook & Twitter. I'd love it if you could
      > > send me a copy....
      >
      > Here's the text from my Quora answer. (Who knows when the blog post will get done... ;-)
      >
      > <quote>
      > TDD provides lower defect rates, higher productivity, and a much more
      > logical and fun technique for us scientifically-minded problem solvers.
      >
      > I've worked on at least 5 projects as a TDD developer and XP coach (before moving to more general Agile coaching and training, including TDD training). The reduction in the amount of bugs we saw vs. non-TDD projects was astounding. In the 2001 project, we saw perhaps one defect per month reported from the field, and we had customers in the US, Canada, Japan. Most were found and fixed (forever) in one iteration.
      >
      > The 2002 project was a life-critical (i.e., "You make a mistake, someone may die") rewrite, and I don't recall a single business-logic bug (I recall one PDF formatting complaint) in over a year. We found more bugs in the old legacy product (the one being rewritten) by using its reporting results as input to our acceptance-test cases, and manually comparing failures.
      >
      > And on and on.
      >
      > Those who say it's slower are looking only at the early results, and early challenges. If I were building a tiny app that I never expected to have to support, I might not get the ROI from TDD. But then, I don't think the VCs would expect any ROI either.
      >
      > After months of comprehensive microtesting and merciless refactoring, teams often find a story in their queue that would have otherwise taken them months to build, but it takes mere days.
      >
      > In my own, first-person experience:
      >
      > * Convert a suite of web apps to internationalized input and output after over a year committed to only one character-set? Three days.
      >
      > * Add a functioning "Display in PDF" button to every one of a hundred HTML reports after having committed 6 months to HTML-only? Three days.
      >
      > * Re-purpose a hand-crafted FoxPro-to-Oracle schema-and-data conversion tool to convert another department's database on-demand and feed those results into that department's separate report-generator at a savings of hundreds of thousands of dollars per year? Two days.
      >
      > A lack of comprehensive, automated, fast regression tests is one of the top three or four reasons why Agile projects fail. Of course, TDD is not a silver bullet, but it solves so many challenging problems. It's one of the first Agile engineering practices I would put into place on any Agile team. (To do otherwise would be unprofessional, irresponsible, and, in some cases, dangerous.) If someone finds a better way, I'll try it. But I've been
      > programming for over 30 years, and until something truly better comes along,
      > for me it's TDD or the highway: I'm not one who can stay and watch
      > people suffer needlessly.
      > </quote>
      >
      > Take care,
      >
      > Rob
      >
      > Rob.Myers@...
      > Twitter: @agilecoach
      > http://www.agileInstitute.com/
      >
    • Tom Rossen
      Rob, Thanks for your kind offer. I am currently gainfully employed - until Feb. 2, when my current contract runs out. Northern Trust renewed it as many times
      Message 167 of 167 , Dec 30, 2012
      View Source
      • 0 Attachment
        Rob,

        Thanks for your kind offer. I am currently gainfully employed - until Feb.
        2, when my current contract runs out. Northern Trust renewed it as many
        times as they could, but there's a hard limit of 1.5 years.

        Re the high-performing teams: it's funny, but I really think I prefer
        working with an organization that's struggling with Agile. I'm extremely
        curious as to why XP practices, which seemed so obvious and satisfying when
        I first read Kent Beck's book years ago, are so frustrating for developers
        and managers who aren't used to them and didn't volunteer for them. I was
        rather seriously burned on my previous engagement when the company was
        acquired by a conglomerate and the policy of openness to Agile suddenly
        evaporated, so my insistence on TDD - which no longer seems as doomed as it
        would have been just a year ago, based on what I'm seeing now in the
        Chicago area - is protection against that sort of thing.

        So I'm curious about the high-performing teams you mention - at least in
        the Chicago area: I don't intend to relocate or commute a long distance (I
        worked in Madison, WI for several years after the dot-com-bomb wiped out
        the Chicago market - not a fun commute).

        Tom


        On Fri, Dec 28, 2012 at 2:30 PM, Rob Myers <rob.myers@...>wrote:

        > **
        >
        >
        > Tom,
        >
        > Thanks for the supportive reply!
        >
        >
        > > 35 years in my case, and amen! Here's a snippet from the cover letter
        > I've
        > > been sending out recently:
        >
        > Tom, if you are not currently gainfully employed, I can point you to a few
        > truly high-performing teams across the country. They are in the minority,
        > as most software/IT organizations struggle to change those
        > command-and-control cultures, and to foster passion and creativity in both
        > Product and Development areas.
        >
        > > *I just thought of an analogy to explain why I am so single-minded about
        >
        > > TDD. Suppose you need an operation and you're looking for a hospital to
        > do
        > > it. A major hospital sends you a wonderful brochure explaining how
        > > successful they are, what a high-tech surgical suite they have,, etc.,
        > etc.
        > > But when you call up and ask them whether the surgeons wash their hands
        > > before operating, they say, "Why would we want to do that?" Oh yes,
        > > surgery was practiced for centuries before surgeons ever scrubbed up -
        > it's
        > > a great tradition. But I don't think you'd want to have anything to do
        > with
        > > a hospital like that. That's how I feel about TDD. It's a matter of
        > > funda**mental
        > > software hygiene. *
        >
        > It's a perfect analogy. Scott Bain uses this in his book /Emergent Design/
        > as one example of how software development is similar to surgery. (Aside:
        > Apologies if I popped an original-idea bubble: So often I find I think of
        > something original, only to spot it in a blog post the next day. It's the
        > Newton-Leibniz Effect ;-) The medical field provides an analogy that gets
        > us much farther than bridge-building. Of course, no analogy is perfect, but
        > I often find myself thinking "Doctor, it hurts when I do *this*!" ;-)
        >
        > Happy Holidays!
        >
        >
        > Rob
        >
        > Rob.Myers@...
        > Twitter: @agilecoach
        > http://www.agileInstitute.com/
        >
        >
        >


        [Non-text portions of this message have been removed]
      Your message has been successfully submitted and would be delivered to recipients shortly.