Over the last eight years, a lot of us have gotten leery about those who, for whatever reason, are prone to mispronunciation. In fact your experience might lead you to believe that it’s a general rule that those who mispronounce words are also sort of lacking in education or intelligence.
Don’t believe it for a second.
I just finished the two-day Construx seminar Being Agile Without Being Extreme, and the instructor, Jerry Deville, is as sharp a tack as I’ve seen in a long time. He also has the advantage of bringing an authentic Louisiana accent into the classroom, and I am now and forever cured of the notion that the occasional mispronunciation has anything to do with capability.
Jerry comes from a background with the U.S. Air Force and Boeing, among others, which wouldn’t immediately remind you of “Agile software development organizations”, but he’s been doing real-world consulting for however long and believe me, he knows his stuff.
So – about the seminar.
It was targeted at the technical program manager crowd, and in Day 1 covered the questions What is Agile?, “Why Agile?” and “How Agile Should We Be?”.
- Jerry was persistent in explaining that it wasn’t a question of Agile or Not Agile, but rather that there is a continuum of SDLC practices, with Pure Agile on one end and Pure Waterfall on the other, and most organizations will fall somewhere in between those two, depending on your particular situation.
- There was a nice discussion of the distinction between agile methodologies (think Scrum) and agile practices (think pair programming, or continuous integration). Even if your organization doesn’t let you do a big-A Agile methodologies, you can still incorporate the practices and get some benefit.
- One of the things I liked was the continuous cross-referencing and repetition of certain key concepts, such as short cycles, feedback loops, and what commitment means. Jerry’s a gifted instructor.
- I had a little disagreement with Jerry’s definition of quality – he says that the product should be at “Near Release Quality” (NRQ) all the time, and he defines NRQ as “able to launch within one more sprint”. That may be true for commercial shrinkwrap software, but anything web or internal should be much closer to release quality than that, in my opinion.
- Great discussion of value – he broadened the definition of value to include things like regulatory compliance, documentation, technical debt, etc.
- Lots of good discussion about the role of requirements in the Agile process. Jerry makes the claim that Agile has only recently begun to be able to tackle super complex or mission-critical applications because of the relative lack of focus on requirements gathering in most Agile methodologies. He makes a good case.
- Good treatment of common agile themes such as barely sufficient, last responsible moment, progressive elaboration, and “emergent design“.
- I loved how Jerry focused on the need to ALWAYS deliver value in every sprint.
- Nice treatment of various ways to break up work, with a hands-on lab to demonstrate the concepts.
- Good discussion on release planning and sprint planning, and what your goals are at each level. It was in this section that I experienced a sour note – I come from a background in XP, one value of which is honesty. If your organization is such that you’re required to pad sprints with important-sounding items that are ultimately just backstops for problems with your business, your organization has a problem that Agile can’t fix.
- I was blown away by the discussion of formal user stories, not having used them myself in the past. Ironically, my boss just gave me a book to borrow called “User Stories Applied” so I’m really eager to dive into that book.
Day 2 started off with a continuation of the previous day’s discussion on quality, and got deeper in the details of common Agile practices, like pair programming, refactoring, coding standards, etc.
- Good discussion of estimating techniques and goals, including a hands-on Party Poker lab.
- Jerry’s a big proponent of fixed iteration sizes – for ease of subsequent math. It seems to me that this has it backwards – you should find the optimal point at which the benefit/cost ratio is the highest, for your organization. I know I’m omitting some of his argument, but we didn’t get into the weeds of “What is the optimal iteration size”. The net of it was: experiment. Pick a size, see if it worked, wash, rinse, repeat.
- Lots of discussion about the soft aspects of the SDLC in general – the peopleware part. Jerry has got tons of good experience-based advice and guidelines here.
- Good discussion about how to handle interruptions, distractions, patches, etc. that your team will inevitably be subjected to.
- Good introduction to the Scrum Burndown worksheet. Looking back, I wish that we’d gone into more detail with that section, but Agile project tracking could be a seminar all to itself.
- Excellent advice about how to set up and run a project retrospective. I’ll be putting that advice to use right away.
Jerry’s a great teacher. He’s as widely read in the field as anyone I’ve ever personally met, and has the real-world experience to tell you what works, what doesn’t, and why. The other students in the class were engaged, thoughtful, and eager to bring up questions that allowed us all to see how the information on the slide could be applied in our own domains.
Even though about 90% of this information was familiar to me, I still picked up more than enough to make this time well spent. I’m doubly motivated to go make this stuff work in practice (even more than currently, and the team I’m on is doing pretty well right now).
I’m very impressed with Construx and with Jerry Deville in particular and recommend that you take a look if you’re considering starting or expanding into Agile at your company.
My one regret? I tried to get a picture with me and Steve McConnell, whose book Code Complete was the first great software book I ever read, but my iPhone camera didn’t record the photo. Bummer.