I wrote a longish follow-up to minnēbar over at Alt Text but wanted to make mention here of the presentation that Ross Niemi of Thoughtworks and I gave this year, titled: You can do that? Selling agile to the enterprise. The slides are a bit sparse (though there are a few extra notes that show up when you print or view without styles) as we spent most of the time talking about related topics and fielding questions. I am happy with how it went as it was the first time I had given that presentation and was please that it wasn’t the same old intro to agile talk I have prepared time and again.

Here are a few notes from Christopher Warren on the session.
I’m not the only one who was involved, though. Here’s a quick post of some of what the Refactr team did at minnebar:

Jesse ran through a well-received session where he created a conference scheduling application using Groovy and Grails in 40 minutes or so. And Scott participated in the Web Frameworks panel in which he represented Grails. Other panelists included: David Heinemeier Hansson (Rails), Jack Ungerleider (Zope), Nate Straz (Django), Scott Vlaminck (Grails), and Derrick Shields (Code Ignitor).

With over 300 participants and growing, I am glad we have the space to hold everyone at this year’s event. Now feeding them, that may be another story.
Refactr will be representing a number of things at this year’s barcamp of Minnesota. I will be a part of a panel on design (visual, interaction, etc) and also be facilitating a session on “selling agile” and all that entails. Jesse is going to walk through the creation of a simple application using Groovy/Grails, and, not wanting to be left out, Scott joined the web frameworks panel at the end of the day where he can discuss the merits of Grails with the other panelists, including David Heinemeier Hansson, creator of Rails and one of the key evangelists for convention over configuration.

Today was the first day of the No Fluff Just Stuff conference here in the Twin Cities. This is my second year attending and I can’t say enough good things about this conference. It’s a great format with excellent presenters and very high quality topics. I was able to walk right up to each of the presenters after their talks and ask them questions; try that at almost any other conference and let me know how that works for you. The only real bad thing about No Fluff is that you almost always have to make a tough call about which session to go to for a given time.

For the first session I decided on Groovy for Java Programmers by Venkat Subramaniam even though I figured it would mostly be review. Venkat is a really fun presenter and he did a lot of live coding during this session which made it very engaging. A lot of the Groovy topics that he discussed were indeed things I knew about, but it was still interesting because Venkat is so excitable and funny. I also did get exposed to Categories, which I hadn’t seen before and I need to look into further. Right now, I’m not fully understanding when or if you’d use these over ExpandoMetaClass.

Up next was Domain Driven Design also by Venkat. Even though it’s kind of a repackaging of basic OO Design, DDD seems interesting and helpful, even if only because it helps to remind us of what we should be doing anyway. Unfortunately, Venkat had to skim over a lot of the last parts of his presentation, and it seemed like the end was the meatiest part. I was happy to see the stressing of DDD not meaning Big Design Up Front and the focus on largely disposable UML diagramming. This may have been Venkat’s personal views bleeding through, but it resonated with my experiences. I’m still trying to fully digest this presentation and hopefully will have more to say later.

The final session of the day for me was Building DSLs in Java and Groovy by Neal Ford. I thoroughly enjoyed this presentation. Neal gave the keynote last year about Domain Specific Languages and it seemed cool, if a little out there, but this year they seem to be actually gaining some traction. I’ve been reading up on this topic lately, so it was fun to see Neal develop essentially the same DSL in Java, Groovy, and finally Ruby. There’s definitely something to the idea of programming in a Humane Interface style where your code is instantly understandable and readable. Neal was big on the idea of BA’s being able to verify your code because it was written this way, but I actually think the advantages to the developer are just as big, because as developers we’re constantly having to reacquaint ourselves with code we wrote yesterday, last week, and even last year and anything that makes that code more readable and understandable will increase your efficiency.

Wow, just reading that makes me tired, and today was essentially a half-day, but I can’t wait to start again tomorrow. I’ll let you know how it goes.

I’ve used CVS for source control for quite a while. We started off using Subversion at Refactr because we keep hearing good things about it and - among other things - I like the idea of keeping version history for renamed files. I’ve been meaning to pick up a copy of Pragmatic Version Control Using Subversion, but I still haven’t. So I was happy to run across this post on Subversion Best Practices by Jared Richardson. It’s more of a quick introduction of how Subversion and CVS differ in setting up projects, but it was still helpful for me.

Jon discusses why he and his team abandoned daily team meetings - a standard practice for many agile teams, particularly those using Scrum or XP. I can definitely sympathize with a couple of his reasons because I’ve had some of the same struggles from time to time. For instance, he’s right that keeping the meetings short and on-task requires discipline - not just staying away from what happened over the weekend, but also keeping the meetings at the right level of detail.

For example, in the daily meeting I don’t need to explain the full detail about an algorithm I implemented yesterday, just the fact that I did it. I can discuss all the details and rationale with the interested parties after the fact - this is an important point to keep in mind, especially on mixed-discipline teams that may include designers and testers. Many of them won’t care how or why I used a Factory pattern within my Bayesian text classifier.

What makes the most sense to me is that his team is typically spread across multiple projects. I agree with his position that the usefulness of daily team meetings decreases when everyone is not on the same project. The “3 questions” discussed during the meeting won’t typically impact someone not on the same project.

I disagree, though, with Jon’s thought that “Daily meetings might make sense if a team is using strict Scrum project management ….”

I’ve had daily team meetings on nearly all the projects I’ve been on for years and have found them beneficial whether I was a team member or “leading” the team. However, in all cases, the team was working on the same project. Coming back to that point, having been in both situations before, I believe that team communication means something different to a project team than it does to a team working on different projects.

Brian Button recently described The hardest part of being an Agile Project Manager for him on a project: Staying out of the way. He’s found that to let the team effectively grow and work well together, they need to be able to identify and resolve some problems on their own. Based on my own experience, I couldn’t agree more, though it’s a seemingly paradoxical idea. Brian says that at times he takes this to the point of letting the team identify and resolve some issues on their own - even when he thinks he can see the problem coming before the team realizes it.

Stepping back, my view is that on an agile project, the job of a team lead/project manager/scrum master/whatever is to clear roadblocks. A daily stand-up meeting helps team communication and also helps to uncover problems people may be having sooner during the process of development. The team lead is responsible for making sure that someone addresses any problems that are identified. Additionally, having a self-sustaining team is important - because the team lead may not always be available, but also because the effectiveness of a team increases when they have confidence that they can address problems as a team, without the always requiring involvement of the team lead - or the team lead will become a bottleneck.

There’s a balancing act here between short-term effectiveness and long-term effectiveness. To me, this is the same trade-off people make all the time: mentoring and building people within an organization vs. impact on daily duties, corporate quarterly results vs. long-term sustainability of the business, day trading vs. investing in mutual funds, etc. To be successful, you need a healthy balance of both: one eye on current priorities and one eye on building for the future.

In the past, I have personally struggled with how much to involve myself in everyday decisions of the team - and making sure that my involvement was for the right reasons. Though each scenario is different, one of my approaches was to try to contribute my knowledge and experience to the discussion, but to refrain from influencing the decision beyond just helping to work through the problem and possible solutions. However, some decisions warrant more involvement and in those cases I wasn’t shy about expressing my opinion about a specific resolution.

It’s another case where it’s a tough call and you need to think about what is right for the situation and for the specific team involved.