Two good videos

Monday was a bank holiday, so I found a little time to catch up with some of the web videos in my queue.

First I watched an inspiring session from TechCrunch Nordic which likens achieving an “exit” for a startup company to dating. Fun, and with a strand of truth.

TechCrunch Nordic – Tommy Ahlers from Mike Butcher on Vimeo.

Anyone running a startup, or thinking about it, should watch this one.

Second I watched a presentation ostensibly about Kanban and “single piece flow”, but really about much wider issues in planning and managing software development. I found the approach presented particularly interesting as it correlates very well with where my thoughts are at right now.

This video is best watched at infoq, to see both the presenters and the slides

Anyone working in software development, or managing a software project really needs to watch this one.

Maker’s Schedule, Manager’s Schedule

It’s an article from July 2009, but I just saw it. A pretty lucid description of the problems faced when mixing a “manager” view of time and a “maker” view of time.

Maker’s Schedule, Manager’s Schedule.

I face this every time I step away from single-client work to develop other business projects. The business side of my responsibilities wants a day split into little chunks in order to make progress on a wide range of tasks, most of which involve meeting or co-ordinating with other people. The software development side of my responsibilities wants a working period with the longest contiguous periods I can manage. Concentrating on either way of working always seems to be at the expense of the other.

How to be a program manager

I think its fair to say that a lot of attempts to “manage” software projects and software teams simply do not work. This is not a new problem, and a lot of smart people have had a go at it.

Recently, software and business pundit Joel Spolsky has waded in, with his take on the importance of  a “program manager”.

How to be a program manager – Joel on Software.

Andy Singleton on Managing Distributed Agile Projects

I have just listened to an excellent podcast interview with Andy Singleton from Assembla in which the discussion ranges around his extreme views on how to run highly productive distributed software teams.

Top tips include “don’t interview when hiring”, “don’t estimate work”, “don’t do conference calls”, etc… Contentious, but very well explained and justified. This podcast is so packed with thoughtful stuff that I’m sure I’ll listen to it again.

Podcast on Managing Distributed Agile Projects

Martinig’s 10 Favorite Agile Project Management Articles

An interesting collection of articles. I have read a small number of them, but I’m looking forward to enjoying (or at least complaining about) the rest.

My 10 Favorites Agile Project Management Articles | From the Editor of Methods & Tools.

Doing the wrong thing right is better than doing the right thing wrong

A very interesting post from Gojko Adzic, which seems to indicate that running a quality IT department is more important than aligning the goals of the IT work with other business objectives.

Gojko Adzic » Doing the wrong thing right is better than doing the right thing wrong

Project management using “Finger Charts”

We have a large project wall, on which paper/card stories, bugs and tasks progress from submitted through to tested. This is great for a quick view of state, but the physical movement of tokens does not help in tracking and analysing progress.

Akshay Dhavle suggests the use of “finger charts” to get a better and more useful of project progress, in particular to help identify time-related problems.

Business Analysis: Finger Charts

How much is really new?

I read a lot of blogs and articles about education, software, and video. It’s often interesting to observe the differences and the similarities between these largely separate fields. In education, for example, the casual use of the internet for sharing and collaborating which characterises modern software development is seen as a new and contentious area of exploration. When shown examples such as this it’s easy to become blasé and to assume that software practice is at the cutting edge of everything.

Ted Neward points out that this is surely not true, and give some examples where software teams have a lot to learn from other fields such as management, sociology and anthropology.

Interoperability Happens – The Myth of Discovery

Disappointed with the British Computer Society

The British Computer Society (BCS) is supposedly the professional institution in the UK which represents anyone working in the field of Information Technology (IT). I have been an associate member for many years, and most years I consider upgrading my membership to become a full member but have never actually done so. Usually the problem I face is that, despite having worked in software development for at least 15 years, I don’t actually know anyone else in the society to act as my sponsor.

This year, though, I face a different problem – my disappointment with the attitude of the society, particularly as expressed in two recent articles, published on their web site and notified to members via an email “magazine”.

The two articles in question are:

I urge you to read them and make up your own mind.

My problem with both of these articles is that they seem to express a one-sided attitude which I had hoped had been banished from the BCS many years ago.

When I first encountered the BCS (during my university time in the mid 1980s) it was seen as the bastion of IT middle management, and in particular middle management in large corporate environments. There seemed little or no representation of or for the people actually doing the work of producing and maintaining information systems, and an almost pathological ignorance of the concerns of contractors and people working for small businesses.

Over the years, my concerns waned. The society seemed to re-invent itself to become more in-line with its charter and thus more inclusive of software developers and contractors. It still struggled with the idea of small IT businesses, and of small departments or lone IT workers in other organisations, but I had hopes that this would improve, too.

But then I received these two articles, and all my concerns about the emphasis of the society came flooding back. Both articles appear riddled with the view that developers are lazy and selfish creatures who will always choose to produce rubbish unless forced by managers or testers. This is an appalling stereotypical slur, and completely at odds with the stated, inclusive, intent of the society.

I understand that both these articles were published through the society’s “blog” initiative, and thus have not had the editorial oversight that one might expect from a more formal publication. However, this does not exempt them from reflecting on the BCS. Since reading these articles a few days ago I have already had one forwarded to me by a colleague. The damage has been done.

Maybe I won’t be upgrading my membership this year, either.

Performance Reviews Banished

InfoQ have published an article which offers a compelling argument that common corporate performance reviews are fundamentally broken, and should be abandoned. While I largely agree with this premise, I don’t see a great deal of improvement in the proposed solutions.

Perhaps it reflects differences in the kinds of places we have worked, but for me an effective performance review should concentrate on a holistic view of how the individual has contributed to the success of the organization. I am worried that neither of the two proposals encourages “thinking outside the box” and doing whatever is most effective for the business. Instead, they concentrate on reinforcing existing decisions such as pigeon-holing staff into “team members” and “managers”.

InfoQ: Performance Reviews Banished

The Seven Things That Surprise New CEOs

Looks like an interesting list, especially if you know a company which is looking for a new CEO right now.

The Seven Things That Surprise New CEOs — HBS Working Knowledge

Saving lost developer time with better hardware

It can sometimes seem hard to overcome real or imagined objections to a need for improved hardware. There often seems to be an assumption that developers all just want the shiniest toys and that the job of management and company finance is to save expenditure by curbing that desire.

As developers, maybe we should get more practice making sensible business cases for the times when hardware improvements really make sense.

Kris Kemper » Blog Archive » Saving lost developer time with better hardware

InfoQ: Seniority, Respect, Authority and an Agile Team

A summary of some views and discussions on the idea of seniority and how it is affected by an agile approach. No real answers, but an interesting read.

InfoQ: Seniority, Respect, Authority and an Agile Team

The Crunch Mode Paradox: Turning Superstars Average

A thoughtful analysis of the practice of “crunch time”.

James on Software: The Crunch Mode Paradox: Turning Superstars Average