Playing golf and Scrum - Part II - codecentric AG Blog
This is the second part of the article Playing golf and Scrum. Part one can be found here Playing golf and Scrum – Part I
Probably you have seen or you can imagine that on the golf course, there are some obstacles like water, bushes or sand bunkers. You need to avoid or conquer them on the way to the hole. And quite often the player focuses so much on not aiming at the obstacle that finally he sends the ball exactly to where it shouldn’t be.
The root cause of this lies in the following principle: The brain does not interpret the word “no”. If you read now “Do not imagine the big green ogre”, I am quite sure that a picture of the ogre just blinked in your mind. You need to create a representation of what not to do and then you need to cross it with some kind of red line and make it disappear.
The fact is, that even beginners in golf can send a ball for at least eighty meters with ease. The water obstacle is fifty meters in front of him or her, so he or she has at least thirty meters of error margin. The only thing you need to do is to focus on the hole, do the perfect move that you practiced so many times and the ball will go over the obstacle. But what really happens the player focuses on the water obstacle and the ball tends to land in the obstacle. Let’s look at how this principle also appears in Scrum.
Scrum Teams focus on
- Not having any bugs
- Automate all the Test Cases
- Get a hundred percent Test Coverage
- Have as flexible architecture as possible
- Gold-plating and looking for the perfect solution
- Spending days on changing graphical design and building ‘prototypes’
And the end effect is having a failed Sprint. What was the Sprint goal? What ever it was, it was none of the above.
Writing Unit Tests does not prevent bugs. It only validates the way of thinking of the programmer. TDD is a way of organizing architecture and code, not a testing technique, what is quite often misunderstood. When you focus on testing all possible cases without looking at the risk analysis, you take the risk of having only partially tested Sprint which can be rejected by the Product Owner or will jeopardize the next Sprint. When you look for the perfect solution you will spend too much time on one task and won’t have that time for the others. Remember that the most important si to deliver the Product Increment. It doesn’t need to be fully featured and beautiful, but needs to be DONE.
You see now that same good practice rules apply to many different areas of life. This time it was presented by comparing playing golf and using Scrum framework. Both seem to be very simple and they are but they need a lot of practice and require mastery in techniques.
- Keep your eyes and mind fixed on the goal.
- Do not try to make figures, charts and other indicators look good. The indicators should indicate the actual state and will look good when you will adapt practice.
- Do difficult things first and prioritize correctly. Try different tools and approaches and try them until you will find it easy.
- Avoiding obstacles and solving issues is part of the game and it will become natural when you keep in mind what is the Sprint Goal and Product Delivery that you want to complete.
People say that you play golf to be relaxed and to play golf you need to be relaxed. To be agile you need to be professional and to be professional you need be agile.