Recently I wrote an article with the title “Agile… not by Scrum, but with Scrum”. Maybe I didn’t bring the content of this article to the point for experienced agilists. I shall therefore try to be more specific here.
You can be agile without using Scrum or Kanban. You can also use Scrum and thus not become particularly agile, I’ve seen that several times.
Let’s take the following example: Just because a Solution Manager is now called Product Owner, writes down his requirements and then calls the document ‘User Story’ does not saying he’s using an agile method yet. I have seen such documents which hardly differed from conventional requirement documents, but the title of these documents suddenly was “User Story” then. I didn’t find much of the actual idea of a user story in these documents, quite the opposite. Nevertheless, many in the organization were proud to write user stories out of ignorance. There is not much to complain about as long as the document describes good requirements and is helpful for the workflow used. However, nothing has become more agile yet, although there is a person called Product Owner and a document called “User Story”.
At the same time I saw that the team had a Scrum Master. This Scrum Master was not necessarily the coach for the team, but in this case the person who organized the meetings, managed the tools, and occasionally went to a manager with problems to get a solution. On the last point, one might think that it is a matter of working up impediments, which is an important task – no question. The rest I would rather see as assistant tasks – not as core tasks of a Scrum Coach.
Has this changed anything for the team? I think so: After all, there are new roles and new document names. Is that agile now? Has that changed anything for the better? Probably not, no.
Let’s look at another example: Recently I was with a team that tried to introduce an agile method to get better. During the introduction of this method, this team decided that it was already applying many of the agile principles, and that by introducing their chosen agile method, they might not necessarily improve the quality of the collaboration so much, but mainly change it, because the principles of agility had already been well established – by common sense, and because they had sufficient freedom to evolve.
Was this team now perfectly organized? No, not from my point of view. It wasn’t perfect either, but when is a team perfect? This team was good, and I didn’t think it was necessary to use a particular agile method here, because it was much more important to anchor some other principles in the team that it hadn’t used yet. E.g.: the conscious application of continuous improvement in short cycles.
What does agility actually mean?
I’ll try to describe it this way:
- To have the customer in the focus of our activities
- To work next on the things that bring the greatest value to the customer
- Delivering value appreciation in short cycles
- To have open and transparent communication within the team and with stakeholders
- Self-organized approach in the team
- Being able to react to changes at short notice
And there are certainly more good points.
What I’m saying is that you can be agile without using a particular agile method in the concrete.
I think it is really good to deal with agility in the sense of “being agile” and at the same time implement it with the right method. “Being agile” has something to do with people and their attitudes.
Wasn’t this the same as with classic project management methods? The method alone does not improve much. Only the use of the right tools by people who pursue a certain purpose with these instruments brings a good result. And so it is with the agile methods.
Sounds logical, doesn’t it?
Recent Comments