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.
Why 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.
The question
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?
Best Answer
Actually, your current way of working isn't that far removed from Scrum as you might think.
In Scrum, you also get an initial set of requirements, implement those and demonstrate the result, and based on the demonstration, new requirements can be given to you or the stakeholders can decide that the product is good enough that no further development is needed.
In your situation, the "client" that you talked about could be given the role of Product Owner in Scrum (they already seem to fill that role by setting the priorities within a project and deciding when it is ready to be rolled out).
One big change could be the length of an iteration. In Scrum, an iteration should last somewhere between 1 and 4 weeks.
As for the team composition and jack-of-all-trades fallacy: Scrum does not require everyone to be a jack-of-all-trades. Scrum just requires that the team as a whole has all the required competences to get the product from a list of requirements to something that has been/can be deployed.
In your situation, I could easily see a team per project consisting of one or more developers (doing mostly the implementation and testing work) and a member of the "implementation staff" who focuses mostly on creating the manuals and training material for the features that the developers are now implementing.
After the client/Product Owner has given the green light for deployment, the work for the scrum team will be mostly done, so the developers can go to another project (and be available only on demand for fixing after-deployment problems) and the implementation staff can switch to performing the training and supporting the roll-out.
The fact that there are deadline is not a real problem, as long as there is enough flexibility in what functionality needs to be in that release.