Nice slideshow that's easy to understand:
http://www.slideshare.net/jeppec/cqrs-why-what-how
Tuesday, November 13, 2012
The surprising truth about what motivates us
How to create an enterprise with staff that evolves from following orders to autonomy and motivation:
http://www.youtube.com/watch?v=u6XAPnuFjJc&feature=youtu.be
http://www.youtube.com/watch?v=u6XAPnuFjJc&feature=youtu.be
Sunday, October 28, 2012
Finger pointing
In the Agile dev world, there is a rule saying 'no finger pointing'. This means not rubbing people's nose in something when they made a mistake. This to assure people don't become afraid of touching some code or making mistakes. I think it's also a way of being professional. Now here's the thing. Most people want to know when they made a mistake. So you need to tell them. It's about how you tell them of course. Polite and calm is the manner it should be.
This works for most people, but the rule has a couple of disadvantages: What do you do when someone really doesn't give a f*ck? You already told him 10 times to run the tests before check in and he still doesn't do it. What do you do then? I say finger point away! Finger point till he cries :)
DevOps
Nice post explaining what DevOps is:
http://blog.csanchez.org/2012/03/13/infrastructure-as-code/
http://blog.csanchez.org/2012/03/13/infrastructure-as-code/
Sunday, February 26, 2012
Existing principles interestingly explained
Here's an interesting video from Gojko Adzic stating that software quality is everyone's problem. Nothing revolutionairy, but I especially like the way he talks about removing team bottlenecks and the importance of job titles.
http://gojko.net/2012/02/17/sleeping-with-the-enemy-video/
http://gojko.net/2012/02/17/sleeping-with-the-enemy-video/
Sunday, January 22, 2012
Work to the rule
I want to share a piece of text that fascinates me in the exellent book 'Pragmatic Thinking and Learning - Refactor Your Wetware'. It fascinates me because it is a general piece of text, which imo can be applied to a lot of big Agile teams on projects that take some years to finish.
[Start quote from the book]
In industries or situations where one is not allowed a fullblown strike, a work slowdown is often used as a means of demonstration. Often this is called work to rule or malicious obedience, and the idea is that the employees do exactly what their job description calls for —no more, no less— and follow the rule book to the letter. The result is massive delays and confusion—and an effective labor demonstration. No one with expertise in the real world follows the rules to the letter; doing so is demonstrably inefficient. According to Benner (in From Novice to Expert: Excellence and Power in Clinical Nursing Practice [Ben01]), “Practices can never be completely objectified or formalized because they must ever be worked out anew in particular relationships and in real time.”
[End quote from the book]
Often, when the velocity of big teams is not good, the teams itself propose a number of rules to improve their velocity. Sometimes these rules deal with check-in procedures, refactoring unfamiliar domains should be reviewed by persons familiar with that domain, adhering to certain conventions and so on... That's all needed and all fine. But if the project takes a few years to finish, it can happen that the number of rules can grow a lot, or that the people who invented certain rules, and more importantly, that knew WHY the rule was needed, are gone.
When your project has an entire wiki full of rules, and not all of these rules are clear for the whole team, there is a danger of overregulation. This can lead to 'malicious obedience'.
[Start quote from the book]
In industries or situations where one is not allowed a fullblown strike, a work slowdown is often used as a means of demonstration. Often this is called work to rule or malicious obedience, and the idea is that the employees do exactly what their job description calls for —no more, no less— and follow the rule book to the letter. The result is massive delays and confusion—and an effective labor demonstration. No one with expertise in the real world follows the rules to the letter; doing so is demonstrably inefficient. According to Benner (in From Novice to Expert: Excellence and Power in Clinical Nursing Practice [Ben01]), “Practices can never be completely objectified or formalized because they must ever be worked out anew in particular relationships and in real time.”
[End quote from the book]
Often, when the velocity of big teams is not good, the teams itself propose a number of rules to improve their velocity. Sometimes these rules deal with check-in procedures, refactoring unfamiliar domains should be reviewed by persons familiar with that domain, adhering to certain conventions and so on... That's all needed and all fine. But if the project takes a few years to finish, it can happen that the number of rules can grow a lot, or that the people who invented certain rules, and more importantly, that knew WHY the rule was needed, are gone.
When your project has an entire wiki full of rules, and not all of these rules are clear for the whole team, there is a danger of overregulation. This can lead to 'malicious obedience'.
Subscribe to:
Posts (Atom)