#scrumbut

[agilegnostic]

Agile reborn in new Avatars! Agile software development is not limited to small teams but being profoundly practiced at scale. Many people argue that the original concept of ‘Agile is Dead’ due to continued erosion of its core values and principles.

[5mincolumns]

How To Implement Scrum?

“Principles rarely change, but practices always depend on context. Therefore, it depends on how you interpret < insert method here >. If you associate the method with a collection of principles, you can always keep inventing new practices, as long as they adhere to the principles. But if you associate < insert method here > with a specific set of practices, you’re doomed. You’re going to need a new fashionable word very soon.”  Jurgen Appelo: #Workout: Games, Tools & Practices to Engage People, Improve Work, and Delight Clients

I have a dilemma. The interesting thing is that the more I know, my dilemma is deeper and more complex. Let me tell you my story.

Every time I start doing something new, piece by piece, step by step in order to see the progress (“inspection”) and see what needs to be fixed at the early stage (“adaptation”). I am fully aware of the  context, so I think twice, even if it’s not the first time I/m doing it.  

How should we implement scrum in new the team environment or work place?

Should we do this the empirical way, piece by piece, step by step, though inspection and adaptation?

Or, should we listen to the scrum’s founding fathers who are “dogmatically” saying that “Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices”.

First there is this natural human behavior (instinct?) that conduct us step by step to the unknown territory. On the other hand, well experienced scrum founding fathers must have known “what’s going on” when they are saying “all or none”.  

My gut tells me that scrum implementation is a thing of continuous inspection and adaptation of scrum roles, events and artefacts with the ambition / vision of doing scrum as scrum founding fathers described in the scrum guide.

We are doing scrumbut for almost a year or two and we observe whether team and stakeholders are mature enough for the next step. We know that we are doing scrumbut, we know that we are on our way of scrum implementation.

Scrum as a form must be filled with the proper content which is fully self-aware, autonomous and self-organizing team. Without this, scrum is only theater, even implemented by the book.    

[systemsthinking]

Another perspective on SCRUM

[easybacklog-blog]

You're not doing Agile!

A lot of people are trying to implement agile at work and it isn't easy.

On one hand there are the unscrupulous managers/project managers willing to use Agile for it's known benefits (charts, metrics etc) but not happy to follow all principles mainly when it concerns self managing team and commitment of sprint points.

One the other hand you have the purists that will compain that 'you are not doing agile' regardless of the efforts you are putting in even if you are following the values but maybe not implemented 100% of a methodology's principles.

Agile is about values and adding value not following this or that strict implementation, this has also been obvious to us as many users of easyBacklog.com commented on features we were trying to force them to use e.g. Fibonacci sequence for pointing, in fact a lot of the recent features we have implemented were around giving users more options and customisation in their daily use of easybacklog.com whilst giving them a default set of options that help get going.

They are right, who cares if one uses hours, points, Fibonacci or others, whatever works for them! What's important is the values and principles, tools and techniques are only there to help focus and structure the approach.

[ptomolik]

The curse of "Scrum, but"

When coming to agile, you will at some point encounter a term not rarely used, which is “Scrum, But”. This term is normally used for specifying a scrum implementation which fails to embrace the whole framework. “Yes we are doing scrum, but...” is the introduction where the term origins from.

In fact a thing like “Scrum, but” can not exist in my opinion. When referring to this, it is usually meant that the implementation lacks some kind of role, some kind of meeting or some kind of any other artefact from the framework called scrum. It’s the approach of an implementation which lacks the understanding what the inner workings and the foundation of scrum is.

Let me explain this a bit.

Scrum as a framework, as a scaffold contains a certain set of rules, principles, values, even a describe process (referred as “Scrum Flow”) with roles, events, tools and additional artefacts.

Seen from a very superficial view or without the learning process needed for understanding the rules and workings it could seem, that e.g. having a daily could be unnecessary. A team could easily say “what do we need this for, we have a issue tracker, where our tasks are, the status is clearly visible. so what for do we need a daily in order to align what tasks need to be done or what the status is?”.

Yes you could say that. But it lacks the understanding for why the daily is part of the framework: the daily is meant for aligning the team in the most efficient way possible: with direct interaction and communication between human beings, no other tool can replace that. It is also meant for making impediments visible: the team members communicating if there’s something that stands in the way for resolving the task. This also becomes visible when a task is not moved for a certain time span and for example stays “in progress” for a while.

But this effect only happens, if other aspects in scrum are embraced and in place: Stories that are small. A story small enough to be resolved within a short timespan. Like a day.

This way, you’ll see at the second day at the latest, that there possibly is an impediment, if the tasks for this story still stay in progress.

In order to have a story small enough you’ll need a product owner and a team empowered and enabled to reasonable slice bigger stories into smaller chunks of functionality. Yes, functionality, as you want to deliver working software and have something testable. You will need a product owner and a team able to understand, that the moment the stories are too big, the effect of the daily is diminished. And as a result, the transparency needed and wanted within the framework is damaged. With the transparency endangered the result of the sprint, the sprint goal is at stake, too. With the sprint goal the committments of the team and with that the trust in the framework and the team that they get their job done as well. At the end, the whole implementation of the framework is endangered.

This is only one example of dependencies between different aspects of the so called frameworks scrum. Just like a good watch all elements are meant to work together and only with all the elements together the framework can effectively work.

At least at the beginning, when you are new to scrum and do not understand the values, principles and dependencies of its parts you should not dare to remove or change parts of the framework. The risk doing harm is greater than the benefit.

Remember one essential principle when learning things: SHU-HA-RI: You’ll first have to learn the rules and obey them until you’ll get to a point of understanding where you are able to change things or exchange things without losing what the element stands for.

Until then, “Scrum, But” can not live up to what scrum contains and what it can provide. Until then, “Scrum, But” is nothing like a noisy approach of trying, but not doing (scrum), which can be toxic to your team, your success and your business.