
In three earlier blog posts I talked about multi-functional teams, matrix management and maintenance. In my maintenance article I argued that maintenance work on an application should done by the developers who were responsible for building it. However, I also pointed out that this introduces some additional resource planning problems...
When software developers are responsible for multiple projects, you always end up with complications in resource planning. This is not just the case when you let developers perform maintenance on previous projects. Similar problems arise when they are required to do some other activities, like spending time on consultancy or estimations for projects that haven't yet been signed into contracts. Likewise, many developers need regular training, or they like to do some quality/infrastructure stuff for the organisation itself. Therefore, maintenance work on old projects is a challenge, but it's just one of many types of work that can take people's attention away from their current projects. This requires a professional approach to resource planning...
Bookmark/Search this post with:

Agile software development methods tell you how to run your projects. But they all do that from a single-project perspective. What if your organization runs multiple projects at the same time? Do the agile practices still hold in such a case?
Our organization consists of 220 people, spread over two locations. We specialize in doing small fixed-price projects, most of them web-based. At any time we have at least fifty different projects running simultaneously, with lots of other projects in "sleep-mode" (either waiting for resources, or waiting for customer input). Handling fifty different projects creates a lot of noise. There are always conflicting resources, conflicting constraints, and conflicting planning requirements.
So, the question is: What do Scrum and Lean say about such a multi-project situation?
Well, the answer is: Nothing! (But maybe they don't need to...)
Let's see... Our people are working on fifty different projects. But is that so much different from other organizations where they have 220 people working on just one big project?
Bookmark/Search this post with: