It turns out that Uncle Bob had some more to say on the role of the foreman, and how it applies in various situations. However, I have totally different experiences.Continue reading The elite foreman
A couple of days ago, Uncle Bob Martin blogged about the foreman in software development. In it he makes some claims with regards to a role in software development that acts like a foreman on a traditional construction site. Uncle Bob claims that the foreman should be the master of having commit rights, and granting those to team members that prevailed long enough. While the idea reminded me by-and-large to the practice on some open source projects, I am not so sure whether we should start installing foremen (and forewomen) all over the place. Let’s see why.Continue reading The situational foreman
Agile methodologies favor effective team work. Team work is fun to do, hard to grow, and at times unpredictable to nurture. I might be biased here, but I have seen way too few good teams working effectively together. Let’s see what can happen with bad and with good team work in place.Continue reading The Power of the Team
Last week I sat in a meeting with a ProductOwner, a ScrumMaster, and the Development Team. The team works on a legacy code base with about 2 million lines of code together with 13 other teams. Thus far there has been little to decouple the various components. In that meeting the topic of refactoring came up. The bottom line was that the Development Team needed to ask the ProductOwner for time to refactor their code for each story.
What a waste of your time.
Personally, I believe that if you have to ask your ProductOwner to plan in time for refactoring, the ProductOwner should stop all work on the product, and send you on a class on working effectively with legacy code if you are an internal employee. If you are an external employee, your client should fire you immediately.
Wait, what? That’s harsh? I don’t think so.
Let’s take a look at the underlying system dynamics.Continue reading The Curse of Refactoring
We live in a cruel world. Our profession of software development is very young compared to other fields such as banking, hotels, or carpenters. I truly believe we have taken a couple of wrong turns in our short history. In this blog entry I try to shed some light on it by some seemingly unrelated stories.Continue reading The “I don’t want to” attitude
Over the past week I came to realize that fixed prices, fixed scope contracts are broken. I am not sure who came up with the concept, but I sense a larger dynamic at play. Let’s explore what’s causing so much trouble around fixed price, and fixed scope contracts.Continue reading Fixed price, fixed scope is broken contracting
I remember a lively discussion at DEWT 4 around self-education, and how you would know whether or not you are improving. There are lots of ways to engage with self-directed learning – in software testing, software development, leadership, and other areas surrounding this field. But with all these methods around, a single question remains: How do you know whether you’re improving with whatever technique you follow?Continue reading How do you know you’re improving?
Have you every worked with a fake tester? How would you notice? How would you notice how much they are faking? Triggered by a discussion back at DEWT 4, I had an insight triggered by a book that I read earlier in my life: The No-Asshole Rule from Bob Sutton. Let’s see how fake testers and the no asshole rule connect in our workplaces.Continue reading The No-Fake-Tester Rule
Over the past few months I have become more and more convinced about the fact that specialization in software development – which includes programming, design, architecture, and testing to me – is a terrible idea. I don’t know when this came up in the history of our craft, and I think we need to stop it – now. I also know that I am probably upsetting some folks with these statements, still I think you should critically read this blog entry, and make up your own mind about the matter.Continue reading On Specialization
While I was cleaning u my bag that I carry around with on various travels, I found the following notes. They were part of my introduction for the keynote at the Agile Testing Days 2012 in Potsdam, Germany. My talk was on “adaptation and Improvisation”, drawing an analogy from the famous geek movie “The Matrix”. I wanted to keep these notes somewhere. That’s why I decided to put them up on my blog. Hope you like it. Imagine Morpheus’ and Trinitiy’s voice.Continue reading What is Agile Testing?