Measuring actuals considered harmful

I don’t quite know what it is, but some project managers really like to measure ‘actuals’. They say it helps them plan better, and that it helps them predict the end-date better. Again, thanks to my love of the dramatic, the title of this article is a tad more severe than what I really mean. In this post, I only make the point that many project managers measure unnecessary things, and often the wrong things – and understanding the what, the how, and most importantly the why, of metrics can make a world of difference to the overall success of a project.

People who advocate ‘measuring actuals’ often mandate their developers report how much actual time they spend working on a user story. So, let’s say that a particular card was estimated at 100 points of work. If the developer pair spends 2 hours working on unexpected build-failures, 1 hour on a staff-meeting and another couple of hours fixing bugs on a story from the previous iteration, then they must report a total of 5 hours less than the total time they might otherwise claim for the card. They must also, of course, report the 5 hours separately.

Often, developers are required to update these numbers on a daily basis. Sometimes even on a per-task basis. (Ouch).

These PMs then subtract the total amount of actual time the team worked from the total available time (capacity) to determine what is sometimes called ‘drag’. The ratio of drag to capacity is their ‘drag factor’, and they then use it to plan the remaining work and predict the end date. I believe this practice is less than optimal for several reasons.

The first reason is that it is painful to report time like this. Ask any developer. It distracts from writing code and breaks flow. And if part of the process doesn’t directly add value to the software being built, it should be a candidate for streamlining. It also sends a signal to the team that tracking/accounting/number-crunching is apparently more important (or at least as important) to the management as the value of the software being built. A related reason is that PMs and HR in certain organizations use these numbers during performance reviews. This, of course, makes the measurement completely useless (because using the numbers in this manner alters behavior too much for the measurement to be accurate anymore).

Another reason I don’t like calculating ‘drag’ and using it to plan future work (and predicting the end-date) is that it simply gives an incorrect answer. This is because a truly agile team that is doing the right things will always see an increase in velocity, iteration after iteration. And so, using drag to project plans becomes less than accurate. That leaves even lesser value in measuring and calculating it.

Now, assuming that the end goal is better estimation of the end-date and a better idea of current rate of development, measuring actuals in this manner is not the best way to achieve it. That’s simply because there is a much easier and more efficient method – it’s called velocity.

It’s called velocity for a reason – it helps answer the question ‘are we there yet?’ Take the analogy of driving a car from city A to city B. Since the drive is long (Google Maps estimate it will be about 12 hours of continuous driving), you make several stops along the way. Making the stops is natural, so when asked how long you might take to get to city B, your answer will usually include those unproductive stops; so you might say – about 15 hours. You don’t say – well, if I stick to the speed limit then I’ll be driving for 12 hours, and I’ll also take a one-and-a-half-hour break for lunch and to recoup a little, and two or three other half-hour breaks. It only matters how much total time you might take to get to city B.

Software development also has a convenient metric like this – and as mentioned above, it’s also called velocity. It is the total amount of work that gets done per unit of time (usually an iteration). This already includes things like meetings, lunches, bathroom-breaks, training, filling out review forms and so on. The total time spent, of course, is a matter of counting the number of developer bodies that were in the team-room for that duration, and multiplying by the number of days in question. Done.

Now – a confession. I do care about ‘drag’. I care about it because by reducing it, the project can move faster. This, however, is what the PM or Scrum-Master should be watching out for during the day, every day. If developers (or BAs or QAs) are being pulled out of the team room into meetings that do not add value directly to the project, then the PM should work the system to get these meeting cancelled or, at least, get the concerned folks out of them. If builds are constantly failing, the PM should sell to management all the benefits that the team will get from an improved build-system. Letting the team refactor ugly parts of the code follows the same reasoning – and sometimes, these refactorings might become rewritings parts of the system. It is the PM’s job to do the cost-benefit analysis with the help of the technical folks, and get permission from management to do the right thing. These things ought to be the goal, not telling management that the team only got 1200 points done because of a 30% drag.

