Agile recipe

One of the most interesting things of Agile is that it means so many different things to so many people. The first thing I would have to say is that it is just like waterfall or rigorous software methodology (RSMs) projects. Yes you heard me right; there is no difference between Agile and Waterfall.

The fundamentals of software development remain the same regardless of the process, and I tire of the Luddites who espouse the virtues of Waterfall or the evangelists who reckon there is no way other than the Agile way.

What is software development?

1. A Customer requests a product.
2. A Developer creates a product.
3. A Tester verifies and validates that the product has integrity and is suitable to be presented back to the customer.

I've obviously simplified these roles, so the same person may wear the hat of customer and tester, plus each role might be decomposed further, but isn't the above the essence of software development?

Let's take one part of the process. What is the underlying process for a customer requesting a product?

1. The customer speaks to the developer and asks for a product.
2. The developer says whether or not it can be done and agrees, providing a time for expected delivery.

Lets look at the two approaches in ideal implementations.

In Waterfall, or more accurately a RSM, requirements are captured, documented in a clear and unambiguous fashion, with extensive formal reviews to ensure quality prior to agreement with all parties.

In Agile, the requirements are captured individually on cards and verbally agreed between the customer and developer. Confirmatory questions and regular feedback ensure mutual understanding.

Now looking at them realistically:

In Waterfall, or more accurately a RSM, requirements are partly captured, poorly documented by those who have little understanding of how to capture true business requirements or communicate the value of each feature requested, followed by a cast of thousands demanding sign-off, followed by endless changes, updates and political positioning around getting what some departments want out of the budget.

In Agile, the requirements are captured individually on cards and verbally agreed between the customer and developer. Confirmatory questions and regular feedback ensure mutual understanding.

So there we have it. I've been fortunate enough to work on RSM implemented projects and where the domain is well known and stable, say a telecommunications protocol (Q.931 for example), it has been really clear what the requirements are, and hence was easy to implement and test. However, it seems the majority of IT systems involve a customer who isn't sure, a developer who doesn't always understand the domain, and a tester who is dropped in the deep end and is primarily an end user.

What Agile does is give immature IT shops, or fast-moving industries where time to delivery is key, an approach to allow the customer constant feedback to ensure the project stays on track.

What Agile does is address the inadequate implementations of RSMs employed by software firms, by ensuring communication, courage, and response to change operates more effectively. The thing is, if people followed the process correctly, then they wouldn't need to try out Agile.

My biggest concern for companies moving to Agile is not what it gives them but what it doesn't. If you don't have the staff that are capable of following a detailed rigorous process with documentation that ensures communication is maintained, what makes you think they can deliver in an Agile world?

I see a lot of organisations struggle with Agile, and in most cases it is because the calibre of the people involved is not high enough to deliver in a courageous and fast moving environment. There are some amazing individuals in organisations; I met some testers yesterday working their way to making testing integrated into the hybrid Scrum teams, but you can tell there are some people they are dealing with that are better suited to having a strict process regime.

My point is Agile is not lacking in rigour, only the rigour has to be applied by the individual rather than the process. It is just as 'expensive' (this issue of cost comparison between Agile and RSM is something else that bugs me), just as hard work, but the onus is on skilled and motivated individuals, rather than average SW engineers and end user testers.

I'm now faced that my wrap up will sound more like a rant, but I suppose it surmises or at least demonstrates the strengths of the many different approaches to SW development.

Firstly, I do not think nor believe anyone else stands by there being only one way to develop software. There are many Agile and many RSM processes, and like a persons sexuality, there are many positions and processes along the scale. Terrible analogy I know but it makes sense. Actually that doesn't work, because people can't change their sexuality. I believe the process should adapt to the conditions of the project and the needs of the application. As a result, we have as many different processes as we do have religions (that's better, sex and religion and software development processes in the same paragraph).

I feel an epiphany coming on.

What are the conditions for a project moving to Agile?

• Do you have highly skilled motivated staff. (be honest now; are they really that motivated? Does drinking 6 Ouzo and cokes at lunch really count as a skill?)
• Is the domain ABSOLUTELY clear (does the customer really know what they want?)
• Is there a formal process in place that already works? (if it is working for you, why change it?)
• Do you have the skills and infrastructure to support highly automated testing? (you ARE going to automate aren't you?)
• Do you have the support of management to move away from heavyweight documentation? (are you really going to get your BAs, developers and testers to develop 148 page word documents like test summary reports, negating any benefit achieved by using story cards).
• Do you have an engaged customer? (without that you are just doing Waterfall without requirements? You're on your own now.)
• Are the developers doing unit testing? (If they aren't doing unit testing, why do you employ them?)

Now lets get back to my original point. How many issues above can affect both Agile and Heavyweight processes alike? I think the issues that affect success are more down to the rigour of implementation of approach rather than the approach itself.