In case you missed them, here are the top posts from the Agile Zone this week--as chosen by yours truly. This week: There's just no time to learn, answering the question "when will we complete our agile transformation?", Choosing software by what's best for the business, building a "hat rack" for open source contributors, and how to fire employees (don't!).
To a large degree, Agile software development IS learning. We try things mindfully, watch the results we get, reflect on why we get those results, and adjust. We do that at multiple levels of granularity, from choosing what products to develop to writing code that works reliably. There is always more to learn. There are ways to learn better ways to learn.
People tend to ask me the general question of how long it will take to complete an Agile transformation. In order for change to occur in your organization, you must enable it to happen. Want to know how long it will take to complete an Agile Transformation? I think you need to listen to your guide but you also need to control the weather.
When people are discussing what language/framework/library to use for something, the general criteria people talk about is “what best solves the business problem.” It’s much more honest to just admit that technology choices are made from a desire to work with a new technology, or because a technology is familiar.
Open Source contributions are often anonymous and the rewards are intangible. A little bit of tangibility is a huge thing. There are unsung heroes at every hackathon and tech meetup who could benefit from some recognition. Perhaps they're looking for a new job or a transition in their existing job. Perhaps they're looking to break through one of the obscure social barriers that seem to appear in a community where everyone looks alike.
Don’t. There, that was an interesting post. Short, but interesting. When you worry about how you’ll fire people, what you really should be worried about is why you need to fire people in the first place.