How to make Scrum work for a team with defined roles?

Question

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:

1. "Client" gives us a set of initial requirements
2. We develop the system to said specification
3. Present said system to "client"
4. "Client" gives us additional requirements based on said presentation
5. Repeat 2-4 until "client" has run out of new requirements or deployment target date is close
6. 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?

Answer 1

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.

Answer 2

You ask for alternatives so I'm going to say eXtreme Programming (XP). Specifically I think that pair programming might help you here.

By pairing people with different skills together, it doesn't matter on what skill: making coffee, testing, training etc. you can spread the skills around the team.

But to be honest it doesn't sound like SCRUM is that far off for you. Part of SCRUM is being flexible and finding what is best for your team. Part of XP is respecting your team and adapting. Maybe in a 100 years time we might have a more fully developed profession with hard and fast rules (although I doubt it) but for now, doing what works for you is all we have. The important thing is to have feedback loops. If something isn't working, then the team needs to discuss that and try new things until they find something that works.

Answer 3

How to make Scrum work for a team with defined roles?

Just do it. According to the scrum guide everyone is a developer but back here on planet earth, different people will bring different things to the table. I nearly got lynched when I suggested that some people are really testers while others write the software.

Some things you might want to address:

Sprints

It sounds like you have an initial development phase followed by a series of what are ostensibly sprints. Consider breaking this up. Not only will the client see something early, you'll get a better feel for development milestones as they occur.

Fixed deadlines

This crops up time and time again and indeed is a persistent thorn in the side of devs where I currently work. Scrum sets estimates for the sprint - nothing more. Yes, you might hit target after a series of sprints but once the client has eyes on early versions the scope is likely to creep significantly. This isn't a problem in itself, but the client should be made aware that further work will take place in later sprints and are over and above the known requirements.

Answer 4

Your situation might be a better match for Kanban, since you can start with you have and iterate from there. This means you wouldn't have a big bang introduction which is disruptive to your current projects - just start by visualizing tasks on a board and adopting some of the practices such as retrospectives and daily meetings.

You have to be a bit more careful than with Scrum because it isn't so prescriptive: so it has a tendency to drift back to whatever went before instead of inculcating a proper agile mindset.

Answer 5

Scrum does not work well with separate projects that overlap, as you don't have a stable set of people working on a project for the complete sprint. Hence concepts like verbosity etc are likely just to depress you.

But first taking the story that give the best cost/benefit to the client, and implementing it including full automated testing, to a quality that is good enough to be deployed, before working on the next story is a useful concept. Likewise require all the code written for a story to be reviewed by another developer before the story is considered “done”.

I assume your implementation staff have to write training and reference documents, they can be written (first draft) for each story before the code is written, hence becoming the acceptance tests.

I expect you will find that at the start of each project where the input of the implementation staff would be of most help to the developers they are 100% committed to the deployment of the preceding project. Therefore consider if the implementation staff can be working on writing the stories and user documentation for the next project, while the developers are writing the code for the current project.

“behavior driven development” with the implementation staff writing the example that are used in the tests may work.

So there are bit of Scrum that will help you, but try to lean from Scrum instead of using Scrum.