Kate Hobler

Agility is not a state. Agility is an ability to change and respond to an environment you're in as an organization.  Once you realize that a binary Scrum-not Scrum stops making much sense.

Many organizations I have seen in my life does not care for their Development Team. Join me in a short analysis of why that happens and what - in fact - is a Development Team.

Commitment is key. Commitment is somethins every team, every manager, every organization wants and needs. Commitment promises better results, engaged people, good relationship with work and many other benefits. The problem is that it can be misunderstood. 

The Spotify "model" pops up as either advocated practice (especially by large consulting companies) or some sort of a hoax and hated practice. I wrote this text few years back, but it appears to be valid more than ever. Join me in discovering 10 lessons from my "spotify" encounters.

Dark, small, crowded room in a corporate office. All windows shut closed with worldproof blinds. The only source of light is a projector splitting the room in two uneven halves. 7 people around the table struggle to keep their eyes open, even though 6 of them have coffee mugs full of the ever-awake potion. One man with blind stare types something on the keyboard. One sits to the back and observes from under half-shut eyelids. Someone looks at the phone to read the time: 10:12 - still 108 minutes to go ... Sounds familiar? In one of the companies over 10 years ago we called them Coffee Plannings that later became Coffin Plannings. An excruciatingly boring and time-wasting activity, where the whole team sits in one room, looking at one screen trying to plan a two-week Sprint. Usually only two people are engaged, the rest is asleep. We tried battling it using Core Protocols (BTW, a great set of tools). Later on we tried working on dynamics by introducing gadgets - balloons, crayons etc. It worked a little. We were stuck in believing that a team is a team and it has to work TOGHETHER! This is one of the most common Scrum misconceptions. Scrum does not allow sub-teams, that means everything has to be done together. That's why we plan together, refine Product Backlog together, review work toghether, achieve goals together. Everyone at once. Of course I'm not advocating creating sturdy sub-teams. Working together in pairs or bigger groups (even the whole team at once using swarming) allows for knowledge diffusion and collective learning. So those sub-groups should be flexible and interchanging as much as possible. Too much division can be as bad as too big group working together - it will stop team from forming and learning and it is a common problem. I am advocating time-restrained sub-group working to maximize output and minimize time invested. If we look at software development, the most effective way of using your team time is not one person coding, and others looking and commenting. The most effective teams work in pairs or small groups, sometimes individually and INTEGRATE their work OFTEN - even every few minutes. Same applies to planning. How can I integrate planning often? I know three ways - all of them reduce planning time by at least half the time: Central board - you can have a central planning board, where all Product Backlog Items are placed. When a sub-group takes one to work on it, nobody else can, so work is not duplicated. After it has been planned, the item is returned to the board, arranged accordingly and another one is taken to be planned. Iterative integration - you integrate your work every (for example) 15 minutes. You organize what you have done until now, and proceed planning in sub-groups for another 15 minutes. 1-2-4-all - divide work to be planned among everybody individually. Then plan individually. Merge people into pairs and merge their work. Then merge pairs into fours and finally merge everybody's work. Do you know any others? Share them in the comments below! You can also join me and other PSTs - Peter Gfader, David Sabine and Joshua Partogi on a tag-me discussion on Linkedin [link]. You also can be tagged to provide your opinion on the next #daretochange - just let me know!

If you were in my class, you probably remember the exercise, where participants list roles, artifacts and events in Scrum.

