Applying management to project in continuesly development

Question

Company background:

We are a company that consists of five developers, a sales department an HR and a communication department. (this question will only focus on the development department).

We have build our system (and is still building) using Angular which means that the system is Web based. Right now we "pretend" to use scrum however there are a lot of steps that i as Head of the department is still unsure how to tackle.

The issue

Right now our development plan for the year has been set. This consists of alot of smaller projects that has to be done from Q3 of 2015 and until end of 2016. As of now each Developer is tasked with one assignment and two developers at a time would rarely work on the same project (which I see as a problem).

Im finding it hard to divide each project into groups and thereby allowing two or more of my developers to work on the same project without overlapping. It seems to me that web development is more or less a straight line of steps that has to be done until the project is complete and goes into the testing phase.

I feel that this kinda negates my idea of a Scrum team which in my mind should be a team working on the same projects.

My question is how do you guys work on a single web development project that is being split into many different tasks? Should I continue handing out assignments to each individual developer or is a collaboration on the smaller projects necessary to encourage a sense of team spirit?

Answer 1

I see different things here and there are no details of what things you're developing and for who so take the feedback with a pinch of salt of course ;)

First of all there's no such thing as Scrum for a single developer, the whole idea of Scrum is centered around the concept of a self-organizing, multi-disciplinary development team, that is tasked with a general goal and then develop iteratively, deciding who does what in an autonomous and dynamic way. That said I think you should first focus on the problems and how to solve them, for maybe Scrum is not the answer and being "compliant" to Scrum might not help you at all.

It seems to me that web development is more or less a straight line of steps that has to be done until the project is complete and goes into the testing phase.

Well, that is true only in a very stable environment, that is an environment in which:

• You're able to capture requirements in a detailed way
• Requirements do not change
• Each stage of development produce a fully completed, not-subject-to-change-whatsoever deliverable that can be handed to the next phase
• People do not change
• Goals do not change
• You don't need intermediate feedback

If you're not in that situation (and if you're doing web-development I'd bet you're not), acting like you're not exposed to such problems can be dangerous. To be more specific to your question, the Scrum way works pretty much like this (and I'm really simplifying here for the sake of conciseness, I invite you to have a look at the Guide to know more):

• A product/project backlog is defined
• A team is appointed (the team should have all the expertise required to develop the product/project)
• The team is mainly/totally focused on the project/product (e.g. no such thing as Dev1 working from Mon to Tue, Dev2 working from Wed to Thu, tester working on Fridays, etc.)
• A sprint backlog is decided and prioritized, the backlog is composed by actionable items
• The team splits the backlog into tasks and decides autonomously who's going to work on what, given the priorities

In order for this to work there are also some rules and principles that apply, for example:

• Work is to be done strictly by priority, i.e. there's no such thing as "everything is priority here"
• Backlog does not change within the sprint
• Development is more iterative than incremental

If your situation does not allow for this to be put in place, or you see no benefit in doing this, do not even try to apply Scrum, chances are you're looking for somethinge else. Luckily the Agile spectrum of methods and practices offers you way more than Scrum... :)