- I've moved...
-
My blog has a new home. You can find me at http://ridlehoover.com.
- Ade Miller's New Blog
-
Our resident p&p Brit has moved his blog. You can now find Ade Miller's thoughts here: http://ademiller.com/blogs/tech/.
Check it out.
- Agile 2007: Reaching New Heights - Learning to Adapt
-
In her opening keynote, Susan Ershler told the autobiographical story of her experiences climbing Mt. Everest. It was an entertaining talk. But, relating the subject matter to the Agile community was a bit of a stretch.
The primary message of Susan's talk centered around her tag line: "Project, Prepare, Persevere."
- Project - Envision where you want to be.
- Prepare - Sharpen your saw, stuff your pack, and take a map.
- Persevere - If at first you don't succeed...
Entertaining? Yes. Motivational? Perhaps. Agile? I'm not so sure.
- More to come!
-
I'm still working on my posts summarizing the Agile 2007 sessions. But, I'm also trying to ship some updates to the TFS process templates right now. I'll kept good notes. So, the conference may be a faint memory, but I will get my thoughts up here.
In the meantime, check out this summary of summaries for a bunch more thoughts about the conference: http://www.notesfromatooluser.com/2007/08/carnival-of-the.html.
Enjoy!
- Tuesday @ Agile 2007
-
Tuesday saw the opening keynote by Susan Ershler, as well as the beginning of the vendor talks that I organized this year. Here's the full list of sessions I attended:
Reaching New Heights: Learning to Adapt
by Susan Ershler
Agile Tooling: A Point, Counter-point Discussion
by Ryan Martens (Rally) and Ron Jeffries
Agile Practices in a Distributed Environment
by Michael Vax (Luxoft)
Absolute Agile: Applying the Synergy of Lean and Agile to Enterprise Transitions
by Paul Hodgetts (Agile Logic) and Justin Yaros (Kelley Blue Book)
Empowering Agile Transformation
by Amr Elssamadisy (Valtech)
Agile Adoption at Google: Potential and Challenges at a True Bottom-up Organization
by Mark Striebeck
I also had an interesting conversation with James Shore Tuesday afternoon. More on each of these to follow.
- Agile 2007: The First Thing to Build - Trust on Agile Teams
-
Diana Larsen is a special sort of nut. She's an organizational development and communications expert, not a technologist. Her sessions touch on many of the softer skills necessary to thrive on a team (any team, not just an Agile team).
I've been seeking out and attending Diana's sessions since my first experience with her and her toys back at ADC 2004 when she ran a Discovery Session that explored self-organization. (Speaking of the toys, I didn't see them this year. Where were they, Diana?)
In this session, Diana explored the concept of trust, starting with a quote from Brad Appleton: "The first thing to build is trust." I took several pages of notes during the session. But, of everything, one point stood out for me: individuation.
Individuation is the process of getting to know someone as a person, finding out what differentiates them as an individual. Without individuation, all you have to judge someone are the stereotypes and prejudices that you carry with you. (And, I with me.) In order to truly trust someone, you must get to know them personally.
It seems so simple that it's almost silly. But, I'd never thought about it before. And, it explains a lot about my own behavior and that of others with whom I've worked.
During the course of the session, Diana recommended several books, including:
And, one of the folks at my table highly recommended another, related book:
There was much more to the talk than I'm mentioning here. I recommend looking through Diana's slides if you are interested in more information. The slide on symptoms of distrust (12) is work the click alone!
- Agile 2007: Having Fun with Rails & Agile Development
-
In 90 minutes, Garg, Matt and David built a working web photo sharing web site. Garg played customer. David played whip-cracker (um... PM), and David did all the heavy lifting with Rails.
This talk was a high level introduction to the speed and power of Rails as a development environment. As such, I found most of the material repetitious of other demos I've seen. But, the guys did a good job of showing off the Rails notion of "convention over configuration." They also showed off RSpec and demonstrated the plug-in architecture.
Recommended resources (from Garg, Matt and David):
I would have liked the session to be more hands-on. I'll have to check out the Rails lab for that level of immersion.
- Monday @ Agile 2007
-
The conference is organized a bit differently this year. The only thing going on this morning is registration. So, I checked in and scanned the program guide for sessions I'd like to attend. There are too many good looking talks, this year! I hate that! How can I ever get to see all of them. I'm going to attend the following sessions this afternoon:
Having Fun with Rails and Agile Development
by Barg Upender, David Naffis, and Matt Scilipoti
The First Thing to Build: Trust on Agile Teams
by Diana Larsen
I'll pen reviews in between the sessions.
- Agile 2007
-
I will be attending Agile 2007 in Washington, D.C. next week. In my capacity as Vendor Talks Chair, I will be moderating the vendor talks in Meeting Room 3 on both Tuesday and Thursday.
Drop me a note if you're attending the conference. I'd love to meet you and find out about your experiences with Agile.
- Update: Iterative and Incremental Development
-
I am enjoying the copy of Visual Studio Team System: Better Software Development for Agile Teams by Will Stott and James Newkirk that I picked up the other day. So far, it is doing a good job of both explaining Agile and how an Agile team might use VSTS. They've even gone to the trouble of creating a VSTS process template for XP. Of particular interest to me, though, in light of my recent post, is this bit on IID:
... software is developed in a series of cycles which each deliver some working software (iteration) that builds upon what has gone before (incremental).
Short & sweet - just like I like it!
- Definition: Iterative and Incremental Development
-
Agile software development methods are often described as being forms of something called iterative and incremental development (or, IID). But, what does that mean? I went looking for an answer recently, and was surprised to find a single, simple definition elusive.
Wikipedia defines IID this way: (from Wikipedia: Iterative and incremental development, accessed on 2007.07.25 at 3:00PM PDT)
Iterative and Incremental development is a software development process developed in response to the weaknesses of the more traditional waterfall model.
While true, that definition hardly describes what it means to practice IID.
Craig Larman, in his book Agile and Iterative Development - A Manager's Guide
, defines "iterative development" as follows:
Iterative development is an approach to building software (or anything) in which the overall lifecycle is composed of several iterations in sequence. Each iteration is a self-contained mini-project composed of activities such as requirements analysis, design, programming, and test. The goal for the end of an iteration is an iteration release, a stable, integrated and tested partially complete system.
Now we're getting somewhere. So, the "iterative" in IID means that work is broken into sequential "iterations" that are themselves composed of enough analysis, design, implementation and testing to produce a "partially complete system" that is "stable, integrated and tested."
Larman goes on to define "incremental development" as follows:
Although an iteration can in theory be only for clean-up or performance tuning, usually the partial system grows incrementally with new features, iteration by iteration; in other words, incremental development.
So, the "incremental" in IID means that one or more new features are added to the system each iteration. Let's put it all together to come up with a single, short definition of IID:
Iterative and incremental development (IID) is a process that grows a system feature by feature during self-contained cycles of analysis, design, development and testing that end in the production of a stable, fully integrated and tested, partially complete system that incorporates all of the features of all previous iterations.
So, what should you expect to see when someone describes a process (agile or otherwise) as iterative and incremental? Well, first, you should expect to see the team working in iterations. Second, each iterations should be growing the software feature by feature. And, finally, each iteration should end in the production of a stable piece of software that real users can use. If you don't see these things, the process is not IID.
---
Update: Note that my definition above does not preclude non-agile processes. For example, a team could be doing IID by stringing together multiple miniature waterfall projects. While agile methods tend to use IID, not all IID processes are inherently agile.
- Windows Live Writer Wins
-
Well, my 30 day trial of BlogJet expired recently. I enjoyed using the product. I especially liked the sense of humor embedded in the product. But, in the end, I am just too accustomed to Windows Live Writer to be productive in another tool. And, that's pretty high praise for WLW.
- Spam
-
Due to the number of spam comments I've been receiving (and moderating) lately, I've been forced to limit the length of time that you may comment on a post. I'm hoping this will reduce the amount of time I spend moderating the blog. If you have something to say about an old post and the comments option is unavailble, use the email function to drop me a line directly. Thanks.
- Agile Prioritization
-
Joel Spolsky and Dmitri Zimine mixed it up last November over whether or not to interrupt a team in the middle of an iteration. I'm pretty late to this thread. But, I think I have something to add. So, here goes...
Dmitri started the thread by arguing on behalf of never interrupting an iteration once it starts. Basically, he's just parroting the party line from the Scrum doctrine: Management is not allowed to interfere with the operation of a team during a sprint. If they do, the team can cancel the sprint.
Joel countered that you should consider the nature of the interruption before blindly preventing it. He argues in his inimitable way that the financial independence of the individuals involved could very well be at stake. He may as well have been yelling: "Take door number 3!"
What both guys missed is that they are arguing the opposing sides of a pendulum, and that the real truth probably lies somewhere in the middle. (Ironic considering the tagline on Dmitri's blog.)
Here's my advice when faced with the decision of whether or not to accept new work after an iteration has started:
- Take five minutes to estimate the newly requested work.
- Communicate this estimate to the person who requested the change in scope.
- Explain the concept of velocity (if necessary).
- Ask them to stack rank the new work into the remaining backlog of unfinished work for the current iteration.
There, now. Everyone has visibility into the process. And, the person in the best position to make the call as to priorities - the one who knows both the benefits and (now) the costs of swapping in new work - is the one responsible for making the decision. That's what I call Agile Prioritization.
For further study, I recommend that Dmitri and Joel (and everyone else) read Mike Cohn's excellent book: Agile Estimating and Planning.
- CNN International was just here...
-
A CNN International crew from Hong Kong was just here filming the patterns & practices agile development space. They were working on a feature program called Global Office. They filmed me while I pretended to be reading email on Peter’s laptop while sitting in our lounge. Thank goodness I wore some decent clothes today! I just wish I’d shaved.
No word on whether or when the footage will actually air in the US. If I hear something I’ll pass it on.