Recently I came across a post by Mike Cohn “Incentives and Deterrents for Starting Daily Scrum on Time”, on Linkedin (originally posted here:). I read it once, then once again, since I thought I misunderstood the overall message. But looks like I read it right. I know many teams that use some sort of technique to make sure they are on time for Daily Scrum. As a very young Scrum Master I also thought - this is going to bring results! Let’s pay or sing or tell a joke, or bing chocolate. It’s a nice thing to do, to have a laugh. Does it work? No. Just like any carrot and stick. It might work once or twice. I once promised a team to bake them a cake if they achieve their Sprint Goal. They did it. And never again. Shavaun Tesareski wisely commented under Mike’s post: “If you have a team member who is so inconsiderate that they don't consider their impact on their team mates, that's a much bigger problem and team meeting start times would be the least of my worries!” So let’s get down to the root of the problem. What’s wrong? What I usually see is the misuse of Daily Scrum. There is no Spint Goal, no work is being Done. People don’t see the need in daily planning. Or it’s just a group confession exercise. I’m not surprised that people fail to come on time if they only exchange information. And what’s scary is that many people treat the Daily Scrum as an information exchange. So the first step a Scrum Master can take is to make sure they really get what the Daily Scrum is for. Let’s take a closer look at some techniques Mike stresses as being efficient as reported by his readers: “Isaias Fritsch took that type of approach by preparing a 30-minute presentation for the team on the importance of the daily scrum. He said that after that presentation, the team decided to come up with some changes to their daily scrum approach. The result of this has been that “the daily scrum is now way more interesting to everyone because relevant information is shared and everyone understands its importance/why we are doing it.” Let’s see - the basis, the need of Daily Scrum was straightened. No carrot or stick. “Start the meeting 15 minutes before everyone wants to go to lunch. Viktor Buzga reports that the company cafeteria in his company gets very crowded at 11:30 when it opens. Arrive at 11:30 and there’s no wait for lunch. Arrive two minutes later and there’s a 10-minute wait. So he starts daily scrums at 11:15. If the team finishes in 10-12 minutes, they’re perfectly timed for lunch. If not …” This method taps into our brain’s autopilot - the habit forming. You set up a meeting around a trigger (lunch, morning coffee, the sandwich guy). It’s not really a carrot or stick thing. But it might be. Watch out if the Daily Scrum just shortens - then you know that the purpose is misunderstood or not taken into account and you have a bigger fish to fry. “Have a “tardy board” as Nadine Sullivan called it that tracks late arrivals or absences. Add rules like everyone is allowed one late arrival during some period. But after reaching some number of late arrivals or absences, the person has to bring something in such as a snack for the team.” This technique is based in transparency. Let’s see how much are we late? Is it a significant number? Being transparent is one of the best things a Scrum Master can facilitate. He is responsible for it after all :). I would omit the snack part and check if it’s still working. I’m sure it will. As Linda Raiseng once quoted “there’s not a problem in existence that the cake won’t solve.” What’s scary? Now let’s take a look at some scary tips lurking in the article: “In fact, Rob Dull pointed out an underlying benefit to using a deterrent, saying, “It's sooo healthy for people to be able to be silly/awkward in front of their teammates.” I agree with this fact. But what happens if this silliness is a form of punishment? Take a wild guess. “Facilitate the next review or retrospective.” A deterrent? This is supposed to be a form of punishment? Using that deterrent I wouldn’t be surprised if your teams pushed it on Scrum Masters exclusively without taking responsibility for facilitating their own meetings. “Take detailed, precise notes for the meeting” What for? The Daily Scrum? For other meetings - do we need them? Doing things with no purpose only kills passion. Do we really want to start with the Daily Scrum? Eyes wide open I refuse to believe that Mike has problems understanding the purpose of the Daily Scrum or how to act if it’s off. Apparently the best of the best can get influenced by some information noise as well as anybody else. Let’s have our eyes wide open for situations like these - explore what works in long term and apply it according to your professional knowledge.

