For those of you who would like to read this article imagining David Attenborough is narrating it, I’ll start the first few paragraphs as such.
‘The plains of the large corporation are both harsh and bountiful for the newly formed scrum team, and today we will be exploring their world in a little more detail.’
‘The team, in this case, is a little older, a combination of a few foreigners and some local talent, all brought together for their particular skillsets.’
‘Their mission, as set out by some strange system of external ‘product’ themes is set out for them, and they need to work together on a daily basis to ‘make it happen’.’
Okay, back to reality, now that we have a background let’s discuss some ideas and practicalities that we as a team have had to unpack and deal with over the last year. The evidence noted here are my own observations, and no feelings were intentionally hurt in the writing of this article.
Early on in our journey our scrum master introduced and insisted on the concept of ‘Definition Of Done’, which to most of us was an interesting idea, but never had to really materialise as long as we had the current way of working in place, e.g we would dev and QA and some other team/process will deploy to staging and Prod..
While DOD is important and we all want to take stories as high up the environments as possible, we made the initial mistake of declaring our DOD as delivered to staging. This, we now know in hindsight, created a highly efficient engine. Our team worked through stories at a rapid pace, delivering them to staging and then ..
Well exactly, and then nothing. You see we had one part of the machine working in scrum mentality and the second totally removed team working in a standard ticketing system. And then there was the confidence factor.
Problem? Two very different velocities of delivering work, and two very different teams. So what do most organisations do when there is a handover or transition to a different team? We had to introduce a detailed document outlining the what, where, hows of every single story.
And suddenly we found ourselves knee-deep in process-mud. Not to mention the detailed discussions about everything around our process, our tech and our approach, all for the simple deployment of one story. Which, if we are being fair, is exactly what you want from your gatekeepers; as they were never part of our scrum process, this was the first time they were hearing of our new change.
At this point, I have to add that the opposite, and exponentially more scary, was when the opposite team didn’t ask any questions.
So with all of the above said, the team started to figure out ways around the problem. Which meant that the stories started to get take longer to develop. Why the additional effort and time? Because the team started wrapping the deployment steps up into scripts to extrapolate the process and complexity away from the deployment team.
Now we had complicated deployment scripts, on top of complicated technology, hiding complicated processes.
At this point, I want to remind you that this process-mud, is entirely the teams own making. We chose to define our Definition Of Done as staging, so we refused to look over the barriers and address the actual problems. By limiting our scope, we created our own blockers.
Back to David to help us frame the rest of the story;
‘The team is suddenly faced with the unimaginable, the processes and rules of the corporation which they have been sheltered from for so long, are finally applicable to them. They are no longer in the safety of their small scrum team, but facing the unknown and untamed wild of red tape.’
Although I frame the story as dire, it is in fact not. The processes and red tape of the system outside your scrum team are, no matter how hard you try and avoid it, part of your eco-system and should be brought into to the Definition of Done as quickly as possible.
The decision to not make the DOD all the way to production was the right decision for the newly formed team in the beginning, but every team needs to be mindful and consistently focussed on dependencies on other teams. Experience taught us to extend our DOD as often as possible and to understand these dependencies in our sprint planning sessions.
Furthermore, we adopted a DevOps model to reduce our dependencies, and although we are still working through the transition, we are starting to see a dramatic improvement in our delivery cycles.
Maybe for the next article, I’ll discuss the shortcomings and issues of DevOps, the idea of ‘everyone can do everything’ (and how using this phrase can upset people). But for now, I have work to do.