Plone Conference 2008
As Plone Conference 2008 continues today, we bring you more live blogging coverage. In the spotlight now is Mike Robinson. He talked about challenges faced by software development teams and how to solve them.

Problems Facing Software Development Team

From the point of view of a customer of a development team: Software is too expensive, and it's pricey to run it. It's not what they wanted or expected. It's unpredictable and unreliable. It wasn't delivered on time, or when they wanted, etc. From the development team's point of view: Software development is really hard, and we don't get a lot of credit for doing it. They don't feel like they're valued or respected. Long hours, hard work, inconsistent business units don't tell you enough or they overspecify things. Both make implementation very hard.

How to Solve This Problem?

Process

RUP or waterfall can often be an overkill. It's a bit too much control. The solution is technology. Having the right tools also helps a ton. In reality, process, tools and technology in the right combination will help ensure your project is successful. But, ultimately, it's people who makes things happen. You can use a ton of different methods. There are a lot out there. The method won't make or break your project. If you get the principles right, things will fall into place. A lot of these methods all have the same basic principles. Process -- so how do you pick one? Pay attention to what your values are and pick out a set of metrics on how you can then measure things. Pick the simplest method possible that meets your values, needs, and metrics. What controls do you need to put in place to help get things done? Review and adapt your process. Make sure it works; evaluate it constantly -- so that it works for you.

Change

Things change during a project -- especially, during a technology project. Yes, scope creep can be bad. But if you work in a way where you can easily adapt to change, you'll be better off. Minimize the impact the change has on you. And then handle it responsibly.

Simplicity

People want more for less money. What's the minimum amount you can do to get the most business value? Use the simplest process to get the job done.

Quality

You need to build quality into the system. If you don't test it, you need to start doing it right away. Do your testing earlier in the process -- test early, test often, test well.

Commitment

Everyone on your team has to be committed. It gives them a sense of responsibility and enjoyment of their work. Your team will feel a lot better about their work and work harder for you.

Visibility

Don't hide things! Give accurate information from the start. Be sure you can accurately measure the work that you're doing, so you can give accurate updates.

Collaboration

Face-to-face communication is the best way to exchange ideas. Get together when you can and work together.

Focus on Value

You're all part of a team. Understand why what you're doing what you're doing and be able to see how it adds value. If it doesn't add value back to the business, then what's the point in doing it?

Final Thoughts

Mike views Agile as a set of value and principles which you can adapt to your needs. The method doesn't matter. Get your core principles right, and the method will fall in line. Mike suggests the minimum thing they can do that allows them to manage their projects. His team prefers a scrum-based method. Mike also suggests a shift in thinking. The project manager works for the development team, not the other way around. Very often, people operate with the exact opposite thinking. Mike summarizes with: “No one method fits all projects all of time, start with people, get your principles right and the process will sort itself, selecting the right method is as much an art as a science. Review, adapt and evolve.” One of the all-time best project management sessions I've attended anywhere. I agree with Mike 100%. These ideas just make sense. So much emphasis is often put on the right method, but it's really more about the right people and having a functioning team. I wish more companies would use this kind of thinking. Maybe it's too radical, but what's scary about a project team that actually gets things done?