One of the best things I budgeted for this year was a new projector for my team. For some reason we require anyone who wants a projector to reserve one at least 24 hours in advance for a specific conference room. Maybe I don’t have a lot of patience, but I found I was constantly begging for a projector the day of a meeting and feeling guilty about it. It was really a pain.
My predecessor obviously felt about the same way as I inherited a projector when I arrived. One small issue was that it only worked on rare occasions and was out of warranty. Fixing it was possible, but easily it could be the same cost as buying a new projector.
So I budgeted for a new projector this year and had one of my developers research and buy one in October. I knew we’d get enough use out of it in my group alone to justify the cost from using it for demos to unit testing seminars. The elimination of the hassle was reason enough.
My general philosophy is to share even if some item came out of my cost center. I also think the idea of trust is really important so I just stow the projector in my old office and not under lock and key. I think the hassle of having to lock up things and have sign out procedures generally means things get a lot less use. Not too different from the idea that requiring a lot of paperwork and receipts for small expenses ends up costing the company more in tracking costs then just setting a per diem for incidental expenses.
As people have discovered I have a projector they often just stop by and ask to borrow it. I happily lend it out no paperwork involved. The projector gets a lot more use, and I generate extra goodwill by making things easier for people. Of course the obvious downside is that someone might, gasp, steal the projector. I think positive effects far outweigh the possibility of some really dishonest employee walking off with it. If your company has theft problems you generally have a much bigger issue on your hands.
I’m into the second week of holding half hour one-on-one sessions with all of my folks. Today is my big day on Wednesday afternoon where I actually hold six one-on-ones from 1:00-4:00. At least half of the one-on-ones today began with the statement:
“Hmm, I really don’t have anything to talk about this time, so I don’t know what we’re going to talk about for half an hour.”
Every one of those one-on-one sessions today went the full 30 minutes and a few I had to cut off to make time for the next session. I distinctly remember this because my bladder was letting me know it could use a little restroom break, but from 1-4 today it was wall to wall one-on-ones.
This week felt a bit more laid back. People are starting to get adjusted to the style and I’m probably a bit more relaxed. So I’m beginning to see why I should have started these a long time ago.
Today I spent pretty much the whole day leading a Sprint Planning Meeting as the ScrumMaster. This is the first time I’ve gotten to involve the customers, which is a really nice change since generally we’ve had to follow the waterfall process and then organize a Scrum under the covers. Customers have a way of really helping to refine the thinking, since they can explain directly what they care about. They didn’t of course stay for the second half of the Sprint planning, but they were very helpful nonetheless.
All and all the meeting went pretty well given the team and myself are still pretty new to Websphere Portal and it’s default content management system. I did get a fair bit of help from one of our Agile coaches who is much better at being direct than I am. The nice part was we were able to get out of the second half of the meeting with a detailed task list for the entire Sprint. The items were almost all all 4-16 hour tasks which I was only able to previously achieve on a much smaller Scrum project with only two developers. The coach was particularly good at roping people back in when we drifted off on tangents.
Everything went into a spreadsheet, but I’ll probably move everything onto index cards and a cork board, because I really prefer visual indicators. Excel can drive me crazy very quickly, so I’d prefer not to rely on it. Last time I did I decided to try out xplanner, maybe this time for the second Sprint I’ll have time to try out Scrumworks.
One odd moment was that we kicked back the final Sprint review two days after the end of the Sprint because myself and 3 of the developers will be at Software Development 2006. For the first Sprint we didn’t want to have most of the team missing. Of course that’s adapting to change over following a plan.
“Agile works really well with a team of experts.”
— Ken Schwaber (ScrumMaster Training)
“I’ve read up on this Agile stuff and it was designed for a team of experts. So we shouldn’t start sprinting until we’ve figured out Websphere. We can just use our usual process until then.” (Our usual process is a waterfall.)
— Sysadmin at my company
Common advice with managing experts is to relax and just get out of their way. Therefore Scrum and any Agile methodology naturally accentuate this strategy. They’re designed to cut the process down to a minimal level and let the team self-organize. Then the real world steps in.
Try putting together an expert team. Sure you may have a few experts on a team, but unless it’s a really high profile project, you can’t pull all the best experts at your company and staff them on the same project.
So you sub-optimize. You get maybe a really good PM/ScrumMaster and a really experienced tech lead. You have a few less senior people on the team who are going to need some help with learning curves. Maybe you have almost all senior developers on a project, but you ask them to work with a completely new toolset/language/framework where they’re not experts.
Sub-optimal Scrum is still a lot better than the typical waterfall. At least the nasty learning curve or other difficulties are taken on as a team and built into estimates and adjusted as you go. And if you want to put a whole team of novices on something then you’re bound to fail no matter what you do.
The second quote from one of our sysadmins should probably be better explained. Their experience was with a ‘Scrum’ project that was pretty much Scrum in name only. The standups regularly went 30+ minutes, there were effectively two ScrumMasters and two product owners. You can get in way over your head on a project using pretty much any methodology.
Everyone agrees the three letter acronym starts with Test. After that we have:
Since development is obviously a broader term hence the need for the other two options centering around the word design. Since developers pretty much uniformly hate testing versus designing and writing code adding the word design attempts to point out the benefits of writing tests first on software design. Then there’s a bit more clarity to Test First versus Test Driven. I actually think Test First Design is probably the clearest, but I tend to stick to Test Driven Development or just TDD myself.