Monday, 13 October 2014

"We Haven’t Got Time to Think about This Job, Only to Do It"

Thoughts on team dynamics...

This blog post is a loose assembly of some of my thoughts on communication, thought and culture - and the importance of making room for these processes/phenomena to develop when we are working to solve complex problems in teams.

Two important references

Perhaps you have heard the following commonly repeated quote of Abraham Lincoln: "Give me six hours to chop down a tree and I will spend the first four sharpening the axe." - essentially, before diving in and starting a job, it pays to think about how to approach it and prepare.

The following link will take you to a more detailed version of the same thinking with specific reference to software development - "We Haven’t Got Time to Think about This Job, Only to Do It" (Peopleware - Timothy Lister and Tom DeMarco, 1987) - if you're lucky, Google will let you read to the end of chapter 2, which is where this section is.

I actually highly recommend the book "Peopleware" in general for anyone working with software development teams; at least take a look at the section referenced above (if you can reach it).

Anyway, these references set the stage for the remainder of this post.

Teams, communication and gestalt

Without communication we can end up doing a lot of hard work to produce something that is mostly useless (worst-case-scenario!).

It is better (in my opinion) to at least accept - and ideally expect - that a percentage of a team's time will be spent purely on maintaining/developing cohesion and culture.

A team is an entity in itself - the German word "gestalt" (for which I believe there is no analogy in the English language) essentially means "the whole is greater than the sum of the parts". This is what a team is like.


Think about it - if you have ever been part of a close-knit team (a football team, family, organisation, etc - most of us have been), you will know that they can be happy, sad, motivated, dysfunctional, hurt, inspired, etc. A team is like a living, intelligent being in it's own right; it is capable of achieving more than the sum of the efforts of the people from whom it is composed. It is born of two or more minds working toward a common cause.

Teams function optimally when they are allowed/enabled to blossom and thrive. One of the reasons people leave teams is when they have no spirit.

Agile meetings - how can we improve?

Meetings are important. It is true that some meetings are unnecessary - and should be called out - but it is important to lean toward giving the benefit of the doubt.

Agile meetings such as stand-up meetings, sprint reviews, sprint retrospectives, sprint planning and backlog grooming give us a framework that we can use to develop a healthy level of team communication.

It's important to have a technical understanding of the purpose of these meetings and use them as intended.

It is far more important though to understand the principle these meetings are founded on; that in order to optimise productivity, teams need to be given the opportunity to figure out for themselves how best to communicate and to manage their work.

[team optimisation]

Agile meetings - a taxonomy

Here are a few articles that I find useful to revisit sometimes as an overview/refresher of the various meetings that Agile prescribes:

In summary

Agile meetings provide a framework that we can use to ignite team communication. They are not the only way of doing this, just a way that has been shown to be effective. This post is not about Agile meetings - it is mostly about team communication.

Effective teams are empowered enough to take advantage of meetings and to use them as a means of internal and external communication. Flavours of Agile like Scrum can give us a guideline for how to use meetings optimally.

By definition, teams are the only means by which organisations get things done (who knew?!). Managers are important - their purpose in the context of the team is to facilitate and to enable team communication.

Sunday, 5 October 2014

Three famous female computer programmers

Grace Hopper

This lady coined the word "debugging", when she found a moth in a piece of computer hardware that she was writing code against:
[debugging 4 realz - source, Wikipedia]

Julie Ann Horvath

Is probably the most recent famous female computer programmer, after she left GitHub in a major huff:

This is a bit of a sad story and it is a shame that it was allowed to happen. Up until just recently, GitHub lauded the fact that it didn't need managers:

So really this story reminds us why/how managers are important - good management would most likely have prevented this situation from going so badly wrong.

Women's work...?

Interesting to note that programming in-fact used to be considered "womens work" - but now most professional programmers and computer science/engineering students are male (in NZ).

So what changed...? Here's one writer's take on the situation (YMMV):

In any case, if you work in software and have even a few female techies on your team, you probably have a more balanced mix than most organisations (at least in NZ?)

Ada Lovelace

Last but by no means least - this lady wrote what is now recognised as the the very first computer program:

The Ada programming language was named after her and was one of the first object oriented programming languages:
[Ada Lovelace - not your stereotypical computer geek - source, also Wikipedia]