Moving week...
Not much work getting done this week on account of our moving cities. Sounds more dramatic than it really is... at least in terms of the actual distance of the move. For some folks, not familiar with the US's East Coast "megalopolis" that runs from Boston to Richmod, VA (some say it doesn't go farther south than Washington, DC), it may sound odd to say we're "moving cities" when we're really only about 37 miles (59km) from our previous home. Practically speaking, we could have moved the same distance in almost any other direction of the compass and we would have still been in the Washington, DC suburbs. In any case, we've moved from the suburbs of DC to the suburbs of Baltimore (Maryland) for many reasons, though dominated by the proximity of our new home to family.
So here we are, amidst a floatilla of boxes, trying to find our stuff. Thanks to the less-than-spritely response time of the 'big iron' dominant phone power of the region, my voice/data lines don't get installed until the 30th... Right now I'm 'borrowing' bandwidth from a neighbor's entirely unsecured wireless access point. ;^>
I might write about the ordeal of moving, or the games being played by the he-was-being-such-a-jerk-it-was-all-I-could-do-to-not-hit-him buyer's real estate agent on the day of moving/closing/settling.... maybe I'll write something about a funny exchange between my mom and me about our differences in how we value planning vs. priorities vs. rework... but what I hope to do is to find an Agile CMMI thread to this week's events and write about them.
Someday.
I would probably need to find the humor in all the week's stress before that happens.
Stay tuned.
posted by Hillel @ 21:27
4 Comments
4 Comments:
Perhaps the closing could serve as an example of why "Quality Gates" don't really help and why an iterative approach is better?
The basic assumption (at least in every schedule I have ever seen or written) is that the formal turnover reviews are expected to be little more than a check the box, sign the form affair. Should any issues whatsoever arise, it is a train wreck because there is no planned effort to address anything at all. An iterative approach relies on many small scale reviews with planned time for adjustment.
Just to be fair, in my home buying and selling experience, we did have a somewhat iterative approach with a home inspection with findings addressed prior to closing.
Your description of closing, however, brings back some not too fond memories of a document review where a reviewer would not accept diagrams with two headed arrows; they needed to be two single headed arrows. This was especially perplexing as this was an update to an existing document and the diagrams had been accepted as is for years. I deny any knowledge of my team starting unauthorized work on the next phase while I repaired the diagrams.
Interesting analogy.
Ordinarily, the events leading up to closing did have time for iterations, however (and this is where culture may come into play), the buyers wanted 2 things:
1. Without previous notice, to make the 'final' walk through only after the house was empty, and
2. Without coordinating with us, for us to wait until after closing to deal with the utilities. They simply assumed we would/wouldn't take certain steps w/out first confirming with us how things would be timed.
So, even in an iterative situation, an important part of Agile methods is the involvement of the customer as well as following the established norms. Change is 'embraced', let's say, but change still cannot happen unless it's communicated.
Hi Hillel,
I hope my comments came across as intended. My intent was to both commiserate with your problem and provide a hook back into agile.
One key point is that the client has to buy into communications and that is true of both agile and waterfall approaches. Last minute surprises are painful to deal with.
Though my two closings were straightforward, I've had several friends who have had difficult closings on both the buyer and seller side. They all came from a party unfairly bringing in last minute requests that could have and should have been communicated earlier.
I understand your frustration and did not mean to imply that you were at fault for not using an agile approach. The other party has to play ball as well, no matter what.
No worries, I didn't take anything you said as any sort of criticism.
We all know Agile approaches don't well when only one side is participating/ believes in the mindset.
Post a Comment
Subscribe to Post Comments [Atom]
<< Home