epistemologic

Amit Rathore’s blog about software project management

Archive for February, 2007

On lean software development: Just-in-time vs. dependency management

Posted by Amit Rathore on February 27, 2007

One of the basic tenets of lean software development is that you try to delay decisions and commitments. This allows you to stay as flexible as possible because you have the most number of options for as long as possible – that is, before you actually make a decision that narrows down those options.

However, this becomes a cause for concern when planning and running a non-trivial and/or large project with multiple teams working in parallel. A big part of ensuring maximum throughput in such a scenario is making sure that dependencies between teams are not missed and that they are played out in a correct order. This ultimately ensures that blockages are held to a minimum.

Most often, to achieve this, many project managers step up planning. The idea behind this is to analyze a lot of the upcoming work, see what dependencies might lurk in the expected work, and ensure that each team plans to work on them before they block another team. This approach, that of planning as the answer, is definitely useful. It is a tad misleading, though. This is because it gives the illusion of having things under control. The trouble is that software development is extremely susceptible to even small changes. And, as anyone who has ever written software knows, changes happen. Quite often. Plans, as they say, are mildly useful as best. Instead, it is the planning itself that holds the value.

What I’m saying then, is just that in my experience, the amount of effort spent on planning never seems to a) cover everything, and b) things change along the way to make the whole exercise decay in value exponentially. This is not to say that planning is useless, of course – see above.

Instead, I believe, a better approach might be to do a basic amount of planning so that folks know what’s coming up in terms of work. This ought to be followed by teams planning for only about, say, 70% of their total capacity. The remaining 30% can be used for one of two things a) satisfying dependencies that other teams discover, and b) extra work if the former doesn’t take up all remaining time. This way, teams can be more agile, and actually complete work as they delve into it and discover issues. It also lessens the need for deep and detailed analysis, especially around integration nodes – which (again) is inventory with a short half-life.

One other benefit of going this route is that it makes explicit (and OK!) the phenomenon of discovering dependencies as teams work on their stuff, and the idea of fulfilling orders (functionality requests from dependent teams) in a just-in-time manner with analysis as fresh as it possibly can be.

What do you think?

Posted in agile, lean software, process, project management | 3 Comments »

Story Points vs. “Real” Hours – The Advantages

Posted by Amit Rathore on February 15, 2007

This from another recent lunch conversation -

1. Story points are a pure measure of size and complexity>
2. Story points are relative (say, with respect to the simplest story) and so have a much longer shelf-life
3. Story points are usually independent of who gives the estimate (as in, an experienced developer and an apprentice can usually agree on something like complexity fairly quickly)
4. Story points avoid the need for discussions like “what are *ideal* hours, really?” or “My ideal hours are different from your ideal hours, stupid.” These add no value.
5. Story points don’t influence behavior (e.g. Parkinson’s Law)
6. Story points are easier to work with – especially when product owners start to wonder why “3 ideal days take a week…”
7. Story points are more fun – especially when they’re in units like gummy-bears, polar bears, or other endangered species.

On a slightly different note –

When you use a geometric series for your story-point scale (say 10, 20, 40, 80, 160) as opposed to, say the fibonacci sequence (1, 2, 3, 5, 8, 13, or multiples thereof), it is a lot easier for your scale to satisfy the closure properties over addition and subtraction. In other words, with a geometric scale, a product owner can say “Hmm… I think this 40 point story is not ready to be played yet”, and you can respond with “How about we swap it with these two 20 pointers?” This could be a bit less intuitive when dealing with the fibonacci scale. All IMHO.

Posted in agile, estimation, process, project management, story points | 1 Comment »

Advice to new project managers

Posted by Amit Rathore on February 13, 2007

I was having lunch with my scrum-master colleagues today, and one them – Eric Plue – asked, “If you had to list four of the top things that you’d advise a new PM to do, what would they be”. It was a lively sort of discussion, and here are mine -

1. Risk management
2. Manage expectations
3. Apply lean thinking
4. Inspect and Adapt

What are yours? Remember, no thinking about it for hours, just the top four on your mind!

Posted in project management | 5 Comments »

Multiple stake-holders and Agile

Posted by Amit Rathore on February 11, 2007

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.

Posted in agile, organizational, process, project management | Leave a Comment »

Why work at ThoughtWorks?

Posted by Amit Rathore on February 1, 2007

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.

Posted in agile, organizational, process, ThoughtWorks | 26 Comments »

 
Follow

Get every new post delivered to your Inbox.