Have a Cookie

First Line Software may use cookies and my IP address to collect individual statistics and to provide me with personalized offers and ads subject to the Privacy Policy. First Line Software may use third-party services for this purpose.

This overview asserts that many of Scrum’s primary practices, far from helping boost productivity, are in fact stifling it. Is Scrum really too rigid with its timeboxing, estimations, and other procedures?

This overview asserts that many of Scrum’s primary practices, far from helping boost productivity, are in fact stifling it. Is Scrum too rigid with its timeboxing, estimations, and other procedures?

Would it perhaps be better to let go of at least some of its structure and just develop software as fast as we can? For example, there is this claim that giving up timeboxed iterations and iteration planning meetings has led to marked improvements in delivery.

The first thought that comes to mind here is: how do they know that? Since they have given up sprint planning and estimations as well, where would they get the data to back up this strong claim? It is only when you track your velocity and use consistent estimation techniques over several iterations that you can actually measure the effect of any suggested process improvements. Absent that, we are asked to accept these claims at face value.

Personally, I like timeboxed iterations. Treating each sprint as a mini-project, with its own scope and deadline, helps keep people motivated and focused. A healthy dose of stress, including time pressure, can actually be a great concentration aid.

More generally though, if developers are left to their own devices, they will probably get rid of all elements of the process that don’t seem valuable to them directly. Estimations will be the first to go; you know everybody hates estimations. However, the folks paying these developer’s salaries may object: they need at least some kind of predictability regarding what they are getting for their money. Scrum provides the predictability while at the same time leaving the (creative) developers alone for weeks at a time, letting them do their thing. Win-win in my book. A “forget-the-useless-process-just-write-code” approach has the project sponsors relying on nothing but faith; and it’s easy to see how most people will be uncomfortable with ponying up money on faith alone.

Download Case Study

Need more details?

Fill in the form and we’ll contact you as soon as possible.

David Tedford

Vice President

David Tedford has over 20 years of sales experience within the IT/software industry. He excels at being immersed in a customer's environment, understanding his customers requirements, crafting solutions to meet those requirements, and ultimately providing solutions to his customers.

Vladimir Litoshenko

Senior Vice President

As the head of business development for First Line Software, Vladimir heads up business development in Western Europe and Russia.

Vladimir began his career in IT in 2002, when, as a student of Faculty of Automation of Computer Science of the First Electrotechnical University (ETU “LETI”), he began his work at The Morfizpribor Central Research Institute (CRI). Vladimir joined the StarSoft team (predecessor of First Line Software) in 2004 as a Junior Software Developer. As he gained experience with more and more projects, he was promoted to leadership roles.

Richard Leslie

UK Business Development

Richard has over 15 years of sales and account management expertise in the IT and Tech sector. He has worked on many outsourcing engagements with global companies.

David Fien


David is a business development professional with more than 20 years’ experience as a specialist in the acquisition of partnerships and IT/software services for associations, not-for profits and corporations in Australia, New Zealand and USA. He has specific expertise in the healthcare, legal and hospitality industries.