Agile Lab Blog

I get this idea of “junking” from my pitiful thin understanding of the world of finance. As I understand it, some guy (I think he ended up in jail) found out that certain kinds of bonds called “fallen Angels” performed better than they were expected to perform. There were corporate bonds, where the corporations that had issued them had got into some kind of trouble (like borrowing too much) and so their bonds had become doubtful in the eyes of the market. When people in big suits with loud voices started trading these bonds, they started to call them “Junk Bonds”. Well for a while, this guy made a lot of money trading in these bonds. But there weren’t that many of them.  So then he had a brainwave!  Why not artificially  make the bonds in a company risky.  Why not make lots of “junk bonds.” The way they do this with bonds is something called “leveraged buy-out.” Which I think involves buying the company with a loan secured on the company’s stock, or something like that, this really is the extent of my knowledge, whatever you do, don’t take financial advice from me.

This is what seems to happen to succeeding development teams - they get junked. What do I mean by that?  I mean that if a team starts to deliver valuable software in a timely fashion, the first instincts of management will be to break it.  There are a couple of ways to break it.  Give it *lots* more to do e.g. if the team’s velocity is 50, insist that if they give luxuries like toilet breaks and coffee breaks and lunch breaks, well then it should be possible to get it up to 100. Lets say you’ve got a backlog, and, given the experiences of previous iterations and releases, everybody is agreed that there’s a 95% chance that you’ll deliver this on time.  Well hell! In that case, let’s add a load more stuff until the chances of it all being delivered are only 50%, or less. Hence, overnight, a “successful” team becomes a failing team. Another way to break a successful team is to literally break it.  Split it into 2, 3, 4, 5, 10 pieces (I’ve hear all of these suggested).  If you were really serious about doing this, the way to do it would probably be gradually increase the size of the performing team and then split it.  Or rotate people from other teams in and out of the team (you’re doing pair programming - right?)  Or, even better (i.e. much worse) give everybody on the successful team another job, so that they’re now only “75%, 50%, or even 30% working on the successful team.

Now the really clever/cynical/jaded amongst you might have realised by this point that there is an obvious lesson that comes from this. Never ever (or certainly, very rarely) give the impression that you are on time and to budget, it will result in your carefully built-up team structures being either broken up or being overloaded to the point of breaking. Junk your projects before anybody else gets the chance. Perform your own leveraged buy out.  This doesn’t actually have to be as cynical as it sounds.  All it means is that you maintain a strong understanding of what the business priority is for the backlog, so that you really are delivering value to clients. Also, maintain a realistic understanding of what the velocity is through that backlog, so that it’s clear in your mind which bits are unlikely to get done in a particular timeframe. Then, crucially make sure that your team is clear that no matter what gets said in senior management pep talks they should work at a sustainable pace (set an example, keep reasonable office hours yourself).

Now, I’ve just tweeted a quote from this post, and it’s attracted a couple of re-tweets and a couple tweets suggesting that I’m being very “negative.” So this might be a good time to warn of the dangers of being this “negative” openly.  Michael Milken went to jail.  Some say that he did nothing other than countenance a certain kind of “negative” thinking.  This is similar to the bizarre hatred for “short sellers.” The truth is people don’t like negative thinking.  So admitting that your aim is ever going to be anything other than “on time and to-budget” may be dangerous for your career. Even so that doesn’t mean as a scrum master/project manager, you can’t have a more “mature” and subtle approach.