Book review: TSP - Coaching Development Teams

One of the little knows secrets of the ACCU is that members can get free books.  All you have to do in return is to write a review.  The review will be posted on in the ACCU book database on the website (available to anyone free of charge) and most likely (space permitted) included in an edition of CVu magazine.

Members can get a full lists of the books waiting for review from the website, and none members, well… think how much your £35 membership fee could save you.

As regular readers of this blog will know I’m very interested in the subject of coaching.  So I decided to review the latest book from Watts Humphrey (farther of the CMM) TSP: Coaching a Development Team.

The review will appear online soon and in CVU a little later, but for blog readers, well, you can have it early…

Coaching seems to be everywhere these days.  I know I've been banging on about it for a couple of years but I am not alone; Phran Ryder wrote about it in CVu last year; several of the Agile methodologies suggest a team coach; and the general press seem to cover business or life coaching every month.  Now the Software Engineering Institute at Carnegie Mellon University (yes, the people who brought you CMM and CMMI) have decided to jump on the bandwagon too.

I should perhaps state my bias up front.  Good stuff does come out of the SEI but my first reaction to anything they produce is scepticism.  I know this isn't good of me but I recognise the bias and try to compensate.  In reviewing this book I'm trying to be even handed.  And in truth, a lot of what does come form the SEI is well researched and thoughtful.

So to the book. This is one of many books from the SEI that covers the "Team Software Process" or TSP for short.  Now I don't know much about the TSP so in reviewing this book I was hoping to learn a lot about coaching development teams and a little about the TSP.  As it is I've learned a little about coaching development teams and a little about the TSP.

The book is completely true to its title.  Lets take it word by word:

• TSP: The book is TSP based, TSP runs through everything in the book.  I felt at a disadvantage because I don't know the TSP and this limited what I could get from the book.  Neither is it a book to learn TSP from.


• Coaching: it seems the TSP takes a very directive approach to coaching and assumes the coach is the TSP expert on the team.  Manager and developers look to the coach for help running the process and resolving process issues.


• Development: its about software development teams (who else would use TSP?)


• Teams: between the TSP advice there is good advice for team coaches.  Unfortunately the author tends to use more words then necessary.  The book could probably have been written in half the number of pages.

The feel the book is culturally biased towards large American corporations, maybe these are the only people who use TSP in which case it doesn't matter.  But if you are European, Indian or a small corporation I wonder if you will find the book so applicable.  Other than this the book is well written and the author knows his subject.

In summary this book is true to its title.  It is about coaching TSP teams.  If you are coaching another type of development team you will learn something here but there are other sources were you could learn more in fewer pages.  If you are coaching a TSP team you might well find this book very valuable. 

To the best of my knowledge nobody has yet written a good process-neutral book on coaching development teams.  In the mean time if you need to coach a team, and they are not following TSP, I suggest you read some of the more general books on management coaching. 

IT is from Mars, HR is from Venus

In general IT and Human Resource departments do not get on well together.  To be fair to IT I'm not sure any department in a company gets on brilliantly with HR but IT seems to get one worse than most.  I once worked for a company where one senior manager claimed "I only work for small companies, as soon as they get big enough to have an HR director I leave."  True to his word within a year of the firm appointing a permanent HR director he was gone.

When you look at it the two departments really are opposites.

• HR is generally staffed by people who use people skills, they do touchy-feely, they do form filling and the do structure.  HR comes along late in a company's life; nobody founds a firm by starting with an HR group.  HR is also, if we believe stereotypes, largely staffed by women.


• IT - and really I'm talking specifically about software development groups - are the reverse.  They are staffed by people who don't know the meaning of the word touch, generally dislike form filling (why fill in a form when you can create an electronic systems?) and are creative.  Software developers are often the first people in a start-up company.  And on the whole the teams are male dominated.

