Mendelt's blog

Poka Yoke, error handling for your process

October 7, 2009 by Mendelt Siebenga

Software engineering is still a very human endeavor. Its a complex process that requires our ability to create non-standard solutions for non-standard problems. But with this ability to creatively solve problems comes a tendency to introduce defects, one of the seven wastes lean production and lean programming try to eliminate. Jack Milunsky describes several ways to reduce the amount of defects in his article. I want to look at another idea from lean manufacturing for reducing the number of defects called Poka Yoke in Japanese and have a look at how we can apply this idea to software engineering.

The dirty secret of pair programming

September 22, 2009 by Mendelt Siebenga

Pair programming is one of the more controversial extreme programming practices. Having two people work on the same piece of code at the same time looks very unpractical and inefficient to someone not familiar with this practice. Pair programming proponents like me are usually quick to point out the benefits like improved quality, less rework, better communication and better knowledge sharing within teams but I think the biggest reason pair programming works is usually kept quiet.

If you're not moving you're not agile

September 8, 2009 by Mendelt Siebenga

Lately I've seen a couple of doom scenario's scetched out for agile. It seems agile is dead or at least dying at the hand of the PMI. I don't want to bash the authors of these articles. I respect them and agree with most of their arguments but not with their conclusions. Agile is changing, sure, but it's not dying, we're all about embracing change right?

At it's core agile isn't a process or a methodology, it's a set of principles with a framework of practices to support them. One of the most important principles is about change, not just in our requirements but in our process, our organization and even in change itself. Agile is about improving your process, trying out new things checking them against our principles and core values and keeping what works.

Personal Productivity on Agile Teams

August 25, 2009 by Mendelt Siebenga

Personal productivity systems like Getting Things Done or the Pomodoro technique are quite popular among agilists, and I'm not surprised. There are many parallels with agile practices, most of these techniques use practices resembling iterations, backlogs and frequent retrospectives to become more productive. I've been experimenting with a couple of these but once I started using these at work I found that these don't automatically work in a team setting.

Fixed price part 2, Fix it with agile!

August 4, 2009 by Mendelt Siebenga

In my previous fixed price article I looked at why fixed price is not only bad for suppliers but also for clients. I also argued that contrary to popular belief using big design up front methodologies will not solve these problems. Fixed price is difficult no matter what methodology you use. In this article I want to look at why fixed price is still popular with many clients. Then we'll look at what we need to do to be a bit more successful at fixed price and how agile methodologies can help us do this.

To look at why fixed price is popular with clients I'll start with a comment I got on my previous article. Sergey Pyatigorsckiy commented "As to my mind, pure fixed priced project can be defined as a project nobody cares about. At best it's spending money, at worst - wasting money. That is why real huge governmental projects are fixed priced: Nobody really cares."

I tend to agree to some extent. Clients often don't care about the project, they often just want the software and be done with it and for them the easiest way to get this is fixed price. So fixed price projects and clients that don't care seem to go together. In most cases clients do care about the outcome of the project. Clients have a problem they want to see solved. Or, more cynical, in larger organizations, clients want a big successful project to show their manager. Often clients don't realize that in order to improve chances of a successful outcome they should care about the project. Most clients have experience with processes like buying a new car, they specify what they want, recieve a time and cost estimate, wait a few days and get their car. Why should software be any different?

Fixed price part 1, what's so bad?

July 21, 2009 by Mendelt Siebenga

In his excellent article 10 Contracts for your next Agile Software Project, Peter Stevens described 10 different contracts that are often used in software development projects. At the end of his article he singles out one contract-type:

"Fixed price projects and agile development are considered not to mix. I know from experience that this is not strictly true. I am also convinced that other forms are better."

I completely agree with him on this but since fixed price contracts are so common in software development it seems like a good idea to look at them a bit more carefully. In this article I want to look the problems with fixed price and why traditional software engineering methodologies are unable to solve these problems. In my next article I want to continue on a more positive note and show how agile practices will help you make the most of fixed price.

Hacking code ownership

July 8, 2009 by Mendelt Siebenga

Two weeks ago I wrote an article about the virtues of sharing code in teams. Just to confuse you, this week I want to tell about a situation where code ownership actually helped me introduce a couple of agile engineering practices in a team I worked with some time years ago. Here's the story. Facts, names and situations have been twisted a bit to ensure the client's privacy.

The project
When I got started on this project the team had already been working on the code for some time. They didn't have strict rules about code ownership but most developers had started on their own piece of code at the beginning of the project and had kept on working in the code they knew as the project went on. When I joined the team everyone had a well defined layer of the application to call their own. I got to work on the UI layer.

On previous assignments I had tried introducing TDD and pair programming. But I often ran into problems. Maintaining a set of tests is hard when your co-workers change your code and don't fix tests when they break. You end up spending extra time fixing the tests other people break and it's hard to convince people to do TDD when it's costing you so much work.

Who's the owner? Shared code vs. code ownership

June 23, 2009 by Mendelt Siebenga

I think it's widely recognized that shared code is important in agile teams. It's an effective way to streamline your development process, making your teams more flexible and productive. Transitioning from code-ownership to shared code can be hard. Lets compare the two, look at the problems in transitioning from one to the other and see how we can ease this transition.

Shared code is only a corollary practice in extreme programming but most agile teams I've seen implement it successfully. Many other teams are still in a situation where team members have what I call code ownership, the code base is divided into parts that can only be edited by certain persons or groups within the team. Usually the code is divided along lines of expertise, for example database-professionals develop the database, the back-end and domain logic is developed by one or more experts, and interaction designers and UI developers are responsible for the user interface. The reasons for this division are usually efficiency, people work on the parts of the code that fit their skill set, and responsibility, when something is wrong it's easy to find the guilty party by looking at what piece of the code failed.

Open Space, an agile way of meeting

June 9, 2009 by Mendelt Siebenga

Last year I went to the European Agile Open conference, two intense days of meeting interesting and interested people and talking about all aspects of agile. I don't think I ever learned as much in two days. The conference was held entirely in the open space format and one impression I left with was that lots of the ideas we talked about there were also applied in the organization of the conference.

This week I had the pleasure of helping to organize my own open space event. The Open Space Code day in the Netherlands. We copied this idea from Alan Dean who has been organizing events like this for some time in the UK. I got the same impression, the dynamics are different, the goal is different but the event certainly feels like an agile project. I want to have a look at the similarities and see what we can learn from it.

Are you efficient or effective?

May 28, 2009 by Mendelt Siebenga

Efficiency and effectiveness are two words that are often used interchangeably. Many methodologies promise 'increased efficiency and effectiveness'. I find this strange because in a rapidly changing environment like software engineering these two are often mutually exclusive. I think in order to understand agility it’s important to understand the differences between these two and the tradeoffs you are making between them.