So – the takeaway? Don’t measure actuals the way some people do. Use a ‘drag’ of 0 percent for your iteration planning. Use historical team velocity to estimate team capacity. Be vigilant about the time your team spends on non-project-related things, and fight for them to reduce that time. Enable them to optimize themselves (refactoring, investment in fixing annoyances, better software tools, outings), and watch their velocity increase along with quality. Your job becomes easier, too!

Pay incentives vs. motivation

I’m sure you’ve had many conversations with people about what motivates people, and how to get them to work smarter or harder or to get them to do the right thing. Compensation – money, stock options, bonuses, and other similar perks quite often figure in these discussions. Yet, there is usually a thread about how these don’t really seem to work that well, or perhaps not at all.

Here’s expert commentary from someone who has spent many years studying management practices – including what kinds of incentives work – such that people are intrinsically motivated to do the right thing towards the end goal. This testimony was given to congress, no less.

[Originally from Esther Derby]

Multiple stake-holders and Agile

There are many times when a team ends up with having to deal with multiple simultaneous stake-holders, or at least with several external folks that have an interest in what the team does. As they all try to direct and prioritize the team’s work, often in a somewhat contradictory fashion, the team finds itself thrashing as it runs down one path of execution and then another the next day. This makes the situation sub-optimal and leaves team-members feeling unsatisfied as they get almost nothing done.

How does a project-manager or scrum-master handle this? After all, while the scenario described can clearly distress a team, it also affects the scrum-master in quite a stressful way. I’ve seen many people try to find a “real” solution by attempting to get all the stake-holders in a room together and try to get them to come to some form of consensus. This is definitely something worth pursuing, but often, this can take a long time in many large organizations. Eric Anderson, a colleague, and I were conducting a retrospective the other day when he made a comment about how one can use a basic aspect of the Agile process to help clarify the direction for such a team.

While each stake-holder feels that his or her agenda is as important as anyone else’s, quite often, everyone involved is aware of the overall goals for the team. When faced with clear consequences of picking one priority over another, they can make good decisions. In many cases, the issue is not as much one of conflicting goals, as much as it is of not having a clear picture of the outcomes of going down routes with different prioritization. Agile processes excel at elaborating just such scenarios. Every time an alternative presents itself (say in the form of a stake-holder changing direction or changing priorities mid-sprint) the project-manager can juggle the sprint and product backlogs (or master-story-lists) to show how that change might affect implementation of other features downstream. When things become as clear as particular areas of functionality being pushed out to particular (approximate) dates or even outside acceptable timelines, it becomes a lot easier to reconsider and plan accordingly. It makes it easier to think in terms of the project and the team instead of particular agendas or personal beliefs of priorities.

So, the take-away is, one doesn’t need new tools or techniques to resolve problems that arise due to multiple customers or stake-holders or interested parties. Simply taking each plan (based on each person’s idea of priority) and demonstrating what they would do to the overall project deliverables is often enough to get everyone together and on a similar page. Of course, getting the various stake-holders to work as a team and funneling requirements and priorities to the team as one entity is still the ideal situation to be in. Demonstrating the above described projections may help getting the right conversations started.

Why work at ThoughtWorks?

Update: I’ve answered a few questions people asked about this post.
———

I started my career at IBM. My dad had bought me a PC when I was seven and I started programming computers when I was 10. I’ve always felt most comfortable sitting at a computer screen, trying to communicate with a peice of silicon, than in any other situation. Mostly, anyway. And so, when I graduated with a degree in electrical engineering, I wanted to work at a company that understood computing and software, a company that built software that solved real problems.

This thinking sort of explains how I ended up at IBM (Global Services). Oh, what a load of…. Let’s just say I got out of there as fast as I could.