To be fair to HR - and I have been known to stand up for them in the past - they do have good intentions.  HR departments can be a force for good in a company and they do work that does need doing in big companies.  On the whole IT people do not appreciate this.  Which just goes to make the conflict so much worse.

I've commented on this subject before.  Then I gave two reasons: firstly that HR groups just do not understand IT and secondly that you actually need damn good HR people if they are to benefit IT. 

So why are software developers so different form the other groups HR works with?

Well I think there are some characteristics of development teams which alienates them from HR people.  Other groups and individuals have these characteristics but in software development they are more common and more pronounced:

• Technical skills are to the fore and social skills can be non-existent.  I think the developers of tomorrow need for more social skills than those of yesterday but still technical skills are key.  This is the opposite of HR departments themselves where social skills are more important than technical skills.






• Software developers often appear to job-hop.  A year here, two years there, six months there.  To a classical HR person this looks risky, will this person be with the company in three years?  But actually this can give a software developer a lot more experience than they would get from working on the same code base year after year.
  

  And it is not really developers' fault.  Much development work is project based, teams expand and contract, therefore people move teams and people move between companies to follow the projects.  Further more because so many software companies are start-ups the risk of company failure and redundancy is that much higher, it is an occupational risk.  Unlike HR departments which only exist in safe companies.

  
  

  The really odd bit is that the best developers may have the most fractured CVs.  If you are good you will be hunted.  If you are an average developer you are more likely to stay in one place because fewer people want you.  Simply good people move.  This is the opposite of what HR expect.  Part of this is because...

  
  
• Productivity varies:  good developers can be twice or ten times as productive as average developers.  In fact one study I saw put it as high as 27 times more productive.  Yet do you see this in their pay?  Many of us have met hyper-productive developers but have you ever met one who was paid twice or ten times more than the average one sitting next to him?
  

  These kind of difference mean that developers who are a little bit better than average can be significantly more productive.  Thus becomes more important to be able to differentiate between someone who is 10% better than average and someone who is 15%.

  
  

  As a result a good developer can consistently extract more economic-rent from an employer.  Because paying people these sorts of differentials is alien to HR groups they don't do it thereby leaving the gate open for someone else to.

  
  
• Software developers often lack traditional career markers: in other words they generally don't do sport.  They were never school team captain and - if they are like me - spent their teenage years in front of a computer honing their skills.  And they don't move up the career paths into management.  If you have a great developer then keep him developing, do not force him into management if he wants to carry on cutting code.

This is all leading up to one more difference.  The best software developers are clever, very very clever.  There is a scene in the BBC film "Breaking the Code" where someone from the Ministry of War tells Alan Turning "You are much more intelligent than most of the people around us.  That makes them very nervous."  I think that effect is at work too.

So what can be done?

There needs to be work on both sides.  HR needs to appreciate the special challenges and demands of managing IT resources and especially software developers.  IT needs to recognise how HR can help and the corporate need for HR.  But this may not be enough, we may need a structural solution.

A few months ago I visited the offices of one of the UK's leading national newspapers.  There are two sides to a newspaper: the business side, including production, advertising, marketing, accounts, etc. and then there is the editorial side.  Because of the need to keep editorial independent this needs to be handled by journalists.  Therefore, there needs to be two HR departments.  The first is for the bulk of the employees and the second is just for the journalists.

I suppose the main HR group could handle the routine admin like payroll, tracking holidays etc.  but to have journalists governed by the same management structure could compromise editorial independence.  So they have their own HR group, staffed with managers from the editorial side.

This model could work in IT.  I can imagine a new role inside the group "Technical HR manager".  This person would be involved with hiring, performance reviews, etc. etc. but they would know about technical people in depth.  They would come from a technical background themselves.

Although this might sound like a drastic change I think it is reasonable.  Companies which depend on software development really bet their future on their people.  They bet that their people can develop better technology than the competition.  What appears to be a technology based business is in fact a people based business.  There is vast difference between having above average people and above above average people.  Just go and ask Google or Microsoft.

