As for me, currently a "new renaissance" of Agile (with capital "A") followers is going on. With their not getting the spirit of agile manifesto, but just following "best" practices and rules from some guide books, not regarding the reality, context and consequences of their deeds. (It may be connected to the new generation of IT employees stepping on the scene.)
That's why it's great that there appear new posts on this subject, trying to educate people about the difference between "agile" and "Agile".
There are of course more than 12 mistakes in real life, as every statement of agile manifesto may have infinity of wrong interpretations :-)
In the post the most interesting explanations were for Principles №9 and №11:
Principle #9: Continuous attention to technical excellence and good design enhances agility.
Principle #12: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
I agree with Yegor's definition of "technical excellence" as a presence of "policies and rules", that should define explicit criteria of "excellence" and punishment for disregarding them.
I'd like to add that in the
same way as while education, the punishment for violations must be
inevitable. Because only junction of rules clearness with punishment
inevitability leads to maximal rules conformity.
Also with the aim of clearness, the rules must be reasonable and well-grounded. So when there are doubts on the appropriateness of a rule, one can always explain the goal. Thus when the external context changes and the goal comes to contrast with the rule itself, the rule may be adjusted to the goal without feeling like anarchy.
As to the regular effectiveness improvements, from my experience I hardly recall a few examples of team's using retrospective meetings improved the team work in a bit. Often it transforms into either "self-victimization" or "mutual accusations" time. It's unlikely such a format could lead to any strategic decisions as an outcome. The only definite information one could get from retrospectives is a summary of
unresolved issues. Also "a complains hour" might be needed for many though.
As I see it, the "retrospective" is needed to gather a tactical information. If the Scrum-master or PM is in the close proximity to the team and there are no problems with knowledge flow, one might not need a separate meeting to uncover issues, as everything is at a glance.
But strategic changes demand another tool, that would operate with information on longer scale than just a few-weeks sprint. And very this tool could influence the team efficiency on higher level.
Besides, I would not split "technical excellence" and "team efficiency" as they usually lay on the same axis and furthermore, are implemented in the same way: within "policies and rules".
Also with the aim of clearness, the rules must be reasonable and well-grounded. So when there are doubts on the appropriateness of a rule, one can always explain the goal. Thus when the external context changes and the goal comes to contrast with the rule itself, the rule may be adjusted to the goal without feeling like anarchy.
As to the regular effectiveness improvements, from my experience I hardly recall a few examples of team's using retrospective meetings improved the team work in a bit. Often it transforms into either "self-victimization" or "mutual accusations" time. It's unlikely such a format could lead to any strategic decisions as an outcome. The only definite information one could get from retrospectives is a summary of
unresolved issues. Also "a complains hour" might be needed for many though.
As I see it, the "retrospective" is needed to gather a tactical information. If the Scrum-master or PM is in the close proximity to the team and there are no problems with knowledge flow, one might not need a separate meeting to uncover issues, as everything is at a glance.
But strategic changes demand another tool, that would operate with information on longer scale than just a few-weeks sprint. And very this tool could influence the team efficiency on higher level.
Besides, I would not split "technical excellence" and "team efficiency" as they usually lay on the same axis and furthermore, are implemented in the same way: within "policies and rules".
Немає коментарів:
Дописати коментар