Agile/Scrum blog

Onderwerp: Craftsmanship

Starting TDD with legacy code

Harm Pauw Door: Harm Pauw,  13-12-2016
Onderwerp: TDD  Craftsmanship  refactoring  

One of the questions people that want to start with Test Driven Development ask regularly is: “I find starting with TDD on an existing project hard. How do you get old legacy code testable?”. Unfortunately, one of the most common answers to that question is: “You just have to begin and take small steps.” And while the answer has truth in it, it’s also a much too simple answer that doesn’t really help you to start. How come and what is a better answer to the question on how to start?

Craftsmanship smells

Harm Pauw Door: Harm Pauw,  30-08-2016
Onderwerp: Craftsmanship  Tech  Team  

In software development, there is a concept called "Code smell". A code smell is a visible indication that usually points to a deeper issue with your source code. It doesn't necessarily have to be a problem, but it's a good idea to investigate further and do something about it if it is indeed a problem. An example of a code smell is a class that has many lines of code. Usually this is a sign of poor design  by violating the Single Responsibility Principle (the class does too many things) and begs for being refactored into multiple smaller classes. Getting rid of these problems that are pointed out be code smells increases the quality of your code.

Your technical practices, like your source code, should also be of high quality since they play an important role in delivering quality. And just like in source code, your technical practices can also contain indications that perhaps something is not right and deserves some attention. So perhaps a good way to call them is Craftsmanship smells. You know you might be dealing with these kinds of issues if you hear people (or yourself of course!) make remarks like these:

  • "It works on my machine."
  • "We only run our tests once a day during the night because they take forever to finish."
  • "I don't dare to change this piece of code because I don't know what the consequences are."
  • "Run the tests again. Surely they will work this time!"
  • "I'm not feeling that confident about whether our release this weekend will go as planned"
  • "Who changed this part of the code? And why?"


If you hear these kinds of remarks, it's time to investigate further and spend time doing something about it if it turns out to be a real problem. Technical excellence can be a real accelerator for a team, but lack of solid technical practices can slow you down or get in the way of delivering high quality software in a timely matter. In Continuous Delivery, which is becoming more and more the standard in the world of software development, technical excellence is even a necessity. So identify those craftsmanship smells in your environment and get rid of the underlying problems!

Scrum causes more change for developers than you might think!

Harm Pauw Door: Harm Pauw,  11-07-2016
Onderwerp: Development Team  Craftsmanship  

When starting to use Scrum as a framework, often a lot of attention is given to the Product Owner and Scrum Master roles. This makes sense, since these are roles that didn’t exist before and play a key part in the Scrum framework. The development team of course also gets attention: developers need to learn the new way of working, know the events, roles and artifacts of Scrum. But besides that, there’s also a lot that stays the same for developers. They still develop features using the same programming language, they still have to test their software and release it once in a while, so that all stays sort of the same right?

Technical Agile Coach

Door: Marco Kroonwijk ,  23-02-2015
Onderwerp: Technical Coach  Continuous Delivery  CD  Extreme Programming  XP  Agile Coach  Technical Debt  Architecture  Development Team  Role  Craftsmanship  Practices  

A while ago, I started working at Prowareness, and as new employees we choose our own role title best fitting our experience, skills, ambition and passion. I chose the title of Technical Agile Coach, without really having defined what it actually is. It just felt right!

However, occasionally, people ask me what a technical coach does and what the difference is with “other” Agile Coach titles. So here’s what that answer is, for me.

Clean up the kitchen!

Martijn Dehing Door: Martijn Dehing,  11-02-2015
Onderwerp: refactoring  Craftsmanship  improvement  Testing  unit testing  zelfsturende teams  

Upon entering the room of team ‘Someone Else Broke It’ the negative energy was immediately noticeable. The tension was present from the utter silence within the room. It was like walking onto a cemetery. Glancing at the team happiness metric on the wall showed an obvious decline in motivation and drive. Both the customer happiness and the team velocity followed this negative trend. The only line that seemed to go up was the defect trend line…. This team seemed in serious trouble. What was going on here?

The Daily Goal

Barry Overeem Door: Barry Overeem,  14-07-2014
Onderwerp: Agile Teams  Craftsmanship  High Performing Teams  Scrum  Scrum Teams  

The daily scrum is the most used scrum meeting. This sounds obvious because it occurs every day. But it's also the first practice organisations and teams apply when starting with scrum. 

Although the daily scrum is a very straightforward meeting with a clear structure and can be practiced daily, many teams fail to extract the potential value it offers. It is used merely as a status update meeting, performed mechanically and resulting in incoherent and ambiguous individual plans. 

This is a shame, because a well-performed daily scrum should be energizing, inspiring and result in a shared refined daily plan that is created and supported by the entire team.

If your daily scrum has become unfocused, practiced mechanically and is an energy-drainer; using the best practice of a daily goal is a great solution!

Analysis Paralysis or: How I learned to stop worrying and love to code

Harm Pauw Door: Harm Pauw,  07-04-2014
Onderwerp: Analysis  Craftsmanship  Backlog Management  

Let’s say your team has a feature on the backlog that it wants to implement. It’s been discussed during a number of refinement meetings, but the team still thinks that needs more analysis before it is ready enough to start implementing it. Otherwise, it might happen that they implement it the wrong way. So you keep on analysing but it takes ages before the feature is finally implemented. It wouldn’t be a problem if this happens once in a while, but if this occurs frequently and it stops you from delivering new features, your team might suffer from something called analysis paralysis.

Management High Five

Peter Koning Door: Peter Koning,  01-04-2014
Onderwerp: Agile Management   Craftsmanship  Motivatie  improvement  

When I was a manager, I was trying to create a culture of continuous improvements and innovation. This often was a hard job. Keeping the balance between business as usual and making time for improvements and innovation is difficult. Over the past months I did an interesting discovery that I would like to share. It took me quite some time before I really understood it. I hope you can understand it much quicker than I did!

Continuous Delivery in a Nutshell

Harm Pauw Door: Harm Pauw,  02-12-2013
Onderwerp: Continous Delivery  Tech  agile  Craftsmanship  

What is it?

Continuous Delivery is a software development practice where you make sure that your application is ready to be deployed to production at any time. You’re not only making sure that when a developer commits a change is, it is correctly integrated by building and unit testing your application (Continuous Integration). You’re also making sure that your application is always ready to be deployed by running automated UI and/or acceptance tests on it and testing the release process itself.