I have a long-running debate with a friend of mine about the state of software development.
I argue that by applying agile best practice the majority of software projects can be successful. My friend counters this argument by saying the trouble is that nobody ever applies agile best practice, so software projects continue to fail.
In many ways my friend is right, in the real world agile is often badly applied. The reason why this is has puzzled me for many years.
Too many developers hated planning because the plan had never been of any personal benefit to them. Instead, plans were often used as weapons used against the developers
- Succeeding with Agile, Mike Cohn
Even if I don't know how to implement something I can almost always write a test for it and If I can't figure out how to write a test for it I have no business programming it in the first place. - Kent Beck
Many processes in agile are mutually supporting. A good example of this is testing and its relationship to the development iteration.
I'm a great believer in getting quality in as early as possible in the development cycle. Checks that run automatically in an IDE are best (for example the Checkstyle/PMD plug-ins in Eclipse).
But these have one drawback: they are not enforced.
Nothing kills the productivity of a development team more than working on and supporting poor quality legacy code.
You start work in a new team, full of grand ideas and determined to do things the right way. Then you discover the morass of existing software that is sitting at the heart of the system. This code has been around for years. Nobody likes it, everyone wants to get rid of it. But that would mean spending lots of time and resource and producing little, if any, business value.
The Daily Scrum is one of the Scrum ceremonies. It is also often called the daily stand-up or just the stand-up.
The idea in holding a daily stand-up is to get the Scrum Team members talking to each other. The stand-up is there to coordinate dependencies, to identify issues and to fascilitate team members helping each other out.
In my career I have seen the transition in popularity from FORTRAN to Pascal, from Pascal to C, from C to C++ and from C++ to Java. That is not to mention the introduction of Hibernate, Spring and numerous other technologies.
Why would you want to spend time and effort to adopt agile?
That's a good question and one that should be asked and answered by your organisation before you attempt an agile transformation. First you need to define what you want to gain (or recognise a problem that you want to overcome). Then you need to agree how you will measure progress to ensure you are actually achieving what you set out to do.
What is agile? A simple question with a complicated answer.
A good point of reference for agile is the agile manifesto. This consists of four basic premises and twelve more detailed principles.
Agile is an approach to software development that is aimed at minimising the cost of making changes. Think of agility as the capability to make rapid changes of direction, to be flexible and to adapt.
