One of the first agile principle I learned is that we should introduce learning culture and remove blaming culture.
Blaming culture comes up easily. It is proved being viral and, in the long run, dangerous for the organization.
So no wonder that, particularly in critical and expensive fields such as the I.T., you can easily see the blaming game.
We need to introduce values that can step by step remove such unsustainable attitudes, and replace them with something better, technical ans social as well.
The chances to have success depends on knowing the following factors:
what is going on in terms of the "iceberg model of human behaviour",
what kind of mindset have the players: pre-conventional, conventional, or post-conventional,
do you have enough referent power?
The better you know that, and the better you can understand how much work is still needed to move to a learning/comunicative/healthy environment.
If you can exercise this "referent power", the simpler thing that you could suggest is: simple tools, simple communications, simple solutions, simple descriptions, simple documentation; a sprint backlog and a product backlog, or kanban, a daily stand up meeting, a shared wiki, discourage the use of emails for task related communications.
Is that all?
Not.
If you consider it enough, then it will probably will turn out in something like the "flaccid scrum".
I think that scrum tools are only the starting points. We have been able to write a backlog, and that means that we know that the P.O. knows what she wants, and, at least once, we probably know also how much can we do in a sprint, and we had the opportunity to discuss that between"pigs" and no "chikens".
This should be a good way to start a process that should allow us to learn by our feebacks.
The feedback could hopefully be, during a daily Scrum, something like the following: "I worked on this backlog item, I tested it (manually?), but I found that the code was not so clean so it toke much more time than we estimated, and probably I need more time working on it, and moreover I'm not sure if there is something else broken somewhere, so I need to work on it a little bit more on tests, and so on..."
So, we will realize this: the estimation have not be fulfilled because we have not been able to describe a clear definition of done, and we underestimated the side effect of implementing new features, because of preexisting unclean code without automated tests.
Those things are "wrong", but this kind of feedback is very good, as long as we can use this knowledge as an answer to learn, and consider that the questions contains what we need.
There is the possibility that such statement will not considered the key to find more answers, but just to play again the blaming game.
Consider for example this answer to the report of the developer: "yes but that means that you guys didn't do unit test, and you guys didn't write clean code..."
respect of the following: "yes and that means that the next time we should have much more consideration about internal quality as a unnegotiable part of the scope for any task, so unit testing and refactoring will be simply included in our activities."
Then there comes again the role of the coach (or scrum master) that is the one that makes the system move in the "learning way", instead of the chaotic way.
How? Difficult to answer, but one thing to know is that during difficult un-comfort situation, the learning can be much more powerful. Ben Fuchs:
"When we are exiting the comfort zone, it will be the time we least want to examine ourselves - and the seduction of self-righteous certainty of our positions will resist any questioning. But this is exactly the time to notice our reflex reactions, slow down and practice all the coaching and communications skills we have learned in seminars. If you can catch the process in the moment when it flares up, then the learning is much more powerful than after its over." (link)
29/11/2009
No comments:
Post a Comment