Subscribe
Posted on July 28th, 2008
Some friends wished out loud for a way to compare the results of Google to the new search engine Cuil. Ask, and ye shall receive. And because I’m sure someone will be asking, here’s a Live vs Cuil page as well.
Posted on July 24th, 2008
So this evening I’m happily toting along, and I look down to suddenly having over 100 unread email messages in my inbox. Looks like someone has used my main email address as the “from” for a big spam run. Who knows how bad *this* is going to be.
Anyway, if you’ve come to the site because you received one, it’s not from me. Spammers are evil, evil people.
Posted on July 20th, 2008
Next month, on August 13th, I’m going to be speaking at the Agile Tampa meeting on “XP and Scrum: Tools and Practices for Making your Organization Agile”. It’s a long title (as anyone who has paired with me will know, I like long method names to describe behavior), but it will cover some very important information.
As organizations begin to investigate and implement agile methods, they quickly find themselves trying to understand what is out there, and what tools can help them manage the process. By tools, I’m not necessarily referring to things like VersionOne or Rally’s tools. I mean things like CRC cards, index cards, user stories, customer tests, developer tests, etc.
During this talk, I’m going to be first comparing and contrasting Scrum and XP (and likely Lean as well, since that has been a hot topic lately), and then diving into various practices and tools designed to help get things rolling on your teams.
If you’d like to come, be sure to get the info from the post on the AgileTampa site. NOTE: This is being held at the *NEW* Microsoft office in Tampa – they aren’t in their old location anymore.
Hope to see you there!
Posted on July 18th, 2008
If you are interested in spinning up a Rails app without a database, it is a little trickier in 2.0 than in previous versions. Do the following:
rails nodbspike
script/generate controller hello
This sets up a basic Rails app with a controller. Modify app/controllers/hello_controller.rb to include the following:
def index
render :text => "Hello, world!"
end
You now have a basic controller set up. Let’s tell Rails not to use ActiveRecord. We do that by opening up config/environment.rb and adding the following line:
config.frameworks -= [ :active_record ]
So far, this is how you’d do this in Rails 1.x. However, in 2.0 they introduced a new file which will also try to use ActiveRecord. So open up the config/initializers/new_rails_defaults.rb file and comment out the two ActiveRecord lines.
You should now be able to fire up script/server, browse to http://localhost:3000/hello and code away!
Posted on July 17th, 2008
On Monday, I started my new role as a Development Manager of a team here in Tampa. I’m extremely excited to be working with them – they are a great team that has been around for a long time, and are excited about finding new ways to produce software.
Last Thursday they released a new version of their product. It was, as quoted by several members, chaos. While all of us may like some chaos from time to time, it’s not a good model for shipping software – even if that schedule is 12-18 months.
One of the first actions I took was to lead the team in a retrospective. I used several exercises out of the very excellent Agile Retrospectives book by Diana Larsen and Esther Derby. The exercises I used were:
- Check-In – each person says 1-2 words about what they think about the process. The goal is just to get everyone to same /something/ since they’ll be more likely to speak later
- Focus On/ Focus Off – What should we focus on during the retrospective, and what should we focus off of?
- Timeline – We broke the group into small teams, and each team wrote an event that happened during the iteration on an index card. This could be as simple as "Shipped the release" or "Lost team member" or something even as small as "The boss brought in donuts during testing week". We then grouped the cards on the wall based on the quarter they fell in – yes, this spanned 6 quarters of work – not a length of time you ideally want to do retrospectives for
- Color Code Dots – I chose to have everyone then come up and grab a marker which represented either a high point or a low point. Multiple dots were encouraged.
- Patterns and Shifts – I then took the cards with the most dots and started grouping them. We discussed each one and put them into categories. We came up with 6 or 7 categories that all of the cards fell into.
- Learning Matrix – This is basically a 2×2 matrix I drew on the whiteboard specifying what was good, what could be changed, new ideas, and accolades for specific actions.
- Start/Stop/Keep – Then we took all of the above insights and put them into an action plan of things we were going to start doing, stop doing, or keep doing.
At the end, we then held a retrospective of the retrospective itself. This was good to get feedback about what worked, and what could be improved.
The results of the entire exercise were awesome. The team, without any prompting from me, came up with the ideas that the way to improve was to find ways to be more agile in their approaches to estimating, developing, and releasing. In addition, they identified that they needed to involve the whole team earlier on, including QA and support. I couldn’t have been happier!
The retrospective itself was cross-functional, in that in included the entire dev and QA teams, some Business Analysts, Support and Management. The feedback I got was extremely positive, and everyone seemed to really enjoy it. In fact, we even managed to capture a couple of pictures (at least the ones I can show. ;)):
The team color coding the dots
Me leading the Patterns and Shifts section
I’d highly recommend picking up a copy of the book and trying this with your own team. You might learn some insights that make your team that much better!
Posted on July 1st, 2008
Over on the XP list, someone posted a link to an article entitled A Soft Answer. It’s a great story about an incident on a subway train between someone trained in Akido, an unruly drunk man, and a older Japanese man who shows truly effective communication skills:
Now it was my turn. Standing there in my well-scrubbed youthful innocence, my make- this- world-safe-for- democracy righteousness, I suddenly felt dirtier than he was.
As the train pulled away, I sat down on a bench. What I had wanted to do with muscle and meanness had been accomplished with a few kind words. I had seen Aikido tried in combat, and the essence of it was love, as the founder had said. I would have to practice the art with an entirely different spirit. It would be a long time before I could speak about the resolution of conflict.
This was rather timely as a particular message board I frequent I got “attacked” by an anonymous poster questioning my very ethics. Note the choice of words there – I truly felt like I had to defend myself, and no matter how much I try to take time, there is always an emotional aspect to conversations that is hard to keep down. Hopefully this article will continue to remind me how to communicate effectively with other people – even those that seem like all hope of reasonable conversation is lost.