( success | failure ) of (your | other people's)
-> experience
-> skills and knowledge
Sharing information regularly creates group knowledge from individual knowledge. Daily Standups are your local best friend.
Competence = skill * discipline * knowledge * social connectivity
And connectivity has more effect than knowledge
@jurgenappelo: from "The Hidden Power of Social Networks", Cross, Bob et.al
But usually I tend to give away little bit discipline by varying my methods. Doing little changes to project plan on every project. Using different test libraries on different projects etc. Some changes are rejected, but best changes remain in effect. It's kind of genetic algorithm for developement process.
Although you can learn some ungooglable little things with other ways too.
Get feedback.
Getting constant feedback from customer, and more importantly from the actual end-user, is essential way to learn about the problem we are trying to solve with the end product. By (my) definition Agile requirements management is a learning process where both the customer and the developer are working together to learn more about the problem. But even then requirements are constantly evolving and only way to make things work is have continuous feedback from actual users of the end product. So you have to commit to continuous integration, deployment and delivery so that the customer has something she can use to give the valuable feedback we need.
Use pretotyping to get feedback (actually you are trying to get prefeed...) on early stages. The main objective of pretotyping is to answer questions about the product's appeal and usage: Would people be interested in it? Will they use it as expected? Will they continue to use it? ... Failing ideas even before prototype stage is much cheaper and you have more time for new ideas to prototype.
Use prototypes to learn about technical challenges you are facing before starting large scale production. The main objective of prototyping is to answer questions related to building the product: Can we build it? Will it work as expected? How cheaply can we build it? How fast can we make it?
But sometimes you can introduce deliberately failures to learn. For example Netflix uses system they call Chaos Monkey. The Chaos Monkey’s job is to randomly kill instances and services within their architecture to learn what happens during outages.
See also
"I have not failed. I've just found 10,000 ways that won't work." -- Thomas Edison
No comments:
Post a Comment