Subscribe
Posted on April 19th, 2009
Thanks again to everyone that came out to my Software Craftsmanship talk at BarCampOrlando yesterday. I had a blast, and I enjoyed talking with so many of you throughout the day about moving forward with becoming craftsmen in your own organizations.
Here are some resources I talked about or listed in the slides:
- Agile Manifesto
- Software Craftsmanship Manifesto
- Software Craftsmanship Mailing List
- Information about Scrum
- Information about Crystal
- Information about Extreme Programming
- Information about Test-Driven Development
- Information about Behavior-Driven Development
- Software Craftsmanship by Pete McBreen
- Clean Code by Robert C. Martin (or my review on Slashdot)
And, as always, you can contact me using the email address on the right-hand side of my blog, or via Twitter at cory_foy.
Posted on April 19th, 2009
“Bob, we need to talk. I’ve been reviewing the check-in histories, and Steve hasn’t bothered to check in anything in the past 6 days. When he does check-in, his quality is just utter crap. I don’t know what happened, but I’m tired of dealing with him and his slack attitude.”
We’ve all had team members that are hard to deal with. In my last post I mentioned that we need to respect our other team members. But is that where it should end? Do we merely just need to acknowledge them as humans?
When we work together as a team, we bring together people with different skill sets, different personalities, different learning styles, and different wants and desires. Bob above may be passionate about building code, and is willing to sacrifice personal time to do that. Another developer on the team may be passionate, but is more passionate about his home time, and rarely sacrifices that. A third may be just using the job to pay the bills to fund his real love of music, art, motorcycles, crafting, or whatever.
When we make blanket statements about development teams, we forget to take these individual attributes into account. Indeed, even as individual developers we forget to take these into accounts. The struggle you see in someone else might not be technical. Steve might not have a slack attitude – he might be going through a divorce, or a sick kid, or a variety of issues.
So what has this to do with compassion, and more importantly, software development? Technically, perhaps little. But from a team dynamics perspective, it is a key tenant to growing a team. You don’t have to attend a team member’s kid’s Little League games, but understanding that something is causing them to not be able to focus on the task at hand can help them get past it.
As an example – we had a team member in a previous job whose child was sick. They had taken time off to try to handle it, but it got to the point where it was impacting their work, and they were running out of sick days.
One response would be simply to be disinterested. After all, it’s a personal problem, and they need to deal with it. But a compassionate response is to try to find out what you can do to help. From a peer perspective, it may be just going up to them and saying, “Hey, I noticed you seem to be distracted lately. If there’s anything I can do to help, let me know”. As a manager, you need to provide them with the comfort to come to you.
In our example, the team member did come to us, and we were able to work with them to come up with a schedule where they were able to focus on their child getting better, but also to still get done what they need to get done.
The other team members responded in kind by helping to define their work, provide assistance where needed, and generally respond as a team would to protect their team and provide an environment of compassion.
Compassion also comes into play with foundational changes. When you shift the fundamental way people work you have to be concerned about two things. The first is the response to change – do they understand the new roles? Do they understand how they need to work?
But the second is more primitive. Does their personality, who they are, make it difficult to work a certain way? If you have someone who thrives on doing one task at a time, in a siloed fashion, how do you incorporate them into a dynamic, collaborative environment? What opportunities do you present them to prepare them?
Obviously at some point, compassion turns to altruism, and then at some point it becomes charity, and you have to make a hard business decision of whether or not you need to keep someone with the team. If they can’t adapt, and there aren’t roles to slide them into, you may have to let people go.
But in our day-to-day activities, we need to be aware of when our teammates are struggling, and offer support to them. It may not be technical, and it may not always be easy, but the impact it has to growing your team will be worth it.
Posted on April 9th, 2009
Some exciting news from the Day of Ruby event – in addition to the Tampa Day of Ruby being held on May 16th (which has 1/3rd of the slots gone already – so sign up quick!), I’m excited to announce that we’ll be holding an Orlando Day of Ruby on May 30th!
Both events are totally free events targeted at .NET, Java and PHP developers who have been wanting to get their hands on with Ruby, Rails, RSpec, Shoes and other frameworks – but who don’t normally have the opportunity in their day to day work. We’ll cover creating Ruby Desktop and Web Applications.
So if you know that special .NET, Java or PHP developer who has been wanting to try out this Ruby thing, be sure to send them over – right after you’ve signed up yourself!
Posted on April 1st, 2009
One thing that has always amazed me is the giant leaps we take in organizations to protect the salary information of others. Even telling another employee your own salary is a firable offense in some companies – much less finding out what everyone makes.
I’m a firm believer in things like Maverick and SEMCO where Ricardo Semler turned the organization upside down by opening just about everything to everybody. The janitor knows how much the IT Head makes. The secretaries know how much the CEO makes. They discuss policies, hiring, raises and a whole host of things that would cause most organizations to shutter.
While I’m a firm believer in it, there is one small caveat. On Twitter this evening, I got this reply:
beefarino: @cory_foy @karlseguin @bradwilson nothing stopping you guys from tweeting your salaries….
And, while he’s right, I want to make something clear. I’m not saying that everyone’s salaries should be seen by everyone, or really anyone outside their organization. There are a whole host of reasons why, with competitive edge topping the list. But inside an organization, it should be fair game.
I worked for a place like that – government. We knew the salary ranges for every position, and you could reasonably guess where someone fell in that range. And if you couldn’t, you could ask them – it was somewhat of public record anyway. And if I were 5x better than someone, and my manager wanted to pay me that way, I would have either been promoted to a position, or had a position created which covered that. And the duties and the responsibilities would have been there justifying why.
Even if you or your organization doesn’t want to post it internally, at least remove it from being an offense for revealing it. If someone asks me my salary, and I want to tell them, by golly, I should be able to tell them. And if I find out they make more than me, then I might understand, or I might ask my manager why. And maybe he has a good reason (the other person is better than I am / has more responsibilities / we needed to hire him at a hire rate due to market, but don’t have the funds to adjust everyone’s salaries). And if he doesn’t, then is he really being a good manager? Or just playing a guessing game?
I’m well aware the shock something like this would likely bring to an organization if it was just turned on. But this isn’t some secret society. We’re professionals. Let’s start asking to be treated as such.