Scrum and software development success

By , last updated March 31, 2014

I’ve been working on a scrum team for several years on some very large and some smaller projects. Although it’s a good methodology to have things done, there are some issues that every leader must consider before using it.


Simple design
A scrum method forces tasks to be designed as simple as possible. An iteration that lasts 3 weeks cannot deliver more than there is capacity. That’s why tasks are divided into many smaller pieces and this gives everyone a good picture of what is done and what is outstanding.

Refactoring is always an issue in software development. In case of scrum refactoring have seldom high priority. This leads to large and difficult to maintain software source code. Although when prioritized the refactoring is done quickly and effective.

Test-driven development
Correctly organized scrum process is always test-driven. It means that after each iteration the code is tested and eventually is sent back to a scrum team to fix bugs. It results in a code with minimal bugs when being presented to the customer.

Pair programming
Pair programming is a good and sometimes effective way to solve difficult tasks. Although it costs much and that’s why it should be used carefully.

Continuous integration
Tools like continuous integration servers are a key to an effective and successful software development process especially when many people work together. It saves time and money when integrating pieces of software together.


Performance with a scrum method is rather high. That is the result of an iterative development. When a developer knows that he or she must show results at the end of the iteration they do what they need to solve the problem in time. It doesn’t mean that everything a leader wants will be done, but the most reasonable things will be.

When it comes to motivation so there are many factors that can motivate together with many other that can do the opposite job. The motivators in a scrum team are usually to have the work done, to show results to the customer, to receive a bonus for achieved results, to work together with other people and so on. But all these motivational points disappear when there are conflicts in a team or where the tasks are not as simple as scrum requires them. If you give a large scale task it means that the team cannot solve the problem within one iteration. If a team does not see the results the members begin to miss the main motivation – to deliver.

When it comes to innovation so there is nothing. It’s not possible to stress a team to deliver results and at the same time expect that they will work innovative. Innovation takes time.

Problem solving
Problems will be solved within an amount of time that an iteration lasts. You can’t expect the best solution to the problem. Here is a risk of solving problems in a way that creates more problems later.

Well, this is the main point. For the time I’ve worked in a scrum team (14 month) only 3 of 17 developers are still working here. It gives a staff change rate of 85%. If you think that this is normal – think again.

So where is welfare?
Not in a scrum team. Here are some of the reasons people don’t like it:
– you don’t have a feeling of having an ownership to the stuff you develop
– you see how easy other people take your place and your code
– you can’t make many errors because other people will come and get you for that
– constant competition that doesn’t stop for a minute
– your achievements are easy to forget because it’s not you that do the work in a scrum team – it’s a team! Nobody cares if it’s only you that do the work.

Should we use scrum?
Well, it’s a good methodology to have things done, but you as a leader must consider the following:

1. Do you have enough stuff on the market? Remember staff change rate of 85%!
2. Do you care about those who work for you today and don’t care if they leave you?
3. Do you have enough work for a whole team for a whole period?
4. Does your business depend on innovative thinking?

Update: In 2013 I have been a part of a new and a very large project that used Scrum. After 1 year and many thousand hours of development, it was suspended. It failed. Reason – detailed project description was not available beforehand. Smart people who could tell developers what to do weren’t there. Scrum didn’t help in this case as developers aren’t allowed to think themselves with Scrum.

Senior Software Engineer developing all kinds of stuff.


  1. Terje July 12, 2012 Leave a Reply

    Interesting thoughts, but have you thought about why the change rate was that high? Could it have something to do with the number of sub-contractors on the team?
    What about the others teams? Did they have the same change rate?

  2. Tatyana July 18, 2012 Leave a Reply

    Well, we had some subcontractors during that time that stood for about 14% of the stuff. After 3 years the number of people from subcontractors increased to about 28%. That is one of the reasons why I think people should ask themselves a question about enough stuff on the market.

    Another thing: after those 3 years the project lasted how many of my own colleagues from that project still work at my company? The answer is 47%. Not every company have money enough to recruit so many people each year.

Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>