Before I begin, I have to make sure you’re not fixed on a misconception. The Daily Scrum is not a status meeting, nor a report back to the team. It’s a planning event. You can read some more here: [What is The Daily Scrum for?] Years back, in the beginning of my adventures with Scrum, I worked with a remarkable organization. They produced very complex software for hardware resting. They were able to emulate elements of a complex network for the purposes of testing, and supplied simulators and testing environments for over 30 independent devices and another dozens for their versions. The organization struggled with quality due to such a complex system. Even though all simulators acted as services, they were not completely independent. Teams struggled with common protocols, hardware upgrades, shared libraries and dozens of dependent remotely-called procedures. On top of that, some simulators used exotic languages, uncommon technologies and internal scripts that barely anybody understood. Let me tell you a story of four teams working in this environment. Let’s call them Spring, Summer, Autumn and Winter. These names also greatly illustrate those team’s tempers. I worked with Autumn and Summer. One day, Marek, one of the smartest people I know, brought a requirement from a demanding customer. They needed a completely new device simulated. A new technology had been developed by our competition, and these devices were starting to appear on networks. Other impediments, such as language barriers weren’t helping either. The requirement was also very time-sensitive, as the market expected them supported in few months. Development teams were currently working on physical devices, so that had to be manually tested. Simulation was crucial. To make it happen faster we needed four teams of 7-9 great analytical minds who would be able to break a new device apart, see how exactly it worked (it was partially a black box) and emulate it for a testing environment. It wasn’t a piece of cake. And still it was dependent on the core of the product – independently developed by another three teams. Out of those people some were sought after specialists, so their work would have been dependent on other tasks they would have to provide. No others were available. Imagine the number of dependencies in this environment. Starting with hardware elements, going through knowledge, simply technological core, availability, abilities, of team members, the Product Backlog and many, many others. So we started working. We decided to start using the practice known from scaled environments – the Scrum of Scrums. And we tiered it. Firstly we did our simple Daily Scrum. Then we did the simulator Scrum of Scrums. In the end, the block was crowned with an organization-wide three element Scrum of Scrums. I particularly remember one of them. Daily Scrum - And how is the hard protocol part going? - Don’t even remind me of this. It’s a f*cking mess. I can’t get to terms with any of the protocol guys. - Did you try talking to Simon? - Of course I did, but there is a decision involved on the product level. So our PO number 7 has to make it. - Does he know about it? - I hope. I wasn’t able to locate him all week. He must have been off or something. But he’s here. - So, should we go chase him down after the SoS? - Sure, tag along. The more the merrier. I will also take the representation duty since I have the problem. - Small Scrum of Scrums - And our team has problems with the hard protocol part. - Um, wasn’t that supposed to be postponed until the next sprint? Core teams aren’t ready yet, I heard - Postponed? That’s a first time I’m hearing that. Where did you hear that? - PO number 5 told me. - Isn’t he supposed to care of the Core teams? - Yes, but you know him. - S*it, I have to visit a couple of people then. - We both have to go to the big SoS. A quick getting back to the team before the big SoS - You wouldn’t believe what I just heard. Number 5 postponed the feature. Ana, can you come with me to the big SoS? Looks like we have some impasse. - Wait – said Angel – isn’t five supposed to care for the core? - That’s what I said, but apparently not. - I’m coming with you. - Big Scrum of Scrums - And one more big thing. We have some problems with the hard protocol part. - It’s almost done on our side – said someone from the core. - Wait … - said the guy from the remaining so-called Small Fly teams –didn’t PO number 8 erase that one? - Say what? Erased by the customer specialist, postponed by the Core PO, unknown by the rest of the crew. What’s up with this feature? Can we get all our POs here before this blows up in our faces? We know that protocols are the most important now. So what’s happening? We managed to gather all present POs (9 out of 12) - Alright, so what’s up with protocols feature? - It’s postponed. Don’t you know? - said number 2 - No, it’s not anymore – said 7 – I didn’t make that decision. I only thought of it. - Really? – said 8 – but I cancelled it last week. It was supposed to be realized by the external plugin we’ve just bought. - No, that plugin is for something completely different – said Marek. It can’t help us. - But that’s what the Core team told me! - They couldn’t have. It’s not possible to do this with this plugin. Let’s get someone from Core to here. Few minutes later - Tom, why did you claim this can be done with this plugin? - What? I said it CANNOT be done with this plugin. Don’t you get sarcasm? - Seriously? All this because of one sarcastic comment? - That’s what you get for acting with 12 POs… And this is what we attributed everything to. The 12 POs. Since we could do nothing about it, we just accepted the status quo. Did you encounter a situation like this? If you did, remember what happened. And now imagine how it would look like if we STARTED with the big Scrum of Scrums. And pulled work and dependencies as we go along into our teams. In this particular situation, it would save us hours of our time. And situations like this happened every few days. Had we planned top-down we wouldn’t have wasted few hours every several days just to make a decision, and then go back to the SoS group with the decision and back. That is EXACTLY WHY this pattern has been incorporated into the Nexus Framework as a recommended way of doing the Nexus Daily Scrum. Try it. You’ll like it. And it will save you lots of time and money. :)