Ironic isn't it?  HR departments can't be trusted when human resources are the most important thing.

And that's another thing, why on earth did we dump the name Personnel Department? We are not talking about some plug-compatible resources here, we are talking about people.  Living breathing people, not resources.

My guess is that Personnel Departments dumped the title so they could put themselves on a part with the money and machines, the other resources; in doing so they lost sight of their key differentiator.  When people are key you have to treat them as such.

I have an ISBN number!

OK I admit it, I do vanity searches.  I was at the Amazon website for something today and I did a vanity search.  The differences this was is: I was.

Changing Software Development: Learning to Become Agile is now listed as available for pre-order.  The other surprising thing is the publication date.  I was expecting January 2008 but it appears I’ll make 2007.

And if your interested the ISBN is 047051504X, or in the new 13–digit ISBN system: 978-0470515044.

I had better get on with the index then!

Back from EuroPLoP

I was out at EuroPLoP in Germany last week, and much of this week has been spent in recovery mode.  EuroPLoP is a great conference – or rather un-conference.  Unconference is an expression I first heard last year that describes a conference which is different.  EuroPLoP is certainly different.

EuroPLoP is first and foremost a pattern writers conference.  So we spend time reviewing peoples papers not listening to presentations.  We spend time playing games together.  Actually this bit is essential because it builds the community and helps you take the feedback in the reviews.

We also hold open ended discussions (focus groups), drink (free) beer and talk, talk, talk.  At breakfast, lunch, dinner, in-between and in the sauna.  Some of the best conversations are in the sauna.

Our conversations revolve around patterns, software development, teams, books, writing and, in my case, business models.  There are more and more patterns being written about business, it is only a matter of time before someone publishes the first book.

As an aside, one of the founders of the European Patterns movement, Frank Buschmann, was at EuroPLoP.  He mentioned some research he had seen about software engineering literature.  It seems that the most referenced software engineering book (not including text books) is…. Design patterns (aka “Gang of Four book”).

(Unfortunately I don’t have the reference to hand, I think it is Paul Clements and others from SEI at CMU.)

The second most references book is Pattern-Oriented Software Architecture Volume 1 "POSA 1" and "POSA 2" (Pattern-oriented Software Architecture Volume 2) also makes it into the Top-10. 

In fact 6 or 7 out of the top 10 books turn out to be pattern books.  To me that says Patterns are on to something. 

Unfortunately, all too many developers don’t know about patterns and those who do only know the 23 in the Gang of Four book, and of those 23 Singleton seems to be know more than any other.

The other news from EuroPLoP is about me!  The conference committee decided to make me conference chair for 2008 and 2009.  I have to admit I am a bit worried about the work involved and tried to avoid the post but I was persuaded. 

Wow, me, conference chair…. I can hardly believe it!

Indian outsourcing gets more expensive

I’ve been saying for a while that there is no need to panic over the outsourcing/off-shoring of software development work to India.  As far as I am concerned the pie is big enough, it is expanding, and India is not the right place to do much of this work.  The right place is right next to the business.

Add to that economics.  India may produce a lot of computer science and engineering graduates but less than 10% of them are useful to the industry.  Of those that are there are not enough to satisfy demand, staff turn over is high and wages are rising.

Just before I left for EuroPLoP I saw this story in the FT “Bangalore wages spur reverse offshoring”.  The story even made it to the editorial column too  “Outsourced to the US”.  Basically wages are rising and the price advantage is disappearing.

As I predicted (December 2006, July 2006 and June 2007) India is pricing itself out of some types of work and it is more economic to do the work in the high-wage US or Europe.

Even if India staff are cheaper you have to factor in:

• Communication and travel costs.


• Additional processes, procedures, documentation, etc. which you don’t need when the guys are down the hall.


• Delays in responding.


• Cost correcting cultural differences, and extra costs in being specific.

