Here’s another example of why language matters, and how the words we choose matter so much. I tried to join the European Lean-Kanban tour, not in person, but on twitter. (By the way, seems like an awesome tour, I’m thinking about going there next time around). And then the following tweet comes up: “@cyetain: Talking
I have a big mouth. The kind that doesn’t shut up, especially when it needs to. I thought this was a development in my adult life. Alas, no. Recently I went to my first school reunion, and the people confirmed I had this situation back then too. Usually it’s not a problem, and if it
When asked:”What’s the best thing I can do right now to improve my code quality” I always answer: code reviews. A code review is the best bug preventer out there. And even more, I like its older brother better: Pair programming. Because if a code review finds bugs after the fact, working in pairs finds
Everyone likes to know the answer. In fact, this question can be interpreted in many ways, and answered that way too. For example, if we’re using agile techniques, we assume things will go wrong. So what we’re asking really is when is the scope going to be completed. And that’s not the way agile works,
Thanks to Dilbert, developers, engineers and the rest of us managed people, have come to disrespect the “manager”. Ok, it’s not just the comic, some of it was perpetuated by actual managers. Still, there are cases where the managers do the right thing, and the developer messes up. Whenever this occurs, regardless if from the
I’ve recently posted on the Typemock blog on test organization, and gave an example of how organizing Outlook folders is not as effective as dumping everything in one bin and using “Search”. Here’s a quote (from myself, by myself): The search box finds things much quicker. There’s also a penalty in the filing system. For
I’ve gone back to watch Uncle Bob Martin’s presentation “Agile overview” from NDC 2010 (while you’re at it check his “The land that scrum forgot”, the man is such a storyteller!). In the presentation, Bob tells about Winston Royce’s study “Managing the development of large software systems”, from 1970. This article is the origin of
Jim Highsmith recently wrote about “Velocity is Killing Agility”. Velocity was originally used as a planning tool. You measured velocity in the past, in order to see how much throughput you’ll get in the future. If we put it very simply: Throughput = Capacity x Velocity Now, as Jim describes in his post, velocity has
InfoQ had a round-up of ideas about “How Long Would it Take to Build the Product?”. It was funny (ha-ha funny) to read some of the responses. One person suggested that upfront estimations end up in a fixed scope, which is anti-agile. If I was new to agile, I would read it this way: if
A couple of comments on my last post (the sad truth about agile planning) made me think: Maybe I was slamming agile planning too much. Then I thought (after an elaborate discussion with myself) – I wasn’t doing that at all! So let’s put some things in perspective: Can I make a plan for the