Agile web Development, the challenges of small projects.

It is often talked about but I have never seen it truly implemented in small scale media bureaus. "Agile Web Development": How can you truly implement and benefit from the tools that are clearly intended to improve quality and ROI in the Internet world for small projects? I am talking about projects that may have a lifetime of 2 weeks, a long project in this world is 6 months. If it is longer the 6 months you are probably doing something wrong. I believe we are running at less then 40% of capable productivity in this world (probably even less than 20%), currently I am trying to collect data to prove this, though most of these companies don't have any reliable data. I am not sure if any one of the many types of Agile development practices are currently suited for this situation, and that is when I had my eureka moment. The reality of complex processes is that there is no perfect answer only best practices.

The basics of Agile anything is simply team work and communication. It is something so basic that we forget about it. How do you create a team? Coaches get paid tons of money to create good teams that win, and if they don't create a good team they get fired. Most project leaders today don't create teams, they create task lists. Often they don't even create task lists, they have a functional designer do that and they assign the task. The only thing that could help to make their life better they destroy. The worst part is that most project leaders do not even know they are doing this. They seem to have this idea that a person is a role and a task fits a role. But we need to see a role as an expertise and not a limit. The project leader must realize he is not a manager, and if he is assigning tasks he will eventually become a beggar or a tyrant (depending on his personality).

Well I am currently not going answer any questions here as I am now still asking questions. I think I have come up with a solution to many of the problems and hope to get the chance to implement this solution in the near future. Some of these problems are specific to the "Internet world of small projects" and the other are simple the difficulties of implement agile development when the Product Owner is constantly changing. Of course the answers are documented in the many books on agile development but the implementation will always have a unique quality depending on the situation and the company. Further more it will always be changing just like technology.

Here are some problems that come to the top of my head now:

1. The projects are often so small that coming into "hyper productivity" by using iteration is not really possible you need be hyper productivity straight off the line.
2. Sometimes waterfall actually works!!!, this is scary but i have seen waterfall work, because when something is so small it can actually get planned somewhat, when the technique is known. Example: I once made a website for a music for Warner Benelux, they wanted another website for another music group that was almost exactly the same with a few modifications, it was completely executed with waterfall and worked! (this is a problem when you try to convince a company to implemented agile development), but of course this is more like a feature then something new, but still it was waterfall, first discussion, then functional design, then graphical design, then building. It works when you have build enough similar things and the client has seen what it is getting actually before hand.
3. Preproject planning, the amount of preproject planning is difficult and can actually take equally long as the development in this world. Getting clients to commit to a basic ideas and design can be difficult. Commitment to design changes is as well complicated. This will often set a team still if they are only working on one project.
4. The chaos of many projects. This is an extreme challenge, prioritizing and maintaining focus is a huge problem here. Can you reach hyper productivity when you are changing from project to project every 3 days? What is the minimal time of focus on something, is it a week? why even differentiate between projects, if you have a clear goal does it matter which project it belongs to?

These are just a few questions, there are still many more to be asked. Once I implement a potential solution the metrics to measure it become complicated. If I am using complexity points or other relative methods of estimated difficulty of implementation, how does that scale across many projects. Can you really estimate a true velocity then?

I hope to get the opportunity to answers these questions in the coming months. As well I plan to really look into some PHP frameworks to see how the rivals of Ruby are doing. Of course I am always looking for tools to improve my rapid development. Maybe I will give Scala a try as well.

This concludes my first "quick blog" and we will see all to soon if i am able to keep this up with all the other tasks those project leaders keep giving me ;)