The Quick Brown Fox

Six weeks of blogging already?! Monday - Finished listening to Agile for Humans 013. Had some good conversations with our coaches.  Tuesday - WebEx changed their loading screen. Started CodeNewbie podcast with their current episode, 154. For reference, the last time I did any Web coding, HTML 4.0 was brand new. I've been doing CodeAcademy courses to get back up to speed on that -- not with any practical application at the moment, but you never know. The problem for me is always that there are so many things one could learn, how to choose? We had a backlog grooming session, which was... okay. Half of one team has been pulling insane hours to put out a fire involving a major client.  Wednesday - Finished listening to the CodeNewbie episode, which I feel contained some excellent advice along with useful information. I'll try to keep up with this one. Got to try to mediate/facilitate a minor clash involving team members getting pulled into other projects. It's frustratingly

So here is a new thing for this blog, and maybe I can turn it into a series, who knows. As I've said many times, I feel strongly that getting your Scrum Master certificate is less an achievement in itself than an announcement that you have begun your apprenticeship. Now that I've been doing the job for a year, while I obviously have a lifetime of learning ahead, I can no longer consider myself a raw newbie. This seems like a good time, then, to start being more conscious about what I've learned so far. The topic of this post is something that I intuited early on was a terrible idea, and while I did object then, it wasn't very strongly. I should have pitched a much bigger fit than I did as a brand-new, part-time Scrum Master.  Team Alpha has five members. Three of them have what I shall describe as high borrow-value. This  is to say that they have expertise that places them in high demand for projects outside their nominal department. Note that they are in high deman

Working software over comprehensive documentation This line seems to me to be the least useful of the bunch, if only because it is so obvious as to seem unnecessary. Software without documentation may or may not be useful; documentation without software is always useless. This line causes technical writers a lot of angst, though, so maybe I will approach it from that perspective as a straddle the career boundary. Part of the angst seems to be rooted in a tendency for people to approach Agile stuff in a restrictive, black and white fashion. Most tech writers being in the business of providing customer-centric documentation of some kind, there's a tendency to think that Agile means getting rid of that wholesale, and I don't think that's what is actually meant. It is fairly common, though, to see "X has more value than y," morph into, "So you don't do y at all then. Good luck with that." Cue rolled eyes. This is of course a straw man; I've y

As expected, this week has been pretty challenging. Monday - Got some unexpected news regarding career planning. That's going to take some thinking about. More candy contributions arrived! I'm happy to see this -- not because of the benefit to me (I would stock the stuff regardless), but because it indicates a level of consciousness about others' efforts that will hopefully manifest within their teams as well. Tuesday - Sprint review and retrospective. I wasn't able to be involved in the individual team retrospectives this time, but one team member approached me to raise some concerns about communication on his (distributed) team. I have some ideas for a few of them, and will probably also discuss them with our coach. My Twitter feed was highlighted in a departmental mailing today, which was a little nerve-wracking to anticipate; however, while a few people responded with positive comments, on the whole it was a non-event. Lesson: Don't sweat. Wednesday - Sent o

I came down with a cold this week, and have been busy preparing for a week on half-time to cover for the spouse's trip. Things might be a bit sparse here. (Indeed, I forgot to post this until Monday.) Team member contributed funds for the candy basket I keep on my desk. (Because Agile = food, as far as I can tell.)  Backlog grooming! This has been a big subject in our retrospectives lately. Unfortunately due to being sick, my energy level wasn't what it could have been for this significant meeting. The stories are not challenging, the business value is frequently unclear (and the teams get tired of asking product owners to provide it), and people are too invested (IMO) in the estimation exercise while at the same time having an unclear sense of how to achieve agreement about those -- or what to do if we can't agree, so as to keep the meeting going. Followed up on a few more items from last week's retrospective.  

Busy week! No wonder I'm tired. Agile Coffee podcast, which happened to be a panel discussion from a recent conference about... how to start a podcast. Not sure if that's something I would ever be interested in. I was disappointed to observe that the entire panel was composed of men.  Also listened to a recent meta-cast on Kanban (a topic about which I know little) and Agile for Humans 012. I have heard Woody Zuill's name, but this is the first time I've listened to him speaking about agile topics. I started 013 but haven't had a chance to listen to the whole thing.  Re-reading The Coaching Habit , which is a decent little book with some good advice (I think). Snapped at someone, apologized, figured out a new schedule that met most needs, punted some additional problems he raised to our coach. If any follow-up discussion happened, I wasn't around to be brought in. This happens, we all move around a lot and seldom schedule things formally.  Sprint review. W