Disclaimer:
They are imaginary conversations resulting from my own understanding of real
conversations I have had with different people and teams.
What method / approach do you use?
Scrum.
Do you use the X, Y, Z … practices?
No.
Sorry, but without these practices this is not Scrum.
It is Scrum. Our way of using Scrum!
We are using Sprints!
What features do you have delivered last Sprints?
We have delivered some
requirements specification.
That is not a Sprint. The Sprint was explicitly
defined to end with a set of potentially releasable features.
Our
collaborators use Scrum and they call that a Sprint.
Another
team and another context …
How often you deliver?
Sometimes
daily and usually after few days.
What method /
approach do you use?
Scrum.
You are much close to Continuous Delivery. Why are you saying that your
approach it is Scrum? They do not deliver more often that one week. They have a
ceremonial to support a potential release that cannot fit in less than a week.
More, this is the Scrum competitive advantage: if they do not deliver in less
then a week and could prepare in advance the work for that week/weeks (Sprint),
they will have a superior velocity. This is the explicit intentions of the Scrum
creator.
I do not want to talk about him.
He does not offer a good approach for software.
Maybe you are right, but he had provide the Scrum definition, and this is
what the whole world understands by Scrum. If you have found a better but different
approach in your context, this is a good hybrid, but is no longer Scrum.
The message/intention problem - maybe you do not believe it, but
also in software development different practices and methods have names and
definitions.
You are not Groot! You cannot use whatever practices in your context and put the label Scrum. You will transmit the wrong message to anyone outside to your team, but also inside to your team.
You are not Groot! You cannot use whatever practices in your context and put the label Scrum. You will transmit the wrong message to anyone outside to your team, but also inside to your team.
Interface problem – the main aspect that it is visible outside the development
side, it is the proposed interface - the life-cycle - between development and customer and
development and other enterprise teams. When you say Scrum, I know which kind
of “contracted” interface - life-cycle - you are proposing. You cannot have your local
convention that override industry well known definitions. You can have any kind
of process you need/want but is honest and professional to use the right label in order to transmit the right message.
Some teams use Waterfall and put the Scrum label on it …
Some teams use Continuous Delivery and put the Scrum label on it …
Some teams use Lean Exploratory Startup and put the Scrum label on it …
How could be that right? How could you differentiate the different approaches
that you will use in different contexts? How you could differentiate the
context of different teams and different products?
I am Groot!