History In 2012 in one of my Professional Scrum Master classes I met a true gentleman. Much older than the average IT specialist in Poland, jeans and button-up shirt, amazing manners, spotless language and a perfectly kept medium-length black beard with shining strings of white. The kind of a person that is impossible to forget. He was very calm and quiet throughout the whole PSM course, even though his knowledge and experience shone through. He took part in all the exercises and contributed, but something seemed on his mind all the time.
 Finally during our walk to the lunch restaurant we were able to talk freely. - “What’s on your mind?” – I said – “You seem a little absent. Is there something I can do for you?” - “Well … you already did …” - he said. I still felt that something was off. - “Um … could you elaborate a little? It looks like something is bothering you.” - “Not really bothering. More like taking half of my mind’s processing power.” Here’s what he told me: “Twenty years ago, when I started working in IT in some far far away place, I was working with this amazing team. They were all experienced programmers, creating a mainframe-like system. They had worked together for years, knew each other amazingly well. I was added to this team to replace a colleague that had moved to another city. They slowly introduced me to their process. First and most important we had an expert who understood what this system was designed for. He answered all non-technical questions we might have. We planned our work on a monthly base, making sure that every month we would create some useful new functionality without breaking existing functions. We made sure each month resulted in a tangible outcome, because that made our work more predictable and easier. Since no one but us understood the solution, we had no external interference. And each month we would review the solution, improve our process and make sure we saw clearly everything vital there was to see. Does this in any way sound familiar to you?” - “Looks like Scrum …” - “Exactly.” And he continued: “But in 1992 Scrum wasn’t created yet. Up until today I thought this was just a coincidence. But much of what I heard today, in this class, made me think: Scrum wasn’t invented. It was observed. Observed at teams that succeeded in delivering a solution. And we did as well. So in a way I created Scrum. Or at least witnessed its creation by the team I was part of.” Observation This in turn made me think, as a proponent of Scrum and professional software development. Here was this team that ‘created’ Scrum not knowing it existed, not naming it as such. Their Scrum wasn’t a theoretical concept, but a way of working that emerged from daily practice. It made me reflect on what triggered or supported this ‘invention’. It convinced me that a healthy, goal-oriented team, with supporting (as opposed to commanding) management will create a Scrum-like environment. There are other re-enforcing factors (values, culture and pure humanity), but true leadership instead of control is an essential condition. I did some research on this idea with fellow coaches and we did identify this as a recurring pattern. We concluded that it is likely why the Scrum way of working resonates so well with so many teams and people; many of them, unknowingly using iterative-incremental, helped create Scrum. Smile if you were on one of them! Expansion Lately in the software development universe, ‘scaling’ is by far the topic most spoken about. A lot of different scaling approaches emerged – like SAFe, LeSS, SaS. Some have much similarities, some are very different. I have heard about some, worked with others. All implementations that I have witnessed, for me, represent a way of working that has its roots in the past. But one of them, still in the process of being created and launched, struck me. And not only by its parts and elements, how much sense it makes or how lightweight it seems, but mainly by how people reacted to it. It was at an introduction of the Nexus framework to members of the Scrum.org community of Professional Scrum experts. Nexus In April 2015 I took part in a Scaled Professional Scrum class taught by Rob Maher, where scaling was presented as suggested by Ken Schwaber. This framework was called the Nexus. From what I saw at first it was a simple, yet great fractalization of Scrum. The Nexus doesn’t change Scrum, but shows how to implement Scrum one level up, to the level of 3-9 Scrum Teams building one product. It was called an exoskeleton for Scrum. The Nexus also emerged from observed practice, not from theoretical design sessions. It gives a name to proven concepts on scaling Scrum and provides tangible practices. And, above all, it makes a lot of sense. Interested? You can read a little more here: https://www.scrum.org/Resources/Nexus Reprise I feel really good about the Nexus. I have seen similar approaches work. They were just named “Nexus”. So at an Agile Coach Camp Poland, I decided to spread the news. In the morning I put up an hourly slot in the ACCPL unconference to talk about the Nexus. Lots of people started asking for a re-run, because they wanted to attend another session. Soon, the whole room wanted to attend. So I promised to set a session for tomorrow as well. About 45 people showed up. For a 70-people event, that was quite a crowd. I started with an exercise upon the question “What is integration?”. The group was amazing in its considerations and answers, nailing down about 30 highly relevant and important aspects. Then I presented the Nexus briefly. - “Um, Kate, a short comment,” - said a man in a maroon polo shirt – “We’re already doing that and it works.” - “Yes!” – said a lady in blue – “The same here! But we didn’t know it was called Nexus!” - “Us as well!” – another voice was audible from the outer ring of chairs. And then it struck me. It took me back to my PSM class of 2012. I am witnessing how Nexus is being created. Just like Scrum has been 25 years ago. I am in between all those teams that do Scrum well at scale and understand that Nexus is what they’re doing. They all independently created the Nexus, They inspected and adapted until they reached a fractal with a Nexus Integration Team to bring them together. Some said they had a one-man army as the Nexus Integration Team, some said they had an actual full-time team. It all works, all those teams delivered a remarkable product using their own application of the Nexus, even before it was created. So they all created the Nexus a little. Smile if you are one of them! You Create Before the session ended I asked people to share their stories about Nexus and how they already have it. It looks like a few will share theirs. One is already posted, three others are being written. I will be adding them to this blog post as they come. Good luck to you all in creating Nexus. I know why this will be the next big thing. Do you? If you have a story like this, please send me a message, I’ll gladly add it below! The language doesn’t matter :) Here is one of the companies doing Nexus: https://www.linkedin.com/pulse/white-board-magic-marcin-wydrzy%C5%84ski This article is still a Work In Progress, so check it out often. It shows the whole way a company is working for people not familiar with the subject. Lots of Nexus here as well! http://it.esky.pl/how-we-work/ Update 30.07.2015 An updated presentation and an article from eSky! http://www.slideshare.net/itesky/scaling-scrum-esky?ref=http://it.esky.pl/how-we-work/ http://it.esky.pl/2015/07/27/we-have-invented-nexus/