Some companies do not want to introduce either Scrum or Kanban at team level because they do not want to be restricted by existing rule systems (although Kanban does not have any fixed rules at all), but still carry out an agile transformation. So the question is whether it is possible to build an agile organization and go your own way.
The short answer to this question is: yes.
The longer answer is: yes, but…
You probably already figured that out. I would also strongly advise against wanting to go your own completely new path. If you want to do without Kanban or Scrum (we are only talking about the team level here at the moment), we initially have a problem of understanding.
On the one hand, Kanban does not come with any rules of its own. It is a loose construct of overarching principles and very general practices. How I implement this is entirely up to me. On the other hand, Scrum implements the principle of agility by providing a few guidelines that we have to fill ourselves. However, there are very few guardrails, and if I remove one of them, I also have to ask what aspect of the principle of agility I am removing.
An example: There are short sprints because agility means proceeding iteratively. So if I want longer sprints, I say goodbye to the principle of continuous iterative learning.
Another example: there is a retrospective because I not only want to test an discuss the product regularly, but also my own approach and my own way of working in order to derive regular improvements from what I have learned.
If someone comes to me with the task of implementing or introducing agility, but doing that without Scrum or Kanban, my question is what bothers the company (or the organizational unit), because of course it also involves a lot of effort to develop something completely new and unique.
This is also the first piece of advice I can give you: try to find out what the one point in Scrum or Kanban is that bothers your organization. Often (I have encountered this situation more than once) it is all about the details. Therefore, we are faced with an all-or-nothing attitude, although that is not necessary.
Another example: it is not possible (because you have neither the expertise nor the budget) to assign a separate product owner to each team. So far, we had one project manager who worked with four teams. It wouldn’t even be that unusual.
In such a case I would be a pragmatist and would say: let us take Scrum and modify it by adapting the role of the product owner to our own circumstances.
Before you hang me from the next tree: Unfortunately, the world is not always the way we would like it to be. Sometimes we do not have the resources we want or need. Sometimes there are rules and agreements that go against everything we want, but which we cannot change because we may be part of a very complex company.
In such cases, we could start a crusade and first try to change everything that does not fit our wishes, which we will probably not succeed in and ultimately will only mean that we will never take the first real step.
So this »radical« view might not get us anywhere.
It is wiser to adapt to the circumstances, to make compromises, and at least to get on the right track. We might be able to change some of these inappropriate rules later, but at least we have gotten started.
It gets even more disgusting when there are simple political reasons that prevent us from introducing one of the known systems. Maybe management does not want to know anything about Agile, but a department wants to introduce agility because they have recognized the benefits for themselves.
In this case I would say take what you know, modify it to fit the realities of the environment (if the environment cannot be changed) and call it something else.
Is this a nice or elegant solution? No. Of course it is better to be transparent and to enter into dialogue, to go the way of persuasion, but sometimes that just does not exist – again one of the stupid peculiarities of the real world.
But what if we really want to do something new?
First of all, prepare for a lot of work. Then we take on the principle of agility, make sure that everyone really understands it the same way, and then build a separate rule for each individual aspect.
I strongly caution against becoming careless in this regard. A big advantage of Scrum is that everything is considered. There is a rule or guideline for every important aspect. If we want to develop something of our own, we have to make sure that we proceed iteratively, regularly check the product or our results, regularly question our own approach, and regularly exchange ideas with customers and/or users. For these things alone we need fixed rules and, of course, someone who makes sure that these rules are observed.
Be careful with phrases like »if necessary«. They are always a stupid idea because they only mean that you do what you want and should do less and less. If you do not want to have a set frequency, you can do it on a case-by-case basis, e.g. whenever a class X ticket is closed, we enter into a dialogue with the customer to have it approved.
In this way we would have created a rule that, although open in terms of time, is dependent on other factors that force us to enter into a dialogue with the customer, which brings us to a key point of these considerations: we have to create constraints. Without them, our house will collapse. This is based on the very simple idea that we want to do something differently because we want to avoid something. If we learn how to circumvent rules and constraints, we can leave it at that. And the desire to do something different is the first step on this path.
Scrum is characterized by the fact that events, roles and artifacts are defined. It is precisely these three major fields that we also have to play on if we want to be successful. I need events to populate (or work with) my artifacts and roles to do that.
Maybe I donot want to have a backlog, maybe – for whatever reason – I want to work with a milestone plan. To do this, I need to know how to work with this milestone plan and who does what when. When and how does this plan change? Who can change it?
And it is always a good idea to regularly question and review your own actions, isn’t it?
Obviously, this can just get you started. Developing something completely new and unique is not an easy task and should not be considered lightly. If you need to d it (or are forced to do it) your solution will follow the unique constraints and rules of your company, therefore you will have to identify the exact spots in your organization, that prevent you from using Scrum, and start from there.
Once again: find a proper rule for every aspect of Agility: iterations, learning through inspection (product and way of working), collaboration with the customer/user and self-organization.
Core: You can develop your own system to work agile. However, the danger of not paying attention to agile core points or even deliberately avoiding them is extremely high and therefore requires a lot of discipline. The better alternative is to take something you already know and modify it if necessary.
If you need any assistance or want to know more, just speak to me.
