Since the waterfall logic of the old project management methods was sacrificed to the necessary agility of software development, tensions still arise in many companies today about how to deal with the systems that feel diametrically different. Because even if IT departments often use SCRUM for software development and thereby achieve much better goals, because the developers finally have 2 weeks of air during a sprint to work in peace, the interface to decision makers, management, finance is often exposed to great friction. Let me explain this a bit more.
Everyone who has ever worked in classic project management knows the triangle of project management: time, scope and costs. For example, if the scope of a project increases, the costs also increase and it takes longer. Or if you want to complete a project in the same amount of time with fewer people, the scope of the project decreases. But if you want to implement a higher scope in the same time and with the same resources, the transcendent fourth dimension of the triangle – quality – suffers.
Many companies of today still rigidly follow the project triangle in daily life. In the fourth quarter, funds are allocated for projects of the following year (cost-fixing), planning for the live start of the project is determined (time-fixing), and the scope is only minimally subject to disposition. This leads to the fact that SCRUM, which requires a much higher agility in time and thus costs to keep scope, later often works flexibly on the fourth dimension of the project triangle – quality. I.e. there are results that are “in time, in budget and in-scope” and at the same time exposed to lower quality. And then SCRUM is questioned by many, since it “apparently brings nothing”.
On the other hand, we also see in companies that allow their teams pure SCRUM, this is also exposed to the risk that the departments can exploit this, because the developer teams of their own accord set the speed and they can use the sprint to simply work less. Quite often, I hear from decision makers, “Somehow, I lack control.” In what’s called Estimation Poker, the team determines how long something should take for each task over the next two weeks. Anyone who has sat in these Estimation Poker rounds can agree with me about how highly estimated things sometimes are here. After all, the higher the estimate, the more time a developer has to complete a task. And who wouldn’t like to have a more stress-free work schedule? I.e. SCRUM works because of the high personal responsibility of all participants only if this freedom is not exploited by the individual.
In the next section we will have a closer look at the important role of the product owner within SCRUM, since many outsourcing companies primarily work according to SCRUM and the product owner is the most important interface to the customer. Thursday we will turn to process management.