Agile development methodology

Technically, we are using a Rational Unified Process, with several aspects of Scrum thrown in for good times? So I think that Agile Unified Process is possibly the most similar to what we do.

Martin Woodward illustrates how all projects can integrate Agile methodologies…

The problems inherent in software estimation also help me to understand why Agile software development methodologies work.

You are forced to break problems down into small bits that can be managed, tracked and measured.

Small iterations means that you can only get so far behind.

You re-estimate and re-prioritise work at each iteration when a hard estimate on that task is possible (and therefore your estimates are more likely to succeed)

You frequently listen to the person who will be using the software

You can load your iterations so that there is always work to do of the correct priority to the customer when you have finished a task early and things of the appropriate priority that you can drop off the list when something takes longer

There are also many other techniques that people can adopt from Agile methodologies or just from common sense to reduce the amount of time taken when a task is taking longer than expected, such as

Limit distractions. You need time to concentrate on a single problem otherwise you will never finish it.

Pair programming. Identify when a second pair of eyes is needed and quickly as for help in your team (can be hard when your team are distributed across multiple time-zones)

Daily progress meetings. The guy that has been stuck for 24 hours on what he thinks is a firewall issue is quickly identified)

Lack of ego. I’m the “Windows guy” in our company, if I say something is a firewall issue with Windows Vista SP1 x64 and a probably collision with the new Eclipse 3.4 launcher executable - then the new intern who only knows about the Mac he used at college should feel like he can ask a “dumb” question and say “Have you checked your proxy settings after that bug you were fixing yesterday”.

I think most of us can see benefits in these approaches. But my team is only implementing a few of these strategies:

Problems are being reduced, mainly through defects and change requests. New work is currently on the back burner.
We have regular builds; nightly builds, with a test release every week. Managed UAT/Production releases.
Daily meetings and we freely discuss issues, continuously.

But I see a few issues in what we are doing and not doing:

There is no nightly automated testing on the build.
A build goes into the test environment (almost) weekly, so we are often firefighting issues instead of working on improved functionality and stability.
Our daily meetings are not focused on work and issues, effectively paying lip service to the Scrum methodology. Really we should be covering off the work done and upcoming in smaller focus teams… that actually understand what we are talking about. Instead we include the entire team, management, analysts, testers, developers…
Pair programming and QA is not done.
There isn’t much interaction between clients and developers… though there is at other levels, if there is useful information being discussed it isn’t being shared.
The test environment and other issues are creating many distractions!

I think some of the issues are more serious than others.

We could do with an automated test system, but it wasn’t really done up front and it would cost to implement it after the fact (though if we did a little analysis and design, I’m sure we could get something together that we could slowly add to as we fixed up functional areas).

A big drain on application development is our proximity to the testers. It is amazing how quickly your productivity drops when you are communicating about issues whenever they arise. I think part of the problem is a lack of unit test software in the application, but I also doubt a week is long enough to consider a build stable enough to bother testing… even small teams can have productive weeks and do some solid damage to the products stability. Perhaps if testers didn’t interact with developers directly? And developers had solid individual environments to work on?

Perhaps there should simply be a development gatekeeper that monitors test defects and checks them out before delegating them to the team… the only problem is that this would be a full time job and isn’t a job for a management type, it is a development role to have deep knowledge of the system and the developers that work in it. All defects and software changes should go through this person. This currently happens for most defects at work, but the gatekeeper doesn’t have much system knowledge at the required level. So system and user interface issues are assigned correctly, but functional areas are often split. Leading to multiple developers doing work in the same piece of code at the same time!

There was more, but where is the time?

Last 5 posts by James Little