Interview with Ralph Jocham – Scaling Scrum, the Swiss Postal Services case

Interview with Ralph Jocham – Scaling Scrum, the Swiss Postal Services case

I met Ralph in one of our meetups, where he presented Scrum. He is one of the best trainers I know, with expert knowledge on anything Agile. This September at Agile Greece Summit we will have the chance to hear him speak about: “10 Months, 7 Teams, 18 Apps – Scaled Scrum at Swiss Postal Services“. Here is his small interview. Q: Could you briefly introduce yourself? I started my career with ISO GmbH 1997 in Germany where I worked as a programming consultant for START in Frankurt and Siemens Medizintechnik in Erlangen. In 1998 I joined Oracle Corp. in Reading, United Kingdom working on JDeveloper. Two years later I moved to the USA and consulted in downtown Manhattan for Spherion Technologies. I later relocated to Silicon Valley to help Applied Biosystems (now Thermo Fischer, before Life), a leading biotech life science company to transition to Agile. Early in 2007 I joined ThoughtWorks in San Francicso, a worldwide leading agile consulting company as an agile coach. During my time at ThoughtWorks his clients included, The Gap, Inveneo, LinkedIn, Google and Roche Pharmaceuticals. In late 2009, I moved to Bern, Switzerland and joined Zühlke Engineering to help kickstart their agile offerings. In 2011 I founded Effective Agile[1] to walk my own talk – to see if my ideas will work. I am a lecturer at the University of Applied Sciences in Bern, where I teach an agile living case in the medical technology department. This autumn I will start teaching introduction to software engineering at the University of Applied Sciences FHNW Q: What will your talk be about, exactly? Why this topic?...
Interview with Gunther Verheyen – Scaled Professional Scrum

Interview with Gunther Verheyen – Scaled Professional Scrum

We are very happy to hosting Gunther Verheyen from Scrum.org. Gunther will talk about Scaling Scrum, “Scaled Professional Scrum, it takes two to scale“. Gunther partners with Ken Schwaber and directs the Professional series at Scrum.org. He represents Ken and Scrum.org in Europe. He is creative with the right touch of anarchy. It helps to transcend mediocrity and strive for excellence. Gunther is author of the highly acclaimed book Scrum – A Pocket Guide (A Smart Travel Companion). Here is his small interview. Q: Could you briefly introduce yourself? Hi, I’m Gunther Verheyen, a seasoned Scrum professional. I partner with Ken Schwaber, specifically targetting Europe, and shepherd the Professional series at Scrum.org. Q: What will your talk be about, exactly? Why this topic? I will introduce “Scaled Professional Scrum (SPS)“, the framework by Scrum.org that describes how to implement Scrum at scale. At the heart of SPS is the Nexus, an exo-skeleton that connects 3-9 Scrum Teams creating one product. Q: What do you think could be the main gain for participants in your session? Participants will learn how to scale product development through Scrum, while respecting and even re-enforcing the principles and foundations of Scrum. Q: Can you give some advice to teams/organizations that are transitioning to agile? In my session, I start by defining Scaled Scrum as any implementation of Scrum that employs multiple Scrum Teams creating one or multiple (related) products. The organization surrounding such scaled implementation of Scrum is bound to be impacted by this. Scrum’s principles and empiricism can be employed to lead such change, as defined by Scrum.org in the “Agility Path” framework, but it is...
Team Awesomeness

Team Awesomeness

