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 foremanCategory Archives: Methodologies
Methodologies
The Power of the Team
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 TeamThe Curse of Refactoring
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 RefactoringThe “I don’t want to” attitude
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” attitudeHow do you know you’re improving?
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?What’s wrong with Software Development?
So far, I think I have undervalued the importance of some practices when it comes to working in a large-scale development shop with lots of teams. One of the major problems with software development in the large is that we as an industry of software developers are terrible. We have bad development practices in place, and it’s strikingly easy to hide your bad software development skills in larger corporations. I also think that the Craftsmanship movement could come up just because we have badly educated software developers since decades.
Continue reading What’s wrong with Software Development?Continuous Acceptance
Over the past year I ran a couple of Scrum trainings. At first I found it sort of funny to notice that amount of misconceptions that seem to appear in these various classes. Recently I figured that it would be more helpful to clarify some of them. Among one of the larger, and probably more manifested misconceptions regarding Scrum lies in the Sprint Review meeting. Let’s examine that one today. I am quite sure that someone has written about this before. I found that it would be worth to throw in my point of view as well.
Continue reading Continuous AcceptancePrinciples of Scaled Agility: Global Optimization
Since the last global Scrum Gathering I worked together with a couple of Scrum trainers on principles to scale Agility in the enterprise (German, we are working on an English translation). We reached a point where we want to share our current results. In this blog entry I am going to take a closer look at our thoughts on global optimization. Stefan Roock already discussed Enlightened Customers (German). Andreas Schliep discussed the part on satisfied employees (German).
One piece of caution: I translated the original German text on the fly without consulting back with the others. It’s likely that we will work on the English translation and continue the word-smithing.
Continue reading Principles of Scaled Agility: Global OptimizationWhy should just the developers have all the fun?
Back in 2009 I attended my first coding dojo. It did not take long for me to realize that it was fun, and all the programmers in that setting learned a lot. Ever since I was convinced about what some call Deliberate Practice. It’s a practical exercise to help you learn a deeper understanding of a skill – most often accompanied with a mentor or coach that provides you feedback. Let’s take a look into various formats that are suited for testers.
Continue reading Why should just the developers have all the fun?ScrumMaster in need, part-time
The other day, I received a mail from one participants of an introductory class on Scrum:
I am working as a development team member. We are looking for a ScrumMaster, and I want to take on this role. I agreed with my boss that I still need to contribute as a team member, and therefore will work 50% as ScrumMaster, and 50% as development team member.
While thinking this through, I got some concerns. I think it’s not a wise idea to become the ScrumMaster for the team that I am also developing in. What are your thoughts?
As an alternative we have a closely related team. I could work as a ScrumMaster there, and their ScrumMaster joins our development team. What do you think about such a solution?
Since I run into this type of question often, I found I should publish my thoughts on it for future reference.
Continue reading ScrumMaster in need, part-time