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. :)
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. :)