Managing activity transitions through use of rituals

Last night I went to a fantastic seminar for parents of children with  behavioural challenges. The speaker was very engaging and gave us a lot  of great information and techniques we can try out to help diffuse challenges as they arise.

Disclaimer: I'm not a behavioural psychologist. This is just my understanding based on the aforementioned seminar and my own observations.

I'm not going to write about all of the topics covered as there were many and I couldn't do them justice. I'm just going to focus on something which struck a chord with me and some behavioural observations I've made in the work place. That is how people manage their own transitions between day to day activities.

So what do I mean by that?

Children, especially those with special needs, can get very anxious when transitioning from one activity to the next. This can be as simple as coming home from school or coming inside from playing in the garden. These transitions happen many times a day and unmanaged can increase anxiety levels with each one. This can manifest itself behaviourally in numerous ways including, but not limited to, melting down, wanting have an argument or violence.

The speaker relayed an interesting example from his own life. He noticed that his son, who is neurotypical, would always pick an argument after he stopped playing on the Xbox. This would only happen for about 15 minutes then he'd be fine. After recognising this they worked out a transition strategy.

One of the suggested way of handling this is by having a ritual between transitions. This helps reduce the anxiety and helps prevent behavioural issues. This should be quiet, perhaps with some food, so to reduce any unneeded stimulation.

So how does this apply to us adults in the workplace?

As adults we have generally figured out ways to manage our transitions between activities without even knowing it.  How many of you have a ritual when you get in the office, but before you start working? When I get in to the office the first thing I do is get a coffee, then I read a few blog posts. After about 15 minutes I can get down to some real work.

I'm suggesting that adults may not manage these transitions as well as assumed under certain circumstances.

I've noticed that my own anxiety levels increase when I go rapidly from one different activity to the next. For example, going from a video conference straight into coding, or leaving the office immediately while in the middle of an intense task.

Going forward I'll be looking for ways to manage these transactions through the use of ritual as to lower my stress levels. I'm also studying my own working patterns to see how I currently handle them.

I'd love to hear others thoughts and experiences.

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.

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.

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?

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?

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.

Blog retrospective

Though I've had a blog since 2009 my post frequency has been a little sporadic. About two months ago I made a decision to post regularly. I'm now at the end of the first two months of active blogging.

As part of my serious commitment to my blog I thought it would be useful to do a quick retrospective. I won't be doing this on a regular basis though as not to flood my blog.

Anyway since I want to cast a wide net I thought a simple pluses and deltas format would suffice.

Pluses
- I've been able to post on average once a week.
- I am pretty happy with the finished articles. I feel that I'm getting my point across.
- I have a large number of story ideas that I'm generating.
- I'm feeling more confident about my posts.

Deltas
- I need to decide what my update frequency should be. I'm thinking that weekly might not be sustainable and monthly too infrequent. I'm going to try bi-weekly.
- I should investigate other Android blogging apps as Google's Blogger app won't let me post hyperlinks.
- I need to get better at writing in general.

Feel free to add your own comments below as feedback is essential to improvement.