Skip to main content

"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.

http://books.google.com/books?isbn=0133440737

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).

http://www.amazon.com/Peopleware-Productive-Projects-Second-Edition/dp/0932633439

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.

[gestalt]


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.


Comments

Popular posts from this blog

HOW-TO: Add/edit a field in Team Foundation Server 2012 using Visual Studio 2012

It's been a while since I made a purely technical post...

So, today I wanted to make a change to a Microsoft Team Foundation Server 2012 (TFS2012) instance that I am working with to reflect "Actual" time spent on a task - mainly for reporting purposes, and because I have found in the past that making this minor process adjustment yields a relatively useful metric over the long-term.

I am using the Microsoft Scrum 2.1 Process Template (http://msdn.microsoft.com/en-us/library/vstudio/ff731587.aspx) for a project that I am working with. So that I don't forget how to do this (again!) I will blog-post the procedure I've used to add this field to the template as a screen-shot-based tutorial, as follows...
Before Assuming you are familiar with the Scrum Process Template (2.1-ish) - open a task and take a look at the "Details" section, as follows:


 This is where I want my "Actual" field to show up.
Get the Power Tools Download and install the latest v…

HOW-TO: Apply a “baseless merge” in Team Foundation Server 2010 (and 2012)

Another purely technical post on TFS...
The scenario We wish to migrate code between branches that do not have a branch/merge relationship, in order to expedite urgent changes being made by a project team, without disrupting on-going BAU development work. Sample branch hierachy/strategy Imagine the following branching strategy in TFS (visible by connecting to TFS via Visual Studio 2010 or 2012):

Essentially you have a "DEV" branch, which has a "QA" branch, which in turn has a "PROD" branch. DEV is the branch that you would be using for BAU development. As a piece of development matures, you move it into QA, where it is tested by your internal QA team. There may be further changes made in DEV that are moved into the QA branch as the QA team pick up issues. Once the QA team are happy with a packaged of changes, they will move them into PROD, which is essentially the hand-over to the customer. The PROD branch represents the software that the customer has.

Mo…

Eclipse/Android error: "Multiple dex files define [...]"

Wow, I am really going nuts blogging this-evening - 2nd post in less than an hour. 


Anyway this is a particularly nasty error that I keep running into with Eclipse/Android when starting the emulator after I have not run it for a little while. Since I run the risk of permanently forgetting the solution to the problem every time I walk away from my Android project (and thus having to spend a painful hour-or-so digging up the procedure again), I will blog it here, for my benefit, and for the benefit of anyone who may also suffer the same problem.


The gist is that when you start the emulator in debug mode (that is, you hit the button in the following image), you get the following error message come out on the console and a nasty popup telling you nothing more than there is an error with your program and you need to fix it:








[2012-04-06 23:20:57 - Dex Loader] Unable to execute dex: Multiple dex files define Lcom/google/gson/ExclusionStrategy;
[2012-04-06 23:20:57 - SimpleList] Conversion to Dal…