More People != More Progress

on March 25, 2008 @ 03:38 AM

There is a common misconception that the best way to add capacity to a project and reduce its completion date is simple—just throw more people at it. Although there is some truth in this, it is usually applied at the wrong times and it ends up having a very negative impact on the project.

This mindset that project development is a series of tasks and that somehow you can just throw people at them and everything will work out is foreign to me, because it won’t work out—at least not when it’s applied in haste.

Adding value to a project is more than completing tasks. Tasks are not isolated during project development. They are features which build on top of one another. Making good responsible decisions and understanding the code base both technically and conceptually goes a long way to help exploit easier and better ways of implementing features. This also helps keep the code base well factored, which in turn helps teams progress consistently and avoid creating a giant roadblock of technical debt which may have lurked just ahead.

Planning In Software Development

on June 13, 2007 @ 03:51 AM

I was just reading the post Quit Planning over at Daniel Morrison’s blog

His comments seem to be down so I felt the need to post my thoughts here. In response to Daniel’s article I think he has it mostly right on the money. Although I would like to change the term “planning” in his article to “upfront planning”.

Dwight D. Eisenhower may have said it best:

Plans are useless, but planning is indispensable.

Unfortunately most definitions of planning involve the upfront and systematic approach rather then focusing on the continuous process which develops daily.

Developing in short iterations allows for short bursts of incremental progress which when used in combination with a quick feedback loop between the developer and the customer gives the customer an upper hand in defining and planning the needs of his software to meet the needs of his business.

It works because the process of planning is continuous and incorporates change, while upfront planning to produce a plan ignores that change will occur, which as Daniel points out, will occur.

If you remove the process of planning (which I don’t think Daniel is suggesting) then you remove a key component to any software endeavor, agile or not. Agile strives to reduce and minimize the concept of upfront planning in favor of iterative planning.

As pointed out on the Agile Journal in a post

Planning isn’t bad

What I believe Daniel is focusing on in his post is that:

... the details [should] emerge throughout implementation.