I joined ThoughtWorks about 5 years ago. And I’m still here. Every time someone asks me how I could manage to stay at one place after all this time, I feel like I’ve been asked a question like “How does one write good software”? I mean this in the sense that there are so many different aspects to the answer that a one or two sentence response can hardly do any justice.

So, what do I find so compelling about ThoughtWorks? First of all, and this is something many ThoughtWorkers will tell you, its the people I get to work with. Almost all are exceptional folks – smart, innovative, and sincere. They’re courageous. They’re caring and well-meaning. Many are actually quite funny. Working with these people on a day-to-day basis is quite a pleasure.

Related to this, is the fact that ThoughtWorks as an organization, truly respects and cares for its people. For example, if I needed something changed about my current project or if I got bored with my role or if I wanted to go to a seminar or something, I could tell someone and more often than not (as long as I wasn’t being totally unreasonable), they would try to fix things for me. It’s quite nice.

ThoughtWorks is a very flat organization – there are hardly any “levels”. There are, of course, roles on every project. Anyone can walk into anyone else’s office to question things – for the most part – without any thought of “proper channels”. As I mentioned earlier, I was at IBM for a while, and since leaving them have consulted at many large companies… believe me, ThoughtWorks is hugely different! Individuals are respected for what they are, not because of a title they might carry. Speaking of which, at ThoughtWorks, you can pick any title you want for your business card – mine says Jedi Master.

One other thing about ThoughtWorks that to me personally is quite enticing is the fact that we play with lots of bleeding edge innovations. We are thought-leaders in the Agile arena, we were early adopters of Java and J2EE, of dotnet and more recently of Ruby, Ruby on Rails, and other dynamic languages such as Python. And I’m talking about applying these things in an enterprise scenario. If it can add value to a client, then ThoughtWorks is not afraid to bring it up as an option. And from a techie point of view, this works out great! ThoughtWorkers are also heavily encouraged to contribute to open-source projects, attend conferences, write papers and books, and in general participate in the community of software development. ThoughtWorks is usually quite happy to support these activities with money – it’s quite fantastic!

There are tons of other things. How about – “architects” actually needing to write code? How about lots of social activities and events – things like geek-nights, dinners and drinking (lots of drinking!)? How about that most people who work here actually have passions outside of work, and can have meaningful and spirited conversations on just about any topic? Even political or religious beliefs? As a company, ThoughtWorks cares about social issues – not that we can always do a lot about everything, but it’s not a faceless corporation that exists solely to make money. Speaking of which, ThoughtWorks is privately held, which means – no pesky shareholders to bother us. Well, almost none.

I want to touch upon innovation again. Apart from the many things that ThoughtWorks is famous for, it also has several open-source projects to its name. More recently we also started a couple of internal teams on product offerings. We looked around and found that the software development industry, as a whole, was missing effective tools for certain things. I can’t say too much just yet – but you can expect to hear some pretty cool things pretty soon.

Another area where we’re innovating is Domain Specific Languages (DSLs). There are really two things – marketing-speak for highly maintainable and customizable systems (the idea being that business users can express or modify business rules using an English-like language steeped in their own domain, for example insurance-gobbledegook) and elegant design with a clean implementation that allows this to be possible. It really is wine in a new bottle (ask any Lisper), but with Ruby and Python gaining popularity in the “enterprise”, this kind of a thing is becoming more accepted. Bottom-line, people get to work on cool stuff and push the envelope on how business systems are being built. Clients get more value for less.

What else is great at ThoughtWorks? Agile processes – XP,Scrum, and the like. Nothing great about a process by itself, of course, but at ThoughtWorks, most people truly get software development. And when you assemble a project team from a bunch of such people, they often end up with an ad-hoc process that is remarkably similar to the name-brand processes mentioned above. In the words of a ThoughtWorker colleague, you can’t do agile, you can only be agile. Further, “common” wisdom states that Agile processes work well only for small teams. We’ve been scaling these processes by being agile for many years now. The current project that I’m working on (as a scrum master/project manager) has a team with a 100+ developers and is based out of three locations – the US, India and Sweden. How do we do it? Carefully.

