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?

  • 17
    Your "Why Scrum?" paragraph is quite important, and it's essentially empty right now. It seems your manager doesn't like what you're currently doing, and therefore randomly decided Scrum because Scrum. Apr 25, 2016 at 8:44
  • 4
    there's a definite role/place for specialists in an agile (scrum or otherwise) environment. Don't mistake the fact that people are expected to jump in on things that aren't their speciality for a "ban" on specialists. Besides that, could you elaborate on why you chose scrum and not kanban? it shounds to me like, given the constant reiteration of requirements, a better fit than one with pre-defined sprints that work best with fixed requirements... Apr 25, 2016 at 10:20
  • 12
    5 developers but not a single tester?
    – Apfelsaft
    Apr 25, 2016 at 12:15
  • 8
    @Revenant you're confusing jack of all trades (individual) with cross-functional (team). Apr 25, 2016 at 12:45
  • 6
    Popularity. Always the best way to choose anything. Apr 25, 2016 at 14:18

5 Answers 5


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.

  • 2
    One change that Scrum and other Agile methodologies would introduce is that the product / all of the features must be "done" - in a shippable state - at the end of every iteration.
    – stannius
    Apr 25, 2016 at 15:33

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.

  • 3
    +1 for XP. Question states that the main reason for adopting Scrum is that "we don't follow a definite development methodology leads to cowboy coding, nigh-unmaintainable code, and bugs that get through production" -- Scrum will do little or nothing for this, as it does not prescribe any technical practices, and only technical practices are going to fix those problems. There are plenty of other agile frameworks that do, with XP being the likely best candidate as it's the closest of the well-known ones to Scrum in structure.
    – Jules
    Apr 25, 2016 at 13:29

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:


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.

  • Just to point out what seems like a horrible mischaracterzation of Scrum: not everyone is a developer - you can and will have specialized members, but they are part of the development TEAM and responsible for the output of that team's sprints. In our Scrum setup the testers are usually behind a few sprints in terms of what they are working on versus devs as they can't test what's not done, but they are creating the test plans and possible test data they'll need. While they deal with the main features we get into older bug fixing mode and prep the patch as they catch up to the release cutoff.
    – Duffy
    Apr 25, 2016 at 14:26
  • 3
    In reality, you were "lynched" for suggesting that testers be treated as chickens, rather than pigs (at least that's why I downvoted that answer)...
    – David Arno
    Apr 25, 2016 at 15:38
  • @Duffy I agree - there are no other titles than developer but in reality, the roles are often arranged very much along traditional lines.
    – Robbie Dee
    Apr 25, 2016 at 15:44
  • @DavidArno In our shop they are. In fact, we have an identical set-up to what Duffy outlines. Our testers work a sprint or two behind. The rub is which members of staff you deem to be the development team. As I outlined in my post, I simply don't accept that DBAs and build managers can be time boxed in the same way as vanilla devs - YMMV.
    – Robbie Dee
    Apr 25, 2016 at 15:48
  • We manage to time box pretty well, it takes a little bit different thinking and process for testers estimates as they are more hard process driven than gut estimation driven, but they usually end up with much more reliable time estimates (once they can baseline them during first pass testing) than devs due to the nature of their work versus ours. I'm the team's DBA/DB Developer and fit completely fine in a sprint, so I'm not sure how they don't fit into the work flow for others.
    – Duffy
    Apr 25, 2016 at 17:49

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.


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.

  • "Hence concepts like verbosity..." - did you mean velocity?
    – Robbie Dee
    Apr 25, 2016 at 19:09
  • If this was on large enterprise application with several departments wanting different things at different times, would Scrum be a bad fit for that as well?
    – JeffO
    Apr 25, 2016 at 20:25
  • @jeffO, could work with scrum, provided ONE person had the power to decide between departments.
    – Ian
    Apr 25, 2016 at 21:00
  • @Ian - that's a good reason to only have one project owner and projects can be sliced and diced as large or small as someone sees fit.
    – JeffO
    Apr 30, 2016 at 2:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.