Monday, April 25, 2011

Don't use Scrum because it has no technical practices

Spend enough time in the agile community and you'll hear someone make the above statement at some point. This is normally referring to the fact that Scrum doesn't make an explicit recommendation to use practices such as Test Driven Development (TDD) or Continuous Integration (CI) etc.
To me this sounds like a way to rationalize a decision not to do Scrum. That's their decision, Scrum isn't for everyone and it's not the only successful way to be agile (XP, Kanban etc). I just don't think the above argument is a valid one and shouldn't be used to sway someone in favour of another agile methodology.
Scrum doesn't need to explicitly outline these practices because it's a framework that can be used outside of software development as well as within. When done well it implements all of the practices and values, whereas some of the technical practices might not be right for your development environment.
I'm not saying that Scrum practitioners shouldn't use the above technical practices I just don't think that they need to be mandated (I personally recommend TDD, CI etc for my teams where appropriate).
Also because Scrum is a framework it gives us the flexibility to use any current or emerging practices, technical or otherwise. In fact most scrum practitioners I've spoken to encourage people to actively seek out and experiment with other ideas provided that they don't conflict with the Agile Manifesto or Scrum values. This was also mentioned in a Scrum Alliance update by Mike Cohn where he states that Scrum is not enough.
Finally, practices such as TDD and CI have successfully migrated out of XP and have taken a life of their own. I see more technical and non-technical practices doing that in the near future. This will allow skilled practitioners to mix and match based on the environment.
If you agree or disagree please let me know. I'd love feedback.

Friday, April 22, 2011

SSRS 2008 Quick tip: designing your databinding scheme for a custom charting control

So you've decided to create your own SSRS 2008 charting control. Good luck. The API is highly under-documented and there are very few examples out there. Now that I've got that disclaimer out of the way I'll proceed.

One of the decisions you'll have to make is how to structure your data for consumption by your control.

If your chart only needs a simple mapping scheme, where you consume data as it's returned by the dataset, then this tip won't matter much to you.

If you want to do something more complex then you'll be pleased to discover that any custom chart has similar column and row grouping capabilities that a standard tablix has.

Tip:

When getting your control databinding working create a tablix for debugging. This tablix should have the same grouping setup, including expressions, which also consumes the same dataset. This way you can debug any issues with the data you're receiving and also experiment with new grouping setups and expressions without wondering if there's a problem with your code.

I'm not going to go into great depth about the databinding code itselfu at this stage. I plan to do that in a future post.

Friday, April 15, 2011

Should the Subversion blame feature be renamed?

I had a brief conversation today about blaming people in which the following question came up:

'then why does svn have a blame feature?'

This is a very good question. My feeling is that it's named incorrectly.

I've had a problem with the name of the blame feature since I first came across it. To me it feels like it was inspired by a culture of fear rather than a culture that understands that mistakes are part of learning. Blaming someone isn't going to achieve anything. Sooner or later all developers will be on the receiving end as I've yet to find a person who doesn't make mistakes.

This also gets back to the words we use and how they shape our thoughts. If there's a bug and there's a blame feature, am I more likely to use it to blame a team member for causing the bug?

I have no problem with the feature itself.  I use it to give me a good view of all of the changes that make up a specific file and find out why they were changed.

I'd like to see the name changed, but have yet to think of a good name. What would you name it instead?

[Edit]

One possible alternative that was suggested was Root Cause. Any others?

Thursday, April 7, 2011

Do job titles shape our thinking?

It's well known that the words we use shapes our thoughts. With that in mind, does a job title shape our thoughts into what our role should/should not be based on industry norms?

For example, I've caught myself in the past using my job title to justify not doing a task that I didn't want to do. This is something I've worked hard at breaking myself out of.  I've also seen other developers do the same thing many times. At the time I thought it was perfectly fine, but have since realised that we all need to pull together.

Of course the job title is just one part of a larger thing, the job description.  When was the last time you saw your job description though, if ever?

In every company I've worked over the last 15 years I've never seen my my job description. I'm sure one was given to the various recruiters and I'm sure that if I asked I would have been given it, but I've never thought to ask.

So the job title, some management guidance and discussion with peers have been all I've had to go on.

With this in mind should we start using team based titles, or no titles at all? I'm gravitating towards Product Team Member.

What are your thoughts?

Tuesday, April 5, 2011

Vaguely empowered revisited

Recently I wrote a blog post on feeling vaguely empowered. Though this is still valid I've since realised that the feeling I had was simpler and more powerful.

Fear.

The upshot is that I don't need a meeting with my manager to figure out my boundaries. I just needed the courage to do what I feel is right.

This in turn doesn't put limits on me. Will I step over the boundaries sometimes? Most likely. Could I get into trouble sometimes? Probably.

I must remember to dig down deep for courage if I truly think that it will benefit the team and the company.

Note: the solution in the previous post might be helpful for people that are new to being empowered and are finding their feet.