Friday, June 17, 2011

Using Agile Practices to Create an Agile Presentation

What’s the best way to make a presentation on Agile practices? Practice Agile practices.

You could write a presentation “big bang” style, delivering version 1.0 in front of your big audience of 200+ people at Kscope 2011 before anybody has seen it. Of course, if you do it that way, you build a lot of risk into your product. But what else can you do?

You can execute the Agile practices of releasing early and often, allowing the reception of your product to guide its design. Whenever you find an aspect of your product that doesn’t get the enthusiastic reception you had hoped for, you fix it for the next release.

That’s one of the reasons that my release schedule for “My Case for Agile Methods” includes a little online webinar hosted by Red Gate Software next week. My release schedule is actually a lot more complicated than just one little pre-ODTUG webinar:

2011-04-15Show key conceptual graphics to son (age 13)
2011-04-29Review #1 of paper with employee #1
2011-05-18Review #2 of paper with customer
2011-05-14Review #3 of paper with employee #1
2011-05-18Review #4 of paper with employee #2
2011-05-26Review #5 of paper with employee #3
2011-06-01Submit paper to ODTUG web site
2011-06-02Review #6 of paper with employee #1
2011-06-06Review #7 of paper with employee #3
2011-06-10Submit revised paper to ODTUG web site
2011-06-13Present “My Case for Agile Methods” to twelve people in an on-site customer meeting
2011-06-22Present “My Case for Agile Methods” in an online webinar hosted by Red Gate Software
2011-06-27Present “My Case for Agile Methods” at ODTUG Kscope 2011 in Long Beach, California

(By the way, the vast majority of the work here is done in Pages, not Keynote. I think using a word processor, not an operating system for slide projectors.)

Two Agile practices are key to everything I’ve ever done well: incremental design and rapid iteration. Release early, release often, and incorporate what you learn from real world use back into the product. The magic comes from learning how to choose wisely in two dimensions:
  1. Which feature do you include next?
  2. To whom do you release next?
The key is to show your work to other people. Yes, there’s tremendous value in practicing a presentation, but practicing without an audience merely reinforces, it doesn’t inform. What you need while you design something is information—specifically, you need the kind of information called feedback. Some of the feedback I receive generates some pretty energetic arguing. I need that to fortify my understanding of my own arguments so that I’ll be more likely to survive a good Q&A session on stage.

To lots of people who have seen teams run projects into the ground using what they call “Agile,” the word “Agile” has become a synonym for sloppy, irresponsible work habits. When you hear me talk about Agile, you’ll hear about practices that are highly disciplined and that actually require a lot of focus, dedication, commitment, practice, and plain old hard work to execute.

Agile, to me, is about injecting discipline into a process that is inevitably rife with unpredictable change.
at

5 comments:

  1. asliwxJune 28, 2011 at 7:18 PM

    Cary,
    Thankyou for your great insights...
    Do you think that the method-r approach of "incremental design and rapid iteration" is the similiar to iterative process Eli Goldratt
    5 FOCUSING STEPS OF TOC?

    ReplyDelete
  2. Cary MillsapJune 29, 2011 at 12:42 AM

    wasque: Yes, absolutely. And it's no coincidence. Studying Goldratt's The Goal was a tremendous source of inspiration for Method R. My familiarity with Goldratt's optimization work made my mind more receptive to the Kent Beck's Extreme Programming Explained, which I regard as a profound step forward in optimizing the process of creating excellent software.

    ReplyDelete
  3. GarySeptember 7, 2011 at 4:44 PM

    This makes me think about creating "user stories" for the audience members.

    ReplyDelete
  4. asliwxSeptember 20, 2011 at 2:53 PM

    Cary,
    ".not very impressed with Cary Millsap, as there is a tendency to oversimplify and use unfounded axioms to draw conclusions…

    Not good science"

    I got this response from one of my fellow performance engineers ... We were discussing how it is possible to make performance worse when you optimized the IO subsystem...

    With the introduction of a
    five-times-faster CPU, the batch jobs ran faster. But
    because they cleared the CPU five times more
    quickly, batch jobs issued disk service requests more
    quickly. The intensified competition for disk I/O
    service made the users’ already existing bottleneck
    even worse, making their workdays miserable compared
    to what they had before the upgrade.

    http://method-r.com/downloads/doc_download/17-performance-management-myths-a-facts

    I 'resistence to change' ....
    any ideas

    ReplyDelete
  5. Cary MillsapSeptember 20, 2011 at 3:25 PM

    wasque,

    Thank you for your note.

    The part about trying to make someone impressed with me may be unwinnable :-). It's not the right battle anyway. If the argument is whether upgrading a component can ever make performance worse for a selected task, then I suppose the best way out is to create a reproducible test case. There are several choices of how to do that.

    I documented one case (case 1) in chapter 12 of Optimizing Oracle Performance. Admittedly, that's a case only half-documented because we didn't have access to the before-upgrade profile, but it is a great example of the phenomenon happening in the wild. If your colleague would regard any evidence I can provide as inadmissible, then you might find other authors who have written about it. The effect is quite disturbing when it happens; surely someone has written about it.

    (Note: I'd strongly recommend for you to prioritize the work that Jeff and I did in the Optimizing Oracle Performance book ahead of the "Myths & Facts" paper that I wrote in 1999.)

    You can model it. For example, you might use MVA or Neil Gunther's PDQ to show how the effect can happen.

    You can simulate it. That would require some real work, but I think it would be fun. Create a program P that spends time at two resources, say, 90% at R1 and 10% at R2. Create another program PB ('B' for background) that consumes time 10% R1 and 90% R2. Run several copies of PB concurrently while trying to run P. Profile P. Then make the PB calls to R2 take half as much time each (keeping the call count constant). That will increase load on R1 by intensifying the arrival rate on R1, which is where P is struggling to begin with. Profile P during this load, and it will require more elapsed time to get the attention it needs from R2, which will be busier and therefore drive more queueing.

    Or, you can test using two systems, one with a faster CPU than the other. By concocting some mixed workload (tasks representing at least two different profiles, like in the "simulate it" idea above), you ought to be able to show off the problem.

    I hope these ideas can help you... Maybe just the act of thinking through how you'd construct the demonstration will make it clear to your colleague how the effect occurs.

    Cary

    ReplyDelete