Some background information
I'm part of an in-house software dev team. It consists of
- 5 developers (with experiences ranging from 2 to 5 years, I'm one of them)
- 3 implementation staff (they do the software deployment and training)
- and 1 project manager.
We develop plenty of small to medium-sized projects, and their timelines usually overlap. Development goes like this:
- "Client" gives us a set of initial requirements
- We develop the system to said specification
- Present said system to "client"
- "Client" gives us additional requirements based on said presentation
- Repeat 2-4 until "client" has run out of new requirements or deployment target date is close
- Set up and deploy the system
This, together with the fact that it's the "client" that handles the deadlines most of the time (which is a red flag, from what I see here in Programmers and PM.SE) and we don't follow a definite development methodology leads to cowboy coding, nigh-unmaintainable code, and bugs that get through production, among other things. That's why we opted to adopt an Agile-based methodology like Scrum.
It was our manager's initiative, and everyone seems to agree upon it, given our current situation.
The problem with Scrum
Some of the elements of Scrum have conflicts with our current setup that we cannot easily address, particularly the "jack-of-all-trades" nature of Agile developers. The deployment team doesn't know how to program, and the developers have below-average communication and training skills. And this lineup won't really change any time soon.
Would it affect the effectivity of Scrum as a methodology? Would other changes need to be made to compensate? Or would it be better to abandon the thought altogether and think about a different methodology?