SCRUM rules the world, the developer’s world.

Most software development teams we come across during job interviews work within an agile development methodology and, in the main, that methodology is SCRUM. That’s how it would appear at first glance in any case, but if you drill down you soon discover that the methodology used is not really SCRUM at all. If you consider what Scrum Alliance defines, for example, you’ll discover that some absolutely key elements of the SCRUM process are not employed, such as the right roles, the team concept, responsibilities, meetings etc.

So, how do you know if you’re really working in SCRUM? The SCRUM methodology is a framework and can, and should, be adapted to your particular project’s needs. Naturally, SCRUM may vary to some degree depending on the organization, the team, the project and the technologies employed. But, there are a few cornerstones of the framework that are unalterable, and those are related more to a way of thinking than to particular aspects of organization.

Consider the following simple questions:

  1. Is the work structured in increments of a regular size which are based on time rather than on scope? (sprint).
  2. Is each sprint planned with sufficient detail and is it clear to each team member what will be the result of the work?
  3. Does the team have full control over the ability to deliver planned tasks?
  4. Who is estimating the effort required to complete each task?
  5. Does the work in a sprint get interrupted by “very important” tasks? How does this affect the planned sprint?

As you’ve probably noticed, in this short list there’s nothing about meetings, daily scrums, planning or review as those are actually few isolated aspects of the SCRUM methodology, which some teams do get right. Stil, their process can’t actually be called SCRUM as it’s sorely lacking the right mindset to employ SCRUM fully and effectively.

What is often badly missing is the shift of responsibility from managers to the development team and, related to this, the central role of team commitment in the process. In my view, there cannot be a SCRUM without team responsibility, and to make it fair, without the team’s full control over the ability to deliver at the end of the sprint.

Obviously, there are many factors that can affect the team’s ability to deliver and thus the team’s commitment. Requirements might be unclear at the time of planning or could change during sprint. Dependencies on other parties might hinder starting work on a task. Sometimes it’s not even possible to estimate a task due to a lack of knowledge in a particular area.

Therefore, it requires the constant work of all involved parties, including the team, the SCRUM master and management as well as the customer to create the right environment. 

And that’s exactly how it works at ProxiDock. Her’s the deal. At ProxiDock the entire team works together to create and maintain the right setup. Once that’s in place, it’s the team’s responsibility to deliver the best results possible, and all in a process that we call SCRUM.

Michał Bartmański

Leave a Reply

Project Wallboard >>
ProxiDock Sp. z o.o. sp. k.
ul. Ruska 3/4
50-079 Wrocław, Poland

+48 71 343 24 19