Thinking big – as in big projects

We talk so much about agile processes, which are clearly well-suited to small and mid-sized projects. But what about scaling agile for big projects? This is a topic that’s often debated, but in my opinion at least, hasn’t been completely settled.

By big projects, I don’t mean the workload of the deployed application (i.e., lots of transactions per second), or even of the importance of the deployed application (i.e., a business-critical application). I mean the size and complexity of the application.

Think about a software development project that has, oh, 10 million source lines of C#, C++ or Java code, or maybe more than 300,000 function points. Or maybe 5x or 10x that size.

We’re talking about large software teams, complex requirements and a significant cost. It’s not a happy little Web application that’s being thrown together with a couple of dozen people and rolling out next month – it’s going to take a while, and it’s going to be expensive.

Many large projects use a heavyweight process like the Rational Unified Process. But can they be agile too? Can you successfully combine the flexibility of Extreme Programming with a requirements-first RUP project? RUP already specifies iterative development, but how much of Scrum can scale up large? Is the answer to use Kanban? Or to say bye-bye, agile?

When discussing this question with SD Times columnists Andrew Binstock and Larry O’Brien, Larry said that, when it comes to the problem of scaling agility for large projects, “it’s not the methodology, but the management. An aligned, self-correcting team is far more likely in a smaller business where there’s an investment and personal relationship from the low to the high. Is a scrum standup going to be successful for a team assigned to execute a doubtful policy about which they can give no meaningful criticism?”

Now, consider how agile plays out when launching a large project. As Andrew Binstock suggested, some questions are:

• How do you decompose large projects into agile-size subprojects?

• How do you balance the inevitable need for requirements with agility’s commitment to changeability?

• How do you do frequent releases that a user can give you useful feedback on?

Larry gently pointed out, though, that my premise might be flawed – or rather, somewhat out of date. Hey, what do you expect from a mainframe guy? He said, “With service-oriented architectures and the ease with which frameworks and libraries are pulled in, fewer companies think of themselves as dealing with very large codebases. The reality is that the enterprise ecosystem is still very large, but subsystems seem to be more loosely coupled than in the past. The result is that most teams perceive themselves as working with only a few tens of thousands of lines of code, for which agile techniques are fine.”