I feel like I’m writing an infomercial. But there is one more thing I wanted to throw in. This is about the highly trans-national nature of ThoughtWorks. Since 2002, I’ve worked with ThoughtWorkers from more than a couple of dozen countries. The cultural explosion is just awesome. We also have an international exchange program where you can opt to work in another country for a period of time (typically 1+ years) – and a lot of people take this opportunity to travel and work in different environments and cultures. Our new hires get sent to India to what we call ThoughtWorks University for a few weeks to learn about the company, processes, technologies etc. Further, people also transfer out to various other offices. I started out in our Bangalore office several years ago, for instance, and moved to the Chicago office in 2003.

Overall, ThoughtWorks is a phenomenal place to work. Obviously there are drawbacks to working here – the travel is most often upto a 100% (leave home Sunday night or early Monday morning, and go home Thursday evening or on Friday). One other thing – and this one is pretty important – not all projects are sexy. It’s true! We’ve had several people join ThoughtWorks who’d only heard the awesome stuff we’re about, and then felt let down because their project was “regular ol’ dotnet” at some “typical large client”. You have to remember that apart from being all the cool things I described above, ThoughtWorks is a real business and we do a range of different kinds of projects. Sometimes they’re slick and sexy, sometimes they’re slow and steady. It’s the nature of the consulting business.

Finally a few last points before I wrap this up – being a small company, there’s less “security” here than there is in a large organization like IBM – although I’m not sure how true that is anymore. Also, we’re fundamentally an application development company – so if you want to work on embedded systems or compilers, maybe IBM is a better place for you. We’re also not Google. Yet. This means no huge salaries, no stacks of stock-options that translate to retired young millionaires. Yet.

In any case, as far as ThoughtWorks is concerned, at least in my mind, the future is extremely bright. We’re growing, we’re innovating, and we’re only in six countries so far…

P.S. Two more things not in favor of working here – you have to battle Lotus Notes, and not everyone has moved to a Mac yet.

* We do have a VC on board – we had taken their money during the dot-com high.

On developers who become project managers

We’ve recently been having quite a few discussions at work around what makes a good project manager. One, what I thought, rather odd remark someone made was that a person’s developer background can work against him (or her). Ouch!

I believe that is a bizarre statement. It’s like saying – someone with a background in advertising should not lead a marketing team. Why? Because it becomes easy to get tied down into details of the work – rather than looking at the bigger picture, and towards the overall success of the effort vs. whether or not the actual work was fulfilling enough on any particular dimension.

Hmmm. Interesting. In my view – if a person can’t elevate his mind to look at the 10,000 foot picture or even the 50,000 foot picture (or whatever the “high-level” is supposed to be), then that is the fault of the thinker – not of his or her particular background. I’ve seen managers without developer backgrounds that love to poke about in the business of programmers trying to do their job. Not only do they make fools of themselves in the eyes of those very people, but their sea-gull management also leaves the project further away from achieving success. The same holds good for the argument that developers tend to trivialize the administrivia of project management. I think that that is at the very most a correlation, not a cause. I’ve seen plenty of non-technical folks mess up adminstrative tsks. And I’ve seen developers do a fantastic job at mundane tasks – sheerly from doing what their logical, step-by-step mind tells them they should.

I’m sorry if I’m being idealistic – but I happen to think someone who leads a company that makes cars should actually know something about engines. And a manager who wants to run a software project should have developed code sometime in his life – for a living. Preferably, he should still be doing it.

Now, to be fair to the person who made this comment, I’d like to admit to one thing. There can be managers who are/were developers who do a worse job than other non-techie managers. Just as there can be non-techie managers who are just so poor at their job that they single-handedly kill software projects wherever they go. I think the spectrum looks like this –

[Bad managers (techie and non-techie)] – [good managers (techie and non-techie)] – [good managers (techie)]

