|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:||Stephan van Rooden, 16-11-2015|
When starting a team you run into a variety of challenges. In an earlier blog series I stated that a group of people doesn’t make them a team. How do you create a team? Where do you start and do the same practices apply for a new management team? In this blog I will share with you an alternative to the often used Team Manifesto. Using this technique will get even a management team into a better, more clear and positive collaborative state.
|Door:||Martijn Dehing, 30-03-2015|
|Onderwerp:||scrum team knowledge sharing single source bus factor|
At the last Sprint Review meeting the Scrum team presented their latest product. Some features were not ready so the Development Team, together with the Product Owner, decided not to show these to the stakeholders. “What is the reason that new report we were so desperately longing for is not in?” Patricia from sales asked. “Well, the feature was not finished so we decided to leave it out” replied Neil, one of the developers. “Ok, it was the most important feature of the sprint! Was there any specific reason why it is not finished?” “Simon had some family-related issues so he was not in half of the sprint, and because he has the knowledge we were unable to finish it on time. But hey, we delivered something else instead!” Neil replied.
In traditional organizations people are pushed more to become specialists and to have focus, alone and heroically, on one tough topic. Everyone wants to feel special, and these local hero’s certainly get a lot of attention, questions and are asked for that meeting where those important decisions are made! Is this what it feels to be Superman? Is this what the organization needs?
|Door:||Barry Overeem, 19-01-2015|
|Onderwerp:||Scrum Culture Team|
Recently I read the book 'The People's Scrum' by Tobias Mayer. In this book he spends a chapter on describing the differences between project culture and team culture. To me, the given examples of both types of culture are highly recognizable and I can easily extend and complement the list of examples with my own experiences. And this is basically what this blog post is all about, my view on the project- and team culture.