First Line Software is a premier provider of software engineering, software enablement, and digital transformation services. Headquartered in Cambridge, Massachusetts, the global staff of 400 technical experts serve clients across North America, Europe, Asia, and Australia.
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.