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,
I’m addicted to predictability. I admit it. I want my life to flow along, according to plan. Sure there will be some minimal changes, but I can adapt. I’ve given up on this long ago, as I came face-to-face with real life. I know life is not predictable. And I have embraced change, as agile
In our recent meet-up at the Agile Practitioner group, there was good talk about non-functional requirement testing. One of the first questions we discussed was how come non-functional requirements are second-class citizens. Usually they are patched on the app as an afterthought, and like any last effort, we botch it up. One of the answers
I’ve read an interesting article about how agile leaves security features off the hook. Security features are usually counted as a non-functional requirements. Non-functional requirements have been a thorn in the side of developers for years. But as with everything, it’s goes a bit deeper. Non-Functional requirements are hard to define. You can define uptime,
The more I put time into product management, since, that’s my day job, you know, I’m more aware of user experience. I’m talking about small features or behavior that if you ask any reasonable person, and by that I mean non-programmer, you’ll get a WTF look. Kevlin Henney shows this kind of photo, and now
When software projects fail, we grow the divide between business and development. Let’s analyze a bit, shall we? Why is the divide growing? The divide is basically a metaphor for trust. Mostly, the two sides don’t trust, or sometimes understand, each other. Their goals don’t coincide, and are not communicated correctly. Add to that some
My natural habitat is an agile software development company. I usually meet with people who are already agile, or aspiring to become agile. And then there are other times, where the “real world” hits me on the head, saying I should leave my little pond for a while, and see what’s really out there. For
One of the questions I got in my Agile Practitioners talk startled me. Actually, it wasn’t the question that startled me, it was how I answered. I was talking about why you cannot say “our organization is going agile” while saying: “we’ll get our developers into that agile business in a year”. I know it
I had a wonderful time at the Agile Practitioners conference yesterday. Lots of great minds, great discussions and great presentations. Including mine. So if you weren’t there, here’s the prezi. 10 Phrases that Can Derail an Agile Project
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