This is the fourth in the series of deeper-dive articles that are part of Agile Organization Incorporating Various Disciplines.
The Project Based Organization Model
You all know this one. You pick all the resources needed to accomplish a project (phase of development on a product), have them do it, then reassign them!
Benefits Of The Project Based Model
- The beancounters love it. You are assigning the minimum needed resource to something “only as long as it’s needed.”
Drawbacks Of The Project Based Model
Where to even begin?
- First of all, teams don’t do well if not allowed to go through the Tuckman’s stages of development (forming/storming/norming/performing); engineer satisfaction plummets.
- Long term ownership isn’t the team’s responsibility so there is a tendency to make decisions that have long term consequences – especially bearing on stability, performance, scalability – because it’s clear that will be someone else’s problem. Even when there is a “handoff” planned, it’s usually rushed as the project team tries to ‘get out of there’ from due date or expenditure pressures. More often there is a massive generation of “orphans” – services no one owns. This is immensely toxic – it’s a problem with shipping software, but with a live service it’s awful, as even if there’s some “NOC” type ops org somewhere that can get it running again if there’s an issue, chronic issues can’t be fixed and problems cause more and more load on service consumers, support, and NOC staff.
- Mentoring, personnel development, etc. are hard and tend to just be informal (e.g. “take more classes from our LMS”).
Experience With The Project Based Model
At Bazaarvoice, we got to where we were getting close to doing this with continued reorganization to gerrymander just the right number of people onto the projects with need every month. Engineer satisfaction tanked to the degree that it became an internal management crisis we had to do all kinds of stuff to dig ourselves back out of.
Of course, many consulting relationships work this way. It’s the core behind many of the issues people have with outsourced development. There are a lot of mitigations for this, most of which are “try not to do it” – like I’ve worked with outsourcers trying to ensure lower churn on outsource teams, try to keep teams stable and working on the same thing longer.
It does have the merit of working if you just don’t care about long term viability. Developing free giveaway tools, for example – as long as they’re not so bad they reflect poorly on your company, they can be problematic and unowned in the long term.
Otherwise, this model is pretty terrible from a quality results perspective and it’s really only useful when there’s hard financial limitations in place and not a strong culture of responsibility otherwise. It’s not very friendly to agile concepts or devops, but I am including it here because it’s a prevalent model.
the agile admin 
I’m never sure myself about these project-based organizations. It seems to make logical sense, but as soon as a project ends, the project team seems left in vacuum, whereas if organizations base their model on tasks (which are parts of projects) – an individual’s ability to streamline their performance gets a lot greater. Looks to me as though not too many managers take this into account.
It’s jut like this post I recently read: http://kanbantool.com/blog/can-agile-projects-turn-into-agile-companies – it suggests that the behaviour people develop and exhibit while working a project can be translated to the organization, which may or may not be true.
What about making an individual Agile and then hope that their newly adapted behaviour is reflected in the organization’s patterns? I think this is what the other article suggest: start with people, then think of projects, then see the impact on companies.
What I’m aiming at is: how about not driving by project but driving by empoyee?
Crazy or potentially good?