It makes sense to offshore some work to India (or China, or Russia) but not all work.  You have to judge these things on a case by case basis. 

Unfortunately one side of this I haven’t accounted for before is management that believe the hype.  If you are attracted by offshoring to India you must go and do your own analysis: count all the costs, assess the risk, look at the time it will take, etc. etc. 

The unfortunate bit is I think some managers are not doing this.  They are jumping on the bandwagon when it doesn’t make sense.

More unfortunate, as far as I can tell there are far too many start-up India outsourcing companies willing to cater for unprepared managers who want to outsource.  I suspect the big, well established, companies want projects that succeed.  They will avoid work from unprepared managers looking to ride the bandwagon.

However, the smaller companies just want work.  They can’t afford the luxury of turning work away so they will accept it from even the most ill prepared companies.  So you get the unprepared working with the worst possible partners.

And that is why, some companies have great offshoring experiences and most have failures.

Unit testing (from objectives)

Still responding to the questions posted in response to my TDD and objectives entry. The question was about how to do TDD, specifically UI and also about what happens when the general consistency fails.

Well the UI question is easy: You can’t really do TDD for user interfaces.  You can, but you have to jump through hoops to get your test framework to push buttons.  Of course there are tools which will do this for you but these usually fall into the realm of ATDD (Acceptance TDD) and system testing.

But, what TDD can help you with is the logic behind the UI.  We all know we should separate program and business logic from the UI but we also all know it has a habit of getting in there.  Well if you are practising TDD you separate the two (as you know you should) and you can TDD the logic and leave the UI as a lot more trivial. (And testable with other tools.)

The other way of doing it is to test the output.  Increasingly application emit XML or HTML to generate their user interfaces and you can test that.  You can test small segments of XML to see if it contains the expected data.

For me the secret of TDD is that it is a Design technique, thats what the second D stands for after all.  It is about designing your code with tests rather than UML, or flow charts or what ever.  You do it before you write the code, it forces you to think about what you are about to write and that is design.

Second part of the question: general consistency.  Well, true, a little change might break a lot of tests, but actually you want that to happen.  If someone removed operator== then you want your tests to break because it highlights the change. 

A good set of tests round your code ensures that any unexpected changes are found quickly.

Of course, when you make a significant change in your code you might find a lot of tests broken, and you end up having to fix lots of tests but:

• Firstly a major change should product major breakage so you can get it right


• Second a well structured, properly separated design, will be less prone to breaking.  Writing tests is itself an engineering exercise.

All in all TDD promotes a lot of good practises which we know are good but somehow forget to do.

 

Objectives again

I don’t normally respond to comments on my blog.  Most of them don’t actually require anything more to be said but on this occasion I thought I should respond.  And keeping to my one entry one comment policy I’ll take them both separately.

So, the question was: Am I changing my view on objectives?

And my answer is: It depends; in this case I’ll wait and see what happens.

I think it is worth knowing what you are aiming for.  I think setting your own objectives is worth while and can help improve your performance.  And I think they are a good way of communicating priorities to and from management.

I also think that if you are going to have explicit objectives it helps if they can be more objective than subjective.  So, the SMART rules make sense.  But… well, there are problems….

Not everything you want to aim for can be specific or measured.  Quite often we operate with ambiguity.  A lot of my work is ill defined, trying to make it better defined can be useful but it can also be counter productive because things will change.  I’m not really sure what my goal is or should be, I just kind of know the general direction.

There is also a problem with the achievable and realistic part of the rule; in a word setting realistic goals encouraged people to satisfice.  If your promotion, pay rise or bonus depends on meeting an objective then there will always be a tendency to aim slightly lower, for something that is more achievable.

As much as they can improve communication between management and workers they can also be the source of misunderstanding; when they are imposed on people, when management sets the objective and forgets about them for a year, or when management sets them and then abdicates all responsibility for helping someone meet them.

So I stick by my answer: it depends.  I’m in favour of objectives when they are used appropriately.