|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?
|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!
|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?
|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.
|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?
|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!
|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.
|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!
|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.