Building Successful Communities of Practice

Just got back from a stimulating evening meeting of the BCS SPA specialist group. The presenter was Emily Webber on Building Successful Communities of Practice. If I understood correctly, a community of practice is a cross-functional, self-selected group of practitioners doing roughly the same tasks in different teams, business units or even organisations. Spotify has identified almost the identical concept in its "guilds".

The big takeaway for me (apart from the fact that Emily in real life doesn't look nearly as similar to Sarah Millican as she does in her photo) was that the mutual support provided by such a group gives people more autonomy and more mastery of their craft, both of which are strong motivating factors and promote happiness, which in turn results in demonstrably higher productivity and lower staff turnover (a study by Warwick University showed the productivity of happy employees to be 10-12% higher than average, while that of unhappy ones was 10% or more below). This would seem to suggest that allowing as much as one day a week to employees to exchange ideas and experiment with ways to improve their technique could be a worthwhile investment.

Simple, secure way to share a git repository

The problem with Windows or NFS file shares is that the contents are not version-controlled and (unless you use the Windows "available off line" feature) not available while you're disconnected from the office network. However, it is very easy to set up a git repository for a team to share code and documents, if they all have at least intermittent access to the same file share.

First install yourself a git command-line client if you have not done so yet (see http://git-scm.com/downloads).

Creating the repository

Assuming that

• You already have a local git repository called "test-repo", which you want to share
• Your local git repositories are under %HOMEDRIVE%\%HOMEPATH%\git
• Your shared git repositories are going to be under \\myserver\myshare\git

To add a remote copy of your own git repository to the share:

>%HOMEDRIVE%

>cd %HOMEPATH%\git\test-repo

>pushd "\\myserver\myshare\git"

>git init --bare test-repo.git

>popd

>git remote add origin "//myserver/myshare/git/test-repo.git"

>git push origin master

Note that the git commands require slashes to be forward - unlike normal Windows commands.

Verify that the file .git\config within your local git repository looks something like this:

[core]

    repositoryformatversion = 0

    filemode = false

    bare = false

    logallrefupdates = true

    symlinks = false

    ignorecase = true

    hideDotFiles = dotGitOnly

[remote "origin"]

    url = //myserver/myshare/git/test-repo.git

    fetch = +refs/heads/*:refs/remotes/origin/*

[branch "master"]

    remote = origin

    merge = refs/heads/master

    rebase = true

Ensure that the sections [remote "origin"] and [branch "master"] in particular are set up correctly.

Cloning the repository

Another team member can now share your code - you both push your local commits to the shared repository and pull other team members' commits from it to your local repository. Here's what each team member wishing to access the shared repository should do, assuming that they also have their local git repositories under %HOMEDRIVE%\%HOMEPATH%\git.

>%HOMEDRIVE%

>cd %HOMEPATH%\git

>git clone "//myserver/myshare/git/test-repo.git" test-repo

>cd test-repo

>git pull

>git status

The status should look like this:

# On branch master

nothing to commit (working directory clean)

BCS SPA2010 conference

Final day of the conference - it's gone much too quickly as usual. My favourite session to date has been the brief whirlwind tour of agile practices given by Gwyn Morfey and Laurie Young of New Bamboo - "the Sword of Integration". This was a highly interactive session that involved everyone standing up and moving about enthusiastically, which despite the cramped room, meant that we all ended up remembering something instantly useful from the session.

By the way, the sword of integration itself is just one example of an instant solution to a pressing problem. The situation was that multiple developers checking in their changes would cause each other to have merge conflicts. The solution: a paper "sword" quickly assembled, which when held conferred on the holder the right to check in - and hit anyone who checked in when they shouldn't. The principle being illustrated is "just try it" - there is no need to get it absolutely right first time. If it doesn't work, we can change it later.

24th March 2009: Theory of Constraints Challenged

My sincere thanks to Kevin Rutherford and Allan Kelly for co-presenting a fascinating session about lean software development to the BCS Kingston & Croydon branch on 24th March this year, entitled "Lean, Constraints, Action!". The audience was excellent too and helped us re-create a famous experiment related by Eliyahu Goldratt in "The Goal".



(Click images to see a larger version)

I had participated in this game previously at the London XP Day 2008 (facilitated by Karl Scotland in an Open Space session). It is designed to demonstrate an intuitively paradoxical finding: that a lean, pull-oriented flow substantially reduces the amount of inventory or work in progress (WIP), while improving throughput.

However, I had a sneaky feeling that the experiment was biased, because in the first "push" simulation, the assembly line was not pre-loaded with WIP, while in the second "pull" simulation, the line was pre-loaded with workpieces at each "workstation's" input buffer up to either the maximum limit or to 50% of that limit. Therefore in a simulation of 10 rounds (equivalent to ten working days - approximately equal to the average cycle time in a six-workstation setup) the push simulation will only start to produce output towards the very end of the simulation, while the pull simulation will produce something from the very first day.



So I got Allan and Kevin to agree to vary the rules a little bit, to try to get closer to a "steady state" from the first "day". Before each of the two simulations, our teams placed three Lego blocks on each of the coasters representing the input buffers of the second through sixth workstations (the first workstation of course has the whole of the product backlog as its input hopper). In fact, as it turned out, four workpieces would have been closer to the true steady state in the pull simulation, even more in the push simulation.

Off our teams went and played the production line for ten rounds each. In the push simulation, the die was passed in order from workstation 1 to workstation 6 during each round and the number of workpieces transferred to the next input buffer was the number thrown, up to the number of pieces available in the workstation's input buffer. Instances of starvation were rare under this system, but did occur sometimes. At the end we counted up the number of pieces that had come off the end of the line and the number currently in progress (i.e. on any of the five input buffers for workstations 2 to 6).

In the pull simulation, the die was passed in the opposite direction and the input buffers were constrained to a maximum of six workpieces. So if the next input buffer had three pieces already in it and the player threw anything over a 3, they could only pass along 3 more workpieces (subject to their own input buffer holding at least 3, of course). Once again, the results after 10 rounds were compared.

The results didn't surprise me particularly, but I think some of the others were a little taken aback:



As you can see, the constraint resulted in both lower WIP and lower throughput. This makes sense when you consider that there were far more occasions during the pull game than during the push game when players were unable to process the full number of workpieces indicated by the die.

Looking back at the game notes, it is noted that if the simulation is run for much longer than 10 days, the pull (or Kanban) system "will rarely produce as much as the traditional push". This may have escaped the attention of some readers (or perhaps it's a more recent edit - I don't know).



My conclusion is that you get nothing for free. The cost of reducing WIP is reduced throughput, which is perfectly acceptable as long as you're aware of it. Software development projects are not production lines in any case, so it is very unlikely that any developer will sit around kicking her or his heels if the work runs out on a given day. There are always low priority tasks such as fettling the build system, cleaning up the documentation on the project Wiki, answering user support requests etc. - or just take the next item off the product backlog and raise the kanban limit temporarily.

Why people think it's OK to cheat / steal

Dan Ariely has given a brilliant talk about this and how it impacts the global economic crisis. Watch this on Ted - it'll be 16 minutes well spent. Good insights into human psychology and behaviour.

Agile and Lean - complementary or conflicting?

Dave West has contributed an article entitled A Marriage Made in Heaven?. I found it very instructive to read that as well as the comments attached to it. To my mind, there are things that the software community can learn (and has learned) from lean manufacturing, but in many respects software development is much more of a joint creative act. As Dave says, Peter Naur as long ago as 1985 equated programming with collaborative theory-building - in other words, it has much in common with research at the forefront of physics or mathematics, where results are difficult to predict and effort is almost impossible to forecast.

Improving team dynamics

Interested in making your team more effective? I found the following list of useful links just now after reconnecting to a former colleague on Plaxo Pulse.

And of course, my own company Zühlke Engineering offers tools, coaching and training to agile teams.