SCRUM in Times of Lockdown #3
First major snags and the wonders of people being people
I have a confession to make, by now we are tired, all of us. So very tired. We all believe in this project, and we all want to bring our best to the table. But the fact is these last three weeks have taken a toll. We’re three days into our first sprint, and we finally find ourselves with a “regular” workload.
For those of you familiar to Scrum, you know there’s a recommendation to building your team with the people that have all the skills you need for your project. And in larger organizations, this might not be that hard to do. In small ones, however, outsourcing some talents is inevitable. In our case, we needed someone to help us with the UX/CX and reached out to a partner company for their services. The immediate consequence of this was the need for the integration of two new team members, coming from a different work culture and with different methodologies. By the time they started working with us and entered their preparation stage, we were starting our first sprint. And, to top things just right, they had different work hours.
Up to a point, we were lucky. The UX/CX company works with an Agile philosophy too, with Kanban as their framework, so there was plenty of room to adjust. And these were perfectly nice and amicable people, so it should have been easy to “bring them into the fold”, so to speak. There was a stated intention of treating them as full fledge members of the team, keeping Scrum as functional as possible in this context.
It wasn’t that easy. Our team had integrated quite well at this point and had developed a very quick response culture, making decisions and providing solutions fast, to things like technological solutions and integration of different tools. In our first meeting, as soon as the new elements referred what tools they would be using, our main techie integrated them with our platform and announced as much to all participants. Which was clearly too fast of a move for the new people coming in and prompted a “Whoa, slow down!” reaction on their part.
These are people with their own considerable experience in remote work. And they offered valuable advice based on such. But the original team had integrated extremely well and had found their own rhythm and their own ways of doing things and addressing problems. Moreover, there was an immense sense of pride of having been able to turn the whole project remote and still consider it a success. Now what? Two immediate consequences: the original team developed some resistance to the incoming inputs. Which lead to number two, the immediate tendency to isolate themselves as a group. The ground was laid for a “Us and Them” view of the work team, the very thing we didn’t want to happen.
I was a very unhappy Scrum Master at this point. We still had a lot of information to pass on to the UX/CX members, the goal was to provide them with the same information and learning materials we had provided the original team. And they in turn had a lot of information to pass on to us, about what they were going to do and how. Our interaction would be frequent and long, in the upcoming week. How was I going to stop this discomfort from evolving too much, too quickly? With no time or context to mediate anything, with no real way (or justification, for that matter) to even raise the subject with the new members?
In the end, I just ended up talking to the team candidly and openly. We had set our company values on acceptance, tolerance and open mindedness for all stakeholders an collaborators. We had done so collectively and by consensus. It was time to put into practice what we developed in theory. It was time to wilfully let go of any ill feelings and work together in the same welcoming spirit we had set out to have. In the end, my main argument was people will always be people, no matter how different they speak or work. We don’t know where they are coming from, we have never walked in their shoes, we might as well be open to accept some things that will feel strange, alien or even inadequate to us. There’s probably a lot of the same happening on the other side. Things seemed to get better after that, but only time will tell if this is a problem solved or a problem dormant.
This was also the week we looked at the user stories in the Product Backlog and gave them story points. There was a lot of knowledge to be gained from this process. First, given the chance, we will discuss things ad eternum. It was something we already knew we had a talent for, but it became blatantly obvious in the grooming.
Second, the most difficult and complex part of story points use is the determination of an initial baseline. We took three stories (the first three in the Product Backlog) and gave them a relative story point value, in an ad-hoc fashion. We were not trying to reinvent the wheel, far from it. We used the Fibonacci sequence as our scale. Consensus was a hard thing to meet.
Third, we had managed to create a team where everybody felt confidant and safe to voice their opinions, no matter how deviated from the majority they were. Fourth, everybody walked away with a much more systemic and encompassing vision of the work to be done. After this initial step, things became much easier, as we used Planning Poker to score the following items. We came out with a good starting point to create our first Sprint Backlog.
Although we hadn’t been really sprinting yet, and since we had been working together in this fashion for about three weeks, I thought it useful to have a Retrospective before planning our first sprint. There was a need to find out how individual team members were coping with our rhythm, our workload and our working hours. And, coming full circle, that’s how we discovered we were all so very tired. Not because we were working too many hours, we were doing a good job of keeping it contained, but because we were spending too much time connected, too much time discussing or learning or both, and we were not pausing as much as we needed to. There were kids to attend too, also, in some cases very small children, that needed attention and weren’t really keeping to timetables. And we came out of our retro with a couple of things in mind.
First, although we should be available for the team during work hours, having a continuous skype call on air proved to be more damaging than beneficial. Second, we should all strive to combat the temptation of never leaving our desk and our computers, pauses HAD to happen. Third, there should be some leeway for extending working hours in the cases where interrupting a train of thought would be more detrimental than to just keep working (coders pushed for this one, naturally). Fourth, there was a strong commitment to speak up and raise flags whenever someone felt overwhelmed. Had we been working in an office, we’d be seeing people get tired and overrun. It would be easy to determine for ourselves that someone needed some space or some peace and quiet. Here, we had to rely on the ability of people to let us know.
Where do we go from here? As we prepare ourselves for our first two weeks of true Scrum work, bumps are expected, and adjustments will happen probably on an almost daily basis. Keep tuned in for the rest of the ride…
