Agile development processes are practiced either at grassroots where all people in the organization or sub-group play an active part in improving, following practices, and contributing to the processes. The alternative is to do what everyone else is doing (Drone-driven-development), or resisting change and sticking with age old practices, tools, and thus development speed, and user feedback and cycles.

Using job aggregation websites and forums, I analysed the quality of jobs, and requirements in UK, UAE, India – primarily because I know people working in these countries and the time spent to research each country is large. If anyone want to help me in refining the criteria and and expand the list of countries, I’m more than happy to work together.

UK is in an ideal position to focus on true innovation and development and lead the way for others to follow. Not being platform specific they can exploit newer innovations rather than rely on vendor to supply approve supported modules and changes.

UAE is a SAP based economy. With C#/Java holding a very small proportion of the economy compared with SAP, and of the C#/Java jobs, a miniscule have agile listed as their requirements. UAE is likely to rely entirely on vendor products and development abroad rather than innovate and develop locally. This is likely to be the more expensive way in the long run, but the premium is noticeable.

India, like UK has a high number of C#/Java jobs as compared to SAP. However, Java holds a significant market share.

My thoughts:

I’ve generally seen companies eventually isolate and remove SAP, and other large systems as it’s expensive and fewer developers are are available, and consultants are required to maintain them which become more expensive as the technology gets out of date. There has been some effort to enhance SAP, however, it is a follower rather than a leader when it comes to innovation.

Joel did some excellent work in helping evaluate if we’re quiet there yet or not in terms of the inefficiencies we face during development and how much hair pulling needs to be done to just write code. Twelve years on with “Agile” being attempted it’s worth a review.

Working as a consultant, and talking with other developers,the attitude to development is “You can’t make an Omelette without killing a few people”, so the general approach many developers follow is just follow the process and get on with it. But it’s worth checking where you stand. It’s definitely more concrete than the Drake Equation.

Kashans Test

1. Source Control (+1 if you have one, -1 if you zip and merge, or use excel to track changes, 0 otherwise).

2. How long do stand-ups take (+1 if 1 min/person, 0 if more, -1 for what standup?)

3. Are there automated UI tests (+1 for yes or if not needed, -1 for none).

4. How long does the build take (+1 for <15 mins, -1 for more).

5. Do you get the “talk” if you break the build (-1 if you do, +1 if you don’t) – team spirit is important, but the underlying cause needs to be checked if it breaks a lot.

6. Do you have requirements to work against (-2 if you don’t, -1 if you have access to people that do, 0 for some document, +1 if there are stories).

7. As a developer are you required to be “well rounded” in large projects – i.e. is the project missing a PM, BA, QA, User (-2 if missing some, -1 if missing one, +2 if all are available).

8. When developing do you get OutOfMemoryExceptions, dribble your fingers on the table for build to happens, tests to run, etc… (-1 if you do, +1 otherwise).

9. Do you have 55 hours weeks outside release cycles (-1 if you do, +1 otherwise).

10. Does your company host developer social events? (-1 for no, +1 for yes).

11. Do all Devs have local test databases and are able to check in database changes using delta scripts? (-1 for no, +1 for yes).

I wouldn’t be surprised if this needs review in a few years with practices being adopted and standardized depending on the size of the company and the developer community in that area.

Data is a vital aspect of testing that we do, be it functional tests or unit tests. However, a lot of times in software development the data is “estimated” and not necessarily well defined. Eventually when going to deployment and the existing data which needs to be migrated is about to be transferred, the team discovered to the horror that the data is slightly different – this could range from missing data to repeating of key columns. As a result last minute modifications are made and minimally tested before being deployed and hoping for the best.

So if it works, that’s great! But an earlier test deployment generally helps avoid this risk, or delaying the release until the data is ready (the system can’t be used if there is no data after all).