When people first try scrum, or TDD (or any new process), they feel uncomfortable. We “know how to do” stuff, but then we’re asked to try on something new. Then our comfort zone alarm goes off. We feel constrained. Scrum puts limit on sprints, so we’ll need to actually help the testers finish testing our story.
When on the Scrum Master Podcast, I was asked a very important question: How do I get a systemic view of the organization. This is worth going deeply into. Let’s start with why this view is valuable. The more I work with teams, I find there’s a limit of change I can make. Or, rather, they can
To improve we need transparency. We cannot solve problems we don’t see. We can’t improve an invisible process. We need people to speak out about how they feel, how their work is affected. In order to improve, my team needs me to admit I’m late, and not hide I’m working for two weeks, digging a hole, and find out
I usually make fun of the “become a scrum master in 3 days”. I mean, what can you learn in 3 days? Glad you asked. Once a year or so, I get a chance of going through an exercise with my army unit. These few days are plentiful of agile post material. I’ll try to cram
Why do we keep trying to attain control? Looking at reality with agile glasses (and even without them), we don’t like uncertainty, and control over a piece of reality relaxes us. A controlled environment is good for our health. In fact, it seems that when we are in control we don’t need to do anything.
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
In my last post I wondered why Agile emerged in the software business, rather than in another field. I still wonder about this, but in the meantime, something happened that made me think that “we’re not the only ones”. The new field? Video games. And I’m not talking about the production side, which is obviously
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
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
I’m a big fan of Manager Tools. I’ve been listening to the podcast and recommending it to anyone, manager or not, for the last five years. A recurring topic in the podcast is Manager Tools co-founder Mark Horstman’s laws: It’s all about people More communication is better. And there are more, and I invite you