I was like, how do you like your daily standups. There's shuffling of feet and everyone's looking down. I asked how often do you do your standups?
Three times a week.
Well, how do you feel about that?
More shuffling, well, it's OK. Finally one guy, a programmer goes "I don't like'em." Turns out more people don't like them.
Well, you oughta stop doing it.
But it's a cornerstone of Scrum, you can't not do daily standups. You'll get kicked out of the community.
I' don't get a royalty on every daily standup, you want to take it out go ahead.
There weren’t any more details on how that played out, but the team apparently did just try removing the standup. I’ve had this conversation with several developers about standups. On some teams they seem like far too much of a chore and too stuck around reporting hours on tasks on a spreadsheet.
I did have one team where we took out the standup on Mondays and people were going to email their statuses around. That turned out to work pretty poorly as for the most part no one remembered to send the emails. Still if a team really wanted to experiment with no standups it’s their call. My guess is the better thing is to fix the reasons behind the dysfunctional standup. Jason Yip has a good recent post on standup patterns and ways to adjust standups that have the wrong vibe.
I made a little headway on Haskell today.
Downloaded the GHCI environment to start running/compiling in Haskell. Had to find the Mac Intel port. Went looking for at least a TextMate bundle, turns out there is a pretty basic one available. Then started one of the basic Haskell tutorials.
After just an hour or so I feel like I’m on another planet, but that was the desired effect. Next up getting HUnit up and running.
Many of the practices I’ve introduced to my team have largely stayed within my team. There’s no moat around our section of cubicle land, and all the other teams knew about the majority of our practices, but we didn’t see any uptake. I hoped about a year ago when I ran a TDD seminar with JUnit for the bulk of java developers outside my team that we’d see a change there. About a year later I think the only evidence that they’d been through a seminar on TDD was a few tests scattered across one project.
Osmosis wasn’t going to be enough to convince people. It went the same way with my team. A few of them have really run with everything from code reviews to TDD, but many of them take a great deal of convincing.
The next push was to talk to my peer manager about how we spread the adoption across our groups. I’ve put that discussion off for at least 4 months now largely due to fear. I heavily lean towards consensus building and I don’t like show up preaching like a convert. We’ve had a pretty good relationship though and for some reason I finally stopped mulling over my notes and approaches and just dropped in on him in his office.
Turns out he’s pretty open to the ideas, and it really didn’t take a whole lot of convincing. We’re going to start out introducing some of the easiest stuff like automated builds and continuous integration and then progress to TDD, code reviews, static analyzers and the like. Just one practice at a time so we don’t overwhelm anyone with change. At the end of the process our entire development organization should be performing all the same practices to a lesser or greater extent. By this time next year our basic practices should be shared throughout the development organization.
Definitely should have broached the subject much sooner.
Turns out IBM recently snuck out a way to integrate ruby with Websphere Process Server using SCA (Service Component Architecture). It’s incredibly enterprisey and a bit surprising to see out of IBM. And the whole thing is made possible via JRuby.