Team Awesomeness, a great way for Scrum Masters and Agile Coaches to facilitate group dynamics and team’s awesomeness. A common goal for our teams at King is to strive to be a high-performance team that communicates and collaborates well both within and outside the team. In that spirit, we are testing a concept that I call “Team Awesomeness”. Generally, it’s a lightweight questionnaire, which the team answers together as an extension to the retrospective. The team fills out a questionnaire with 25 questions divided in five different areas: contribution to King, contribution to the team, innovation, communication, and quality. The team members read each question out loud and then do “fist of five” voting. Those members with the highest and lowest votes should explain their choice. The whole team listens and discusses, then votes again, as in planning poker. The team tries to reach a consensus on a score, makes notes, and then moves to the next question. After going through all the questions, the team should clearly see in which areas it needs to improve. The first Team Awesomeness exercise takes approximately two hours. The exercise offers good input for an improvement theme (see picture). The team can also easily measure progress. Make sure the results are transparent for the whole team, and put the score on your Scrum/kanban board. We don’t tell a team which methods or processes it needs to put in place to strengthen its weak areas; if a team, for example, finds that they need to improve quality, the company doesn’t tell them to fix more bugs or start with TDD. The team must find a solution...
O Ελληνικός Οδηγός του Scrum (a.k.a The Scrum Guide in Greek)

O Ελληνικός Οδηγός του Scrum (a.k.a The Scrum Guide in Greek)

Με μεγάλη χαρά, ανακοινώνουμε ότι δημοσιεύθηκε ο Ελληνικός Oδηγός του Scrum στο Scrum Guides. Ο οδηγός αυτός, γραμμένος από τους Ken Schwaber and Jeff Sutherland, συν-δημιουργούς του Scrum, αποτελεί τη “Βίβλο” του Scrum. Είμαστε ιδιαίτερα περήφανοι για τα μέλη της ομάδας του Agile Greece, τα οποία μετά από πολλή προσπάθεια κατάφεραν να ολοκληρώσουν την ελληνική μετάφραση και να την προσφέρουν στην κοινότητα του Agile στην Ελλάδα. Today, we are happy to announce that Scrum Guides has published the Scrum Guide translated in Greek. The Scrum Guide is the official Scrum Body of Knowledge. It was written by Ken Schwaber and Jeff Sutherland, co-creators of Scrum. We are really proud for the members of our team that, with their hard work, managed to complete the guide’s translation in greek and share their work with our community. Πολλά συγχαρητήρια και ευχαριστώ στους (Special thanks to): Dimitris Dimitrelos Twitter / Linkedin Yorgos Saslis Twitter / Linkedin Byron Georgantopoulos Twitter / Linkedin Vagelis Antoniadis Twitter / Linkedin Nikos Batsios Twitter / Linkedin Yiannis Mavraganis Twitter / Linkedin Giorgos Psistakis Twitter / Linkedin And to Petros Athanasopoulos (Twitter / Linkedin) for initiating the whole project one year ago....
Using Scrum for Fixed Price Contracts

Using Scrum for Fixed Price Contracts

The first question I usually get when teaching or preaching Scrum is “Sounds nice, but you surely can’t use on a Fixed Cost/Price contract, can you?” Well, let’s see. Note: for this article’s context we will assume that your company is implementing IT projects for external customers.   The problem with contracts The problem with contracts is that: You have to keep them, and You can’t change them Why not? Because contract change usually requires escalation to top management and involves a lot of people not directly related to the project implementation, like Sales & maybe Legal (your side) and Procurement and maybe Legal (customer side).   The problem with Fixed Price contracts A Fixed Price/Cost contract is created to legally bind a supplier with a customer, fully defining all three basic project aspects: Cost, Time, and Scope. The problem with this type of contract is that it assumes full predictability on all three aspects, something that is, in all but the simplest projects, not realistic. The reason Fixed Price contracts are the norm is that Customers prefer them, falsely believing that they transfer the risk to the supplier (i.e. if the project proves to be twice more difficult than originally expected, it’s the Supplier’s problem –or so they think).   Is it really Fixed? So, a Fixed Price Contract has a Fixed Price, a Fixed delivery deadline, and a fixed scope, right? NO. Let me explain: As contracts are usually signed well before the project has really started, the scope is not, can not be adequately broken down, analysed and clearly defined. What is usually included as “Scope”...