To avoid any upcoming confusions, beer coaching is not about coaching people to drink beer. It’s more coaching a larger organization by putting a crate of beer in the middle in the evening, and have chats with people. I didn’t invent this one. A few weeks ago, a colleague, Christian Dähn told me that he was bringing a crate of beer to a client to have an opportunity to talk to some folks, and reach a deeper relationship with the ones attending.
I wasn’t convinced.
Up until a colleague, Anna Lorenz, convinced me to try that out at a client we are both working right now. She actually had to push me. Here is what I think now about it.
Huib Schoots asked me the other day whether I was on a blogging spree. I provided him an answer. Well, I answered him over twitter. So, it was more than a shallow answer. I told him that he was only seeing side-effects of what I tried to do. Actually an example that he should focus on my outcomes rather than the outputs. Here is the longer answer.
Over the past year I ran a couple of Scrum trainings. At first I found it sort of funny to notice that amount of misconceptions that seem to appear in these various classes. Recently I figured that it would be more helpful to clarify some of them. Among one of the larger, and probably more manifested misconceptions regarding Scrum lies in the Sprint Review meeting. Let’s examine that one today. I am quite sure that someone has written about this before. I found that it would be worth to throw in my point of view as well.
Since the last global Scrum Gathering I worked together with a couple of Scrum trainers on principles to scale Agility in the enterprise (German, we are working on an English translation). We reached a point where we want to share our current results. In this blog entry I am going to take a closer look at our thoughts on global optimization. Stefan Roock already discussed Enlightened Customers (German). Andreas Schliep discussed the part on satisfied employees (German).
One piece of caution: I translated the original German text on the fly without consulting back with the others. It’s likely that we will work on the English translation and continue the word-smithing.
There are a couple of professional organizations out there. I joined a few of them. How did I pick the ones that to join, you ask? This blog entry serves as an overview, and a decision aid for tester folks also looking forward to become more professional in their work life.
Back in 2009 I attended my first coding dojo. It did not take long for me to realize that it was fun, and all the programmers in that setting learned a lot. Ever since I was convinced about what some call Deliberate Practice. It’s a practical exercise to help you learn a deeper understanding of a skill – most often accompanied with a mentor or coach that provides you feedback. Let’s take a look into various formats that are suited for testers.
The other day, I received a mail from one participants of an introductory class on Scrum:
I am working as a development team member. We are looking for a ScrumMaster, and I want to take on this role. I agreed with my boss that I still need to contribute as a team member, and therefore will work 50% as ScrumMaster, and 50% as development team member.
While thinking this through, I got some concerns. I think it’s not a wise idea to become the ScrumMaster for the team that I am also developing in. What are your thoughts?
As an alternative we have a closely related team. I could work as a ScrumMaster there, and their ScrumMaster joins our development team. What do you think about such a solution?
Since I run into this type of question often, I found I should publish my thoughts on it for future reference.
When I went back to work in the first week of January 2014, I was surprised. Right before Christmas some rallies started in Hamburg. For whatever reasons, some folks started to make fun out of the high demand of police that was present in certain areas of Hamburg – the so called danger zone. Let’s see what I learned from the news about those folks.
What if you found out that you were living in a matrix? That the world before your eyes has been blurred. That a lot of the things that are dear to you actually are counter-productive to your goals. How would you recognize this?
Some years ago, with Systems Thinking, I started to realize some problems with my own thought processes. Ever since then my realizations went worse. I am too frank to face you with the full truth. Still here are some stories worth thinking about.
When it comes to focus, I am deeply convinced that you should focus on the right things. That raises the question what the right things would be. In the Lean community there is a saying that we should not focus on outputs, but rather on outcomes. Let’s try to turn this argument around, and wonder how we can focus on outcomes rather than outputs.