Anyone can fall towards the extreme-left side of the scale. And good, people-focussed managers can fall towards the middle and sidle towards the right. The good guys are in this very region – and can include techie and non-techie people. But to fall on the right-most part of the scale – (again, in my view), you just have to have a mind that truly gets software development. And that also means to understand what an asynchronous event is, and why they’re harder to write tests for. Or why dependency injection is a Good Thing.

Also, I’d like to admit that there are managers who can fall on the extreme-right of the scale without being technical – by the sheer dint of their people-skills, communication abilities and understanding of the software development process. So much so, that they make up for their lack of knowledge about the very thing being built by their own team-members. Sometimes, domain knowldge makes up for a little bit of this lack. Unfortunately, these people are few and far between.

I’m saying this from the most general point of view. There are projects and situations where this may or may not apply. I do believe, however, that this is the case in most projects and companies. Finally – rather than repeating what Joel Spolsky has already said in his inimitable style – I’ll leave you with this link to his essay.

Recruiting and the Butterfly Effect

Everyone has heard of the Butteryfly Effect. (Maybe you’ve even seen the movie by that name – I’m sorry, if you have!). Anyway, according to WikiPedia –

“The Butterfly Effect is a phrase that encapsulates the more technical notion of ‘sensitive dependence on initial conditions’ in chaos theory. The idea is that small variations in the initial conditions of a dynamic system produce large variations in the long term behavior of the system.”

When a startup is founded, it is typically done so by a few friends. They’re like-minded or at the very least, focused on the same goal. They are also pretty good at what they do (despite the fact that most startups fail). Without me having to list a whole bunch of wonderful characteristics of this set of people, lets just agree that they all have some desirable characteristics. Not only that, but these folks make the bar that was set on the standard around these characteristics.

When this company grows to the point where they need to hire more people, they are extremely careful in making sure that they hire people like themselves. They hire all the new folks themselves, because they want to preserve the quality of the people that work with them and are like the “model-employee” (geeky, brilliant, marketing genius, a combination of these, whatever).

Being personally involved in hiring (interviewing – I use the term hiring to mean interviewing from here on) can continue upto a point – and then they can no longer do this. Already, because of the fact that no two human-beings are perfectly alike, they have no real model employees, just very smart people who have most of the desirable properties in sufficient amounts. Let us call this deviation from the model, d1 and label this set of employees who were personally picked out as wave-1.

The moment someone other than themselves start doing the hiring (wave-2 and so on), the deviations start compounding. This is because everyone in their mind creates a mental model of the ideal employee that differs, atleast ever-so-slightly, from what they understood was the “model-employee” from the people that hired them. This is inevitable – these are all smart people who are empowered to draw inferences and make decisions. We now therefore have wave-2 and deviation d2. Total deviation at this point is not just d2, but d1d2. If wave-2 starts hiring further employees, deviations start compounding – d1d2d3…dN.

There comes a time, when the total deviation from what was desired is now more than a tolerable threshold and things are different from what they were meant to be. This is a manifestation of the butterfly effect. This is because, in the end, everything (for eg. working at a company) can be reduced to the people involved. This is what probably happened to most large companies of today.

What is my conclusion? People with as low a wave-number as possible, must stay involved in hiring. You can not expect wave-Z folks with a deviation of d1d2*d3…*dZ to be able to hire people who are like wave-1 or wave-2. ThoughtWorks as a company is at times, guilty of doing this and I think a part of the blame is attributable to the fact that its growing too fast – it has become less feasible to apply this conclusion.

Of course, a lot of caveats apply – things change over time – models change and desirabilities change. But I think this hypothesis still holds good. At the very least, it is useful to recognize this phenomenon. To collaboratively create something that is as subjective and personal as “a great company” and to be able to stay as close as possible to this vision , it is imperative to keep people who buy-in and fit-in to the vision the most, completely involved in the inevitable expansion process.

Easier said than done.