Peter Götz

Together with my colleagues Uwe Schirmer and Kurt Bittner, I have compiled a book that contains many of our own stories and those we experienced while working with customers and students: The Professional Scrum Team. Maybe they provide value to you. 

Software developers are mostly guys, happy to work by themselves at night in dark rooms. And they turn coffee, cola and pizza into code. Right? My experience so far To be honest, the longer I have worked in software development the more wrong this stereotype feels to me. True, when I learned to code I enjoyed those solitary moments of puzzling out a solution to a tricky problem. I didn't count the hours and proudly told my colleagues and friends about the nights I worked away. The first years of my career as a software developer I worked in a small team of three people where everyone had their specific expertise. I was responsible for the client application we developed for an in-house application. I was the only one working with the specific technologies and libraries I used to create the UIs and so it was basically me and a mixture of Google and API documentations of sorts (it was way before stackoverflow.com was born). I sometimes asked my colleagues for help, but most of the time they were trying to solve their own problems and weren't of much help to me. After five years I left this company to start a job as an IT consultant. Over the next six years I worked in many different teams - together with my colleagues in our own office, as a small team at our customer's office or alone inside a customer's team. Some of those teams were people happening to work on the same problem, some were 'real' teams. So, when is a group actually a team? To me, a real team is not just people working on the same problem, but people having a common goal and collaborating closely. The common goal is the overall problem we are trying to solve. We don't develop software to satisfy our desire for shiny tech stuff - well, not only, at least. We try to make life easier for our customers and users. Collaborating closely means working with others, not only near others. Over time I have identified several characteristics I deem necessary for great teams. Autonomous The best teams I have worked in were autonomous to a certain degree. Sure, some teams have very wide boundaries and can choose many things from the languages, libraries and tools they use to what problems they want to work on. Others have more restrictions. While working as part of a team, one important thing to me was always to have clear boundaries that I know of and understand. Then I wanted to be free to decide inside those boundaries. This way I was able to feel lots of autonomy even in environments that were very regulated. I think software developers need autonomy as a pre-condition to be creative in their finding of solutions, which brings us to... Creative "We have always done it like that." This is one of the sentences I dread most. It strips me of all the creativity I have. Although we may have always done things like that - this doesn't mean we can't improve by trying something different. Therefore I think that creativity - the intrinsic drive to find new (and better) solutions to existing problems - is key for software development. Technology and user needs change so quickly that yesterday's solutions often aren't fit for today's challenges. Creativity is an individual trait that can radiate into and stimulate a team. In my experience, creative teams are also... Curious I am a very curious person. I can't count the side projects I have started because I was interested in learning something new - a new technology, a new problem domain, a new way of thinking. Like creativity, curiosity is an individual trait. Curious people ask lots of questions. Those questions help finding out about the root cause of a problem. They also enable us to create more information about a specific context in which our solution might be applied. This helps prevent solutions that are clunky at best, and unfit for the problem at worst. Now that we have talked about individual traits that help a Development Team become the best it can, there are a few team characteristics. Great teams are... Diverse Let's look back at the stereotype that I started this post with. First of all, I think (hope) it is hard to find a team of people embodying this cliché. At least those teams that I like to remember for the fun and effectiveness we were able to have, were different. They consisted of very different people. People of different gender, race, beliefs, age, etc. This diversity made it possible to create a bigger context of experiences and knowledge. We have been brought up differently, lived differently and were able to work as a team nonetheless. Diversity induces tolerance. Diversity as described here is one side of the coin. Great teams I have worked in were also... Cross-functional Diversity for me describes who someone is. When I talk about cross-functionality, I talk about what someone knows and is able to do - the type of expertise someone has. In the complex environment of software development there are many different special types of knowledge that we need in order to solve a problem. From the business or problem domain via different parts of technology, systems and their dependencies to running, monitoring and maintaining the solution. One person can't have all this knowledge in the depth needed. Therefore we need individuals who are experts in one or more of those domains and who are... Generous Sharing knowledge and experience is key for a cross-functional team. It helps individuals to grow and the whole team to improve. Software development is not a zero-sum game. This means that the benefit of one part of the system has to come with a loss for another part. The more individuals share, the more the team members and the overall team improves. A colleague who benefits from my knowledge and experience doesn't take anything away from me, on the contrary: by sharing with and learning from each other we all benefit. How to get there? While those traits are beneficial for the individual team member, they are also very much improving the overall team and its performance. In my experience the cost of trying to continuously improve a team in those and other aspects is more than outweighed by the long-time benefits the team and the company gain. The question now is how can you create and grow a team with those characteristics? To be honest, I don't know. I don't even think there is a single recipe for creating great teams. What I have experienced in the past is that I can work with my teammates and colleagues, discuss where we are at the moment (and celebrate our successes so far) and what we can do to further improve. Some concrete things that I have seen work in the teams I worked with were: Sharing knowledge within teams: brown bag lunches, tech talks, pair / mob programming Invite management to explicitly define the boundaries the team has to respect in their self-organisation and periodically review them, e.g. as part of a Retrospective When stuck with a problem, doing something completely different in order to get new insights and fresh ideas Trying to learn more about the business domains - maybe collaborating with a business user of your system for a few hours or days will help you understand what they are really struggling with Inviting other teams or colleagues not directly working with the system we create to reviews and ask for their feedback; sometimes just explaining what we have tried to do to someone unrelated helps create a better picture This list is by far not complete. These are just some very few examples of things I did in the past. I always enjoy meeting other software developers, discuss teamwork and exchange experiences. I think peer consulting is a great way to improve. It is not about finding the best way of working as a team. To me it is more about finding out what others do and how this might be applicable to my own situation. What is your experience? So what is your experience? What characteristics do you see that make up great teams? How to you (self-)improve in your teams? Do you disagree? I am curious about your comments. If you are a Scrum Master how do you or could you help your team improve in those aspects?

Scrum and Kanban are a great combination. With this insight more and more Scrum Teams become aware of terms and phrases used in Kanban. Like 'WIP'.

Simon Sinek in his book „Start With Why“ talks about the importance of knowing why we are doing things before we think about what and how to do it. I think it is a good idea for Scrum Teams also to start with why for their product development. An important point for Simon is „people don’t buy what you do, but why you do it“. Another key idea in the book is the „Golden Circle“ (s. figure below), which in fact is three circles contained in each other that define: What you are doing How you are doing it Why you are doing it Many people know exactly what they are doing and how, but often the why is not clear enough. I see a parallel to the development of complex products with Scrum. Many teams I have worked with knew fairly well what they wanted to build – the features and functions of their systems. Some of them also knew how they would implement these features and how this might help their customers or users. But too few of them knew why they built that product in the first place. That’s why I try to stress the importance of the Product Vision in my trainings and coachings. It is the answer to the question of why this product is being developed. I would like to borrow Simon’s metaphor from above and call it the „Golden Product Circle“. Without a really good reason to build the product, and a purpose to the product, it doesn’t really make sense to build it. So development starts with why, the Product Vision. Then Product Owner can think about how this purpose might be fulfilled, the functions and features of the product in the Product Backlog. The Development Team then has to build the product and decide on the what to do to deliver the how. They might decompose the Product Backlog into Tasks if it helps them. But everything can be referred back to the next higher level. When stuck with the what, the Development Team can look back at the how. If Product Owner has doubts around a how she can look back at the why and try to figure out if this specific how adds to reaching the why Since „people don’t buy what you do, but why you do it“, please Start With Why for your product development with Scrum.

The PSD training teaches the whole Scrum Team on how to do real Scrum. They work in Sprints, create Done software and use the appropriate tools and practices for it. It is a unique experience on how really good Scrum feels like.

My name is Peter Götz. I am an experienced software engineer. I started in 2001 and have worked in several projects and with several teams since then. Besides actually developing software I have also prepared and conducted several technical trainings (Java, JBoss, OOAD) for developers. For more than eight years now I have been active in Scrum projects. My journey in Scrum has been an exciting one. My Early Years My journey in Scrum started in 2007 when I joined a distributed Scrum Team as a Java developer. I immediately loved the transparency and direct contact with everybody on the team who was involved in creating the system. Fascinated by this aspect I took a special interest in what our Scrum Master did and - after some time and projects - I myself became Scrum Master for a small Scrum Team. I read the books and blogs ‘you should read’, I discussed my issues and solutions with fellow Scrum Masters and I felt I was improving in my new role over time. But I have never forgotten my roots and was as near to the Development Team as I could get. Finally, in 2011, I applied to become a Professional Scrum Trainer for the Professional Scrum Developer Training at scrum.org. I met the preliminary requirements, my application was approved and after I attended a Train the Trainer course for the PSD I got my license by the end of 2012. I then took on a project to support an Indian Development Team for an insurance company as a Scrum Master. I had never worked with colleagues from outside of Europe and was skeptical, although very interested in how we could make Scrum work in that context. The Product Owner was in Germany as well as the major stakeholders and myself as Scrum Master ('technical lead' in the wording of my customer). When I joined the project, it had already been going on for about a year and the German part of the team had started recently expressing their difficulty in overcoming the language and cultural barrier. Furthermore, the impression had taken root that the Indian colleagues were not able to make proper technical and design-related decisions and had to be told each and every step. It explains why in my first briefing the project manager told me I had been selected not only for my experience with Scrum, but also because I knew the technical background (Java EE) of the project. In their opinion I was a perfect fit for being able to also steer the Development Team in India! During the first months in the project I was able to support the rest of the German Scrum Team with my experience. The Indian colleagues indeed seemed to need a lot of guidance on how to solve problems, which decisions to take and how to implement them. Most of the time I was discussing the WHAT with our Product Owner, figuring out the HOW by myself and then informing the Development Team to implement it. I would review the actual implementation and - if everything was fine - we would push the functionality to our Product Owner for further inspection and sign-off. This happened on top of my other Scrum Master duties like organizing and facilitating meetings. The project really was a full time job, and probably even more. However, I also gained lots of experience and liked the work. A Turning Point In 2013 I decided to extend my trainer license with scrum.org with the Professional Scrum Master course. In the meantime I had several years of experience with Scrum in the roles of Developer and Scrum Master, had worked in several different projects and had even gained in-depth experience with a distributed Scrum in an Off-Shoring scenario. What could go wrong, right? So I applied, I met a number of preliminary requirements and got a ‘go’ to proceed. All I needed to do was sit a Train the Trainer course with Gunther Verheyen, the director of the professional series at scrum.org and finish the PSM II assessment with more than 95%. A piece of cake! I took the PSM course with Gunther in November 2013 in Brussels and this is where my self-perception as a Scrum Master changed - heavily. The course was great, Gunther made everything seem so obvious and easy and my fellow trainer candidates gave much valuable input to me. But what really shook me was when, in day two of the course, Gunther checked why I was being so pushy and directive as a Scrum Master. He asked me if this was how I thought a Scrum Master should be and if a person like that would be able to optimally support the Scrum Team’s self-organization. I was a bit puzzled, because - after all - my implementations with Scrum had been quite successful. On my way back to Munich and in the following weeks I thought about this, re-read my books and blogs and realized that I was not being a Scrum Master, but a technical lead indeed. I was not helping the Development Team in finding their own way, I was guiding them on my way instead. And that was why they were not taking on responsibility themselves, but instead were doing what they were told: Command and Control! The Future Rewritten By the beginning of 2014 I decided to change my approach, radically. I had visited the Agile Coaching Stance training by the Agile Coaching Institute the year before and had learned the basics of being a coach - active listening, powerful questions, letting the coachees figure out the solutions by themselves. Additionally, inspired by the PSM class I attended this is what I started doing, without hesitation and leaving no room for doubt: I told my Development Team that I had misused my role and that I wanted them to be more self-directing. I honestly added that this would mean more responsibility for them, but also more freedom of decisions, more interesting work than just implementing what someone else said and even the ownership of success (and failure). In meetings I did not proxy the communication between Product Owner and Development Team anymore. It resulted in awkward silences and much avoidance of eye-contact. It was difficult but I refrained. And ultimately they did start discussing the WHAT and HOW among themselves. When pushed by my customer to ‘lead’ the Development Team more stringently to reach our (management’s) goals, I explained why I thought I shouldn’t do it. Much to my surprise most of the management seemed to really understand my point: the power of self-organization. The others wanted to be lied to, which is what I did in the past. At first slowly, but then with increasing momentum, the Development Team took on responsibility - they challenged decisions I had made before, they discussed the contents of the Product Backlog to understand the business needs behind it with the Product Owner, they debated amongst themselves on how to best implement a feature and how to refactor the existing code base in order to improve the overall system. They did not wait for me to point out Sonar violations (on source code quality) but just fixed them as they appeared, spontaneously and autonomously. After only three months I was merely facilitating the meetings and making sure that Scrum was understood and implemented properly. But that was only the beginning. The real change was soon to start. The Development Team in India asked if they could also select and provide the Scrum Master themselves. Since the majority of the Scrum Team was located in India, they preferred the Scrum Master to be there as well in order to have the support and facilitation on their side. The management in Germany agreed (of course, the main reason for Off-Shoring being cost-reduction) and suddenly I was out of business. It was my best moment in the whole project! I am still in contact with some of the developers privately and am pleased to hear they are still making progress. Of course there are difficulties, but all in all everybody in the Development Team plus the Scrum Master really enjoy their work. I resigned from my employer, went for self-employment and seized the opportunity to move to other projects. I am currently working as a part-time developer for one team and part-time Scrum Coach in a Scrum transformation for another. In the meantime I have met the preconditions to expand my license to PSM and will start teaching PSM classes in the beginning of next year. The simple observation by Gunther in that class in November 2013 triggered the biggest change in my professional career so far although it came as a total surprise. I am really curious what the next Big Bang will be for me.