13

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?

Revenant
  • 1,395
  • 2
  • 11
  • 16
  • 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. – RemcoGerlich Apr 25 '16 at 08:44
  • @RemcoGerlich "because Scrum" is actually correct. It's popular and delivers results quickly if done right. But if whether it will be a good fit for our team, I'm not certain either. That's why I'm asking for possible alternatives as well. – Revenant Apr 25 '16 at 09:07
  • 1
    Are the "implementation staff" needed to be able to present the initial system to the client, or are they mostly working on the deployment (and training) that happens after the client has given their final approval (step 6 in your current way of working)? – Bart van Ingen Schenau Apr 25 '16 at 09:18
  • @BartvanIngenSchenau The latter is correct: they're in charge of deployment and training after the client approved the system. – Revenant Apr 25 '16 at 09:21
  • 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... – Elias Van Ootegem Apr 25 '16 at 10:20
  • 12
    5 developers but not a single tester? – Apfelsaft Apr 25 '16 at 12:15
  • 8
    @Revenant you're confusing *jack of all trades* (individual) with *cross-functional* (team). – guillaume31 Apr 25 '16 at 12:45
  • 6
    Popularity. Always the best way to choose anything. – Robert Harvey Apr 25 '16 at 14:18
  • 4
    Cowboy coding is not something Scrum can solve - you have basically a skinned down version of scrum already going on, and it is _not helping_ you to solve it. Scrum is about task organization, not code implementation. If you want to solve Cowboy coding, what you need is to sit down and talk, and agree on a coding standard. – T. Sar Apr 25 '16 at 17:07
  • I don't think there are many development teams using Scrum that also do training and implementations for clients, so I don't see why this is a problem unless they're doing testing as well. – JeffO Apr 25 '16 at 20:38
  • @EliasVanOotegem I don't know about my manager, but I thought Scrum can give us requirements faster and in turn get software done earlier. But now that you've mentioned Kanban, I think a combination of both would be a better fit. I might be wrong, though. – Revenant Apr 26 '16 at 01:39
  • @Apfelsaft The team hasn't adopted TDD (I'm currently studying it) and they seem to be not open to the idea. They think testing on the system level is enough. But this topic is better off on a different question. – Revenant Apr 26 '16 at 01:43
  • @guillaume31 I was under the assumption that everyone does everything in an Agile environment, as some of the people I know that do Agile told me. – Revenant Apr 26 '16 at 01:46
  • @ThalesPereira I thought code quality would increase if requirements are well-defined and deadlines are not tight, such as in my case. But on the other hand, some of the other coders tend to produce spaghetti regardless, so I guess the cowboy coding problem is agnostic of development methodology. – Revenant Apr 26 '16 at 02:06
  • @Revenant you can have the best defined requirements on your project - if you have rockstar or cowboy devolpers in your team, you will need a really good QA process to make sure the code quality is good. As you said, this is agnostic of methodology. If you really want to get better code, you need better developers, not a better method - you can train the ones in-house or get new ones, but changing methodology is tackling the problem from the wrong side! – T. Sar Apr 26 '16 at 11:17

5 Answers5

17

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.

Bart van Ingen Schenau
  • 71,712
  • 20
  • 110
  • 179
  • 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 '16 at 15:33
5

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.

Encaitar
  • 3,053
  • 19
  • 26
  • 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 '16 at 13:29
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.

Community
  • 1
Robbie Dee
  • 9,717
  • 2
  • 23
  • 53
  • 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 '16 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 '16 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 '16 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](http://programmers.stackexchange.com/questions/311465/scrum-what-are-team-members-busy-with-during-a-sprint/311469#311469), 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 '16 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 '16 at 17:49
  • @Duffy You can of course try to time-box everyone but dev is usually the bottleneck so it just isn't worthwhile for us. – Robbie Dee Apr 25 '16 at 18:30
  • @RobbieDee, I'm loathed to say "you are doing it wrong", as that assumes their is a right way to "do agile". However, if a task hasn't been tested, how can you claim it's done? Thus, if your testers are testing tasks from previous sprints, then each sprint finishes with a collection of not-done tasks. Further, by the time you get around to testing, the devs have moved on to new tasks, so fixing issues will be slower and those fixes will impact on the work that can be achieved in the sprint. Making testers "pigs" and having them test "in sprint" solves these issues. – David Arno Apr 26 '16 at 12:47
  • @DavidArno I totally agree - it is sub-optimal for sure. Welcome to the enterprise world of shared resources... – Robbie Dee Apr 26 '16 at 12:54
3

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.

ndyer
  • 209
  • 1
  • 8
0

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.

Ian
  • 4,594
  • 18
  • 28
  • *"Hence concepts like verbosity..."* - did you mean velocity? – Robbie Dee Apr 25 '16 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 '16 at 20:25
  • @jeffO, could work with scrum, provided ONE person had the power to decide between departments. – Ian Apr 25 '16 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 '16 at 02:24