About Frank, our fantastic handyman

johnny-automatic-electric-drillAt home, we have a handyman. His name is Frank. He is very experienced and all-round and was able to take on every construction or repair job we gave him in the past years. Frank is easy going, never stressed out and often takes a break to smoke a cigarette and enjoy the weather. Although we pay him by the hour, we do not complain about his smoking as he asks a reasonable fee and works quite efficiently. Also, my wife really likes the guy, as she feels he can be trusted and always understands her really well.

For instance, last year he redid our kitchen, which turned out really nice. And although we wanted to go for a four ring gas hob he convinced us to take a five-ring hob with a central wok burner. He argued this would hardly take any extra space and would be very convenient in case we needed to use a bigger pan. Every time we have visitors over, my wife refers to Frank and how happy she is about the choice we made.

This year we were getting the bathroom done, but since we only have one shower in our apartment I asked Frank: “When will the bathroom be done?”. He answered “that depends”, “why are you asking?”. I told him about my concern of using the shower and he smiled. “I can make sure the shower can be used every time I leave as long as you don’t mind the mess.” he replied. Well… that solved one of my worries, but I was not completely satisfied, so I kept asking.

“But, when will the bathroom be done? I mean.. how much money is it going to cost?”. “Those are two different questions” Frank answered, “The first one depends on how often and how long I will be here and the second thing depends on what the bathroom should look like and what other more important jobs you have around the house”. “Hmmm… I understand”, I mumbled, but had the unpleasant feeling that he was dodging the question.

My wife has a very busy and responsible job, but she is also the one that decides on the interior related things in our house. Not that I do not care, but we both know that she has “feeling” for these things and I (an IT guy) do not. I told my wife that I could let Frank in and pour him his coffee, but that I did not see how we would organize this bathroom rebuild. She had an easy solution: She asked Frank to promise to work 3 days a week for at least 2 months. He worked on Monday, Tuesday and Thursday, since he had another job going on Wednesday and Friday. Every Thursday evening he would leave late, so he could meet my wife to show what he did and discuss with her what he was going to work on next week.

I would not have taken that route and would have probably asked an interior designer to draw the bathroom in 3D. Then I would have asked several building contractors to quote me with a price and a delivery date. I’m sure my wife would not have been as pleased as she is now with our new bathroom. The bathroom turned out exactly as we wanted, she even feels she has built it herself. Another good thing is that we only paid Frank for the work he actually did and the materials he needed. Of course not everything went flawlessly: Frank had to reroute a sewer pipe because we wanted the toilet in a different position. That was a lot of hassle, but my wife really wanted it like that, so it was our own choice in the end.

I’m glad I’m in IT doing agile projects, because construction work is not my cup-of-tea. 😉


Waterfall versus Agile – comparing software development methodologies

One of the first decisions you need to make as a project manager before starting a project implementation is: Which development methodology should I use? There are several methodologies you can use to manage a project. This blog contains reasons and information about two methodologies which can help you make this decision.

What is Waterfall?


The Waterfall model is a sequential design process, often used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design, Construction, Testing, Production/Implementation, and Maintenance. This means that when each of the eight stages are completed the developers move on to the next step. Once a step has been completed developers can’t go back to a previous step without reviewing the whole project and starting from the beginning. There is few room for changes or errors, so a project outcome and an extensive plan must be set in the beginning and then followed carefully.

What is Agile?


Instead of a sequential design process the Agile methodology follows an incremental team based approach. Developers start with a minimalistic project design, and then begin to work on small modules (sprints with a defined duration and a running list of deliverables planned one sprint in advance). The deliverables are prioritized by business value as determined by the customer. At the end of each sprint project priorities are evaluated and tests are run. These sprints allow bugs to be discovered in an early stage and customer feedback can easily be included into the design before the next sprint is run.

Comparison between Waterfall and Agile

In this picture you can see the differences between both methodologies at a glance.


Image source: Waterfall versus Agile

Advantages and disadvantages of both methodologies

Advantages Disadvantages
  • The customer knows what to expect in size, costs and timeline
  • Minimal impact in case of employee turnover due to strong documentation
  • Developers and customers agree on what will be delivered up front
  • Progress is more easily measured, as the full scope is known in advance
  • Team members can work on different projects simultaneously
  • Customer presence isn’t strictly required after the requirements phase
  • Makes it easier when multiple software components must be designed for integration with external systems due to early known design
  • Once a step has been completed, developers can’t easily go back to a previous stage and make changes
  • The initial requirements can’t be changed without heavy impact
  • Testing the whole product at the end is risky due to finding bugs in early written code
  • A customer’s evolving needs are not taken into account. When changes are demanded this will impact the deadlines and budget
  • Possibility of a dissatisfied customer with their delivered software product due to not seeing the product until it is almost finished
  • Value is added every sprint
  • Easier to add features that are up-to-date with the latest industry developments
  • Project priorities are set before every sprint and evaluated after each sprint
  • Customer feedback is allowed and will contribute to the final end product
  • Testing each sprint (also by the customer) ensures no surprises at the end
  • High level of customer involvement (strong sense of ownership)
  • Short time to market: quickly produce a basic version of working software
  • Transparency is high
  • Deviations on the final product can arise due to no existence of a definitive plan
  • Customers need to have the time for the high degree of involvement otherwise the product will not match their requirements
  • Additional sprints could be added due to added requirements, because not all these requirements are clear during the start of the sprints, this may increase costs for the customer
  • The iterative nature may lead to a reduction in overall system quality, as there is less emphasis on understanding the finished system as a whole early in the project


After putting the information together, what can we conclude from all this? Both methodologies have their own strengths and weaknesses. The choice of methodology really depends on the goals you want to achieve. This all comes down to the context of a project. In fact, will it not be better to combine aspects from both methodologies to make the best possible software development process for the project?

When should you use the Waterfall methodology?

  1. When customers will not have the ability to change the scope of the project once it has begun
  2. When a clear image of what the final product should be must be worked out in advance
  3. When definition and quality are the keys to success instead of fast delivery

When should you use the Agile methodology?

  1. When customers need to be able to change the scope of the project
  2. When there isn’t a clear picture of what the final product should look like
  3. When quick production is more important than the quality of the product
  4. When the product is intended for an industry with fast changing standards, like software development
  5. When you have skilled developers available who are adaptable and able to think independently

Ultimately, although the way in which you do your work is important, most important is delivering a solid and supportable product that satisfies the customer’s needs!