|Door:||Wilbert Seele, 05-10-2016|
Starting Fresh with Agile
I attended Scrum Day Europe 2016 last summer and had a great time. The talks were great and I was cured of a sudden case of the Zombie Scrum to boot! I began writing this article some time later, but due to circumstances it took me until now to finish.
Part of the program was an update from Scrum.org on what they’re working on, and a follow-up talk about Scrum Studio. This really resonated with me as it confirms something I’ve long suspected. Scrum Studio was born out of empirical observations of Agile transformations. The observation in question being that the transformation doesn’t happen. Of course, there’s always exceptions to the rule, but in general the finding has been that the running organization can’t change Larman’s Laws have been confirmed.
|Door:||Harm Pauw, 31-08-2016|
If a non-developer looks at some source code on the screen of a developer, that source code will look like some random characters in all kinds of funny colors. They think that this is what makes programming hard. I think that this is also one of the reason why time and time again attempts are being taken to create visual tools to avoid having to manually write source code, like UML tools that generate code for you.
|Door:||Harm Pauw, 31-08-2016|
I think SonarQube is a great tool for static code analysis and can help you increase quality by exposing all kinds of quality issues in your code. It nicely complements an automatic test suite, since it can not only find maintainability issues, but also (potential) bugs. If you're running a somewhat older version of SonarQube (read: older than 5.5 which was released on May 5), it could be worth considering to upgrade to a newer version soon because of an interesting new Quality Model and some other features.
|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:||Willem Vermaak, Wilbert Seele, 24-08-2016|
In our Agile courses we often talk about something called “the speed of change”. We illustrate that where it took almost 75 years to get 50 million people on the very first version of a telephone, it took Rovio just over 2 years to reach the same amount of people with Angry Birds. Everything happens much, much faster these days.
|Door:||Willem Vermaak, 24-08-2016|
|Door:||Harm Pauw, 11-07-2016|
|Onderwerp:||Development Team Craftsmanship|