In Pursuit Of (Or Recovering From) An Encounter With The Leannan Sidhe

Managed to make it out for the fête last night for an hour. Saw several wunnerful people whom i haven't seen forquite a while, even managed to fail to recognize someone i should have known. Bah- i fail! It's nice to observe the social elite from arm's length, and prncsmoonbeam holding court is truly remarkable to see, even if most of the assembled gentry in their finery were people i didn't- or only barely knew. Staying any longer would just have ensured that morning came far too early.

Serotonin levels seem to be rebounding- yaaaay for better living without psychopharmacology. And for the concomitant levels of feeling better in general.

Work continues to show promise. Maybe this time we're going to stop cobbling one layer of fixes onto another making a hideous patchwork over something which was broken in the first place and actually start doing things properly. It'd be about time.

A most joyous of natal anniversaries to ithilien. :-)

Today ended up being a nine and a half hour workday because someone made me a mandatory attendee at a meeting from 4-5:30. Since I don't take lunch out and generally get in at 8ish in the morning, i leave around 4, which makes it possible to miss much of the traffic on the way home. Leaving at 5:30 pretty much ensures i hit the point where even the express lanes are at a near-standstill.

Even worse, it was a stupid-ass meeting. If director-level personnel are going to make policy decisions, they owe it to all the people who report to them and with whom they work that they know what the fuck they're talking about. By request, i brought a Visio diagramme which i spent nearly three hours of my day working on, mapping out the path reported incidents take from the point they're brought to light until they're fixed. So, of course, they decided to ignore the first two of the four columns of the workflow chart, and most of the fourth just to focus on the triage aspect. They can't decide whether we need to have triage meetings twice a week or only once. Course, they didn't have a clue how many issues get routed through the system in a month in the first place. For the record, for the month of August, there were seven issues routed to our triage queue, four of which were five minute fixes i did myself (which required fixing bad data, but no code modifications), one of which will be deferred indefinitely, and two of which are extensions of existing functionality.

We've been handling these for the last year in pretty much an ad hoc manner- for the most part, there aren't enough to require a formal process. The general structure of the department is built around two Microsoft frameworks- MOF, the Microsoft Operations Framework; and MSF, the Microsoft Solutions Framework; with the Agile methodology loosely applied on the MSF side. My position boils down to the intersection between the two, so I have to know both. My existing process for delivering user-requested changes can very easily be stated in MOF/MSF terms, and the 'Agile Manifesto' elements apply as well- it's about as streamlined as it can be considering i can't fix any code problems.

To make a long story shorter than it could be (since it's already starting to grow), the fixing stuff efficiently part of what i do is now technically separate from the triage process. It's still something i have to do/get to do, but apparently it's important to them to reclassify it as tertiary technical support. Intriguingly, i'm now supposed to both consult the development teams before touching anything within their demesnes, but also not supposed to interrupt developers during their work weeks. Exactly how the fuck i'm supposed to manage to do both simultaneously baffles me. What it'll boil down to is that i'm going to continue to do the same damn things i'm doing now, but once a week we'll all sit down and the business analysts on the two main development teams will tell me that they'll prioritize any new requests for change in their weekly planning meetings in a formalized, post hoc ergo propter hoc meeting rather than in an as-needed basis.

Stupid waste of my time. Style over substance is pointless, especially when there's damn little substance to begin with in what the development teams accomplish with regard to fixing user-reported incidents. Sometimes i wonder why i care still.

It has been a while since you've had to deal with a work rant from me, so scroll past if you wish.

I'm still having big doubts about the functionality of the Agile methodology, at least in our environment. Perhaps it can work in places where the needs of the business are well planned out and prioritization is all that needs to happen. We certainly don't fit that description.

We're now in a position where we have to deliver an amount of functionality. We thought we had a fair grasp on how much that was, only to have it grow three orders of magnitude in our Monday planning meeting.

So, development has some initial user stories to work on this week. Good for them. Unfortunately, the scope of them is mainly "stub out the presentation layer for this new page" "stub the business layer for this page" and so on. The scope of things which is testable for them is roughhly "yup, there's a page there."

We need to reach some level of full ownership in this project, because we're in danger of repeating the problems of the last one and reinventing the square- we're going to go from a point where test may have all of a half-hour of work (as will probably be the case this week) to points where several of these pages which are now being stubbed will be completely functional all at once, resulting in seventy or more hours of testing needing to be crammed into one week. I'd note that this is one of the things which is allegedly contrary to the methodology- which claims to deliver (citing from the principles of the methodology) "Agile processes promote sustainable development. The sponsors, developers, and users should be able
to maintain a constant pace indefinitely" or which writes test out of the bigger picture of what constitutes development altogether. As it is, there's nothing consistent other than that test gets regularly screwed. If that's going to happen, i'd rather deal with a good ol' fashioned waterfall deathmarch- at least with those, there should be some specifications and planning documents which let me write test planning in advance.

Full ownership may be the only thing which saves it, thinking logically. If I can get the development process to unify all the user stories related to a particular aspect of the whole and prioritized by aspects, and aspects completed before the next ones are completed, it may be sustainable. I'm not going to hold my breath waiting, though- cyanotic blue doesn't look good on me.