The Tao of SDLC
Now that Scrum, Agile, Kanban and other methodologies have become the Tao of DevOps and SDLC (Software Development Life Cycle), not a day goes by without the ubiquitous and oftentimes annoying user stories typically found in issue tracking systems such as Jira and Trello. “As an end user, I want to be able to see the website the same way in all browsers”; “As a customer of Irrelevant Inc., I want to be able to redeem my credits as Dogecoins”; the list could go on and on but I already feel my blood boiling from just writing this very sentence.
Those two examples of user stories are ludicrous in and of themselves and I could write an entire article on how sometimes we should not listen to what end users want (or think they do); instead, what I’m going to focus on today is how I, as a developer/ops person/IT staff member/whatever, would like to be treated by my non technical colleagues when it comes to Scrum and Agile.
Listen to the devs
If you’re not a tech person but is responsible for a software project, be informed that I’m not a Scrum master, product owner, Agile coach or whatnot. And that’s exactly why you should listen to me! I’m always impressed at how much Agile folks in general talk about the way SDLC should work and that “developers this, developers that”, but don’t actually talk to developers in order to understand what we think and how we like doing things.
I’ve lost count of how many times I’ve heard that “remote work goes against Agile’s philosophy yadda yadda yadda” without even being asked what I thought about the topic or what experiences I could share in regards to it. (Probably because my Agilista interlocutors already knew about my positive experiences with remote work and, due to some strange ecclesiastical precepts, didn’t want to accept practical evidence that went against their quixotic theories.) Or how many times I’ve seen Scrum masters and product owners intentionally creep themselves closer to the business side of things, as if the technical aspects of SDLC were minor and unworthy.
I have to remind those people that most, if not all, of these methodologies were spurred by people from the trenches, not the suit and ties who “focus on results” (and yachts and beach houses). If you’re a Scrum master, Agile coach etc., rest assured that distancing yourself from developers in the hope that you’re safer under the shadow of the (supposedly) big shots of your company is the fastest and most certain way of losing everyone’s respect and making your own life miserable.
I’m not saying you need to have a technical background and share the same interests and knowledge with developers and others in order to be a Scrum master, because that’s just unrealistic these days. Nevertheless, if that’s your case and you’re not technical, you’ll eventually have to address the fact that there’s a gap you need to fill. I’ll talk about this in a bit. For now, just remember that tech people are precisely the ones you want to have on your side, and that, as surprising as it sounds, is not that difficult to achieve. Here’s how.
As a developer, I want user stories to be decently written
I’m aware that user stories should be written from the perspective of end users and convey information about what the product is, not how it does it. But imagine a junior developer who gets assigned a new ticket. If the ticket doesn’t contain any technical details about the how, chances are s/he’ll unnecessarily spend a hell of a lot of time digging up information that could (and should) have been made available even before s/he was assigned the story. You can always use the story’s comments for that kind of information.
If you don’t understand the technical details, make sure you ask someone who does. And this is what I was referring to a few lines above when I talked about non technical people. Filling this gap is the main reason why more and more companies are adopting the practice of asking developers to label and compose user stories as the very first ceremony in each new sprint. The time senior developers spend on this task is guaranteed to pay off as soon as the sprint begins to take shape.
Don’t write stories without first talking to senior developers and then expect people to understand what has to be done. It will put an extra burden on those who don’t master the codebase and force them to ask direct help to those who do. This is a sure way of making recently hired developers feel frustrated and incompetent. You should want your team members to feel empowered, not depending.
As a (recently hired) developer, I want/need to do peer programming
Everyone loves well documented software. When it comes to developing new features or fixing bugs in a fast-paced sprint, though, nothing beats peer programming. If I’m new to a codebase or need to develop functionality that I’ve never worked with before, I find that chatting with someone more experienced than me is the most productive way of learning how to walk with my own feet.
The confidence and knowledge we gain by doing so is unparalleled, but that only works if the other developer is willing to teach. If that’s not the case, then you’ll probably have to work on your team’s culture—a team that doesn’t like peer programming is a team that doesn’t like sharing knowledge.
As a developer, I want not to be told what works best for me
This is the most frequent and most annoying one: being told by other people what works best for myself. As if every Scrum master and Agile coach was also a master in psychology or held a diploma in behavioral science. “I know not everyone likes it, but at the end of the day, working nine to five is the best way of getting things done.” I may have met one person in my entire life for whom this is a true statement. “Studies say that open concept offices improve communication”. Bullshit. “Statistics have it that remote workers are less motivated.” Two times bullshit. In fact, for every study and article suggesting that remote work doesn’t work, I can find at least one proving the exact opposite.1
But do you know what? Why don’t you put those papers and statistics down and just ask your team what works best for them? Better yet, ask each individual what works best for her/him. You’d be surprised at how many opinions and personal experiences are conveniently left out of those “official” studies ;)
Not doing so gives your team the impression that you’re playing the role of the Devil’s advocate, which is quite annoying, or worse, that you’re a headsman—a two faced faintheart who’d do anything to please the boss, even if that required throwing everyone else under the bus.
As a developer, I want to be able to make mistakes when estimating time
Estimating how much time we’ll spend on a ticket can be strikingly hard sometimes, especially when it involves a complex problem whose scope we’re not fully aware of. There’s a science and an art to it, but most of all, it requires a lot of experience in the field (and with the codebase). Expecting every single person to know beforehand how much time s/he’ll spend on a story is pure nonsense, yet developers are often confronted with the question “What went wrong with this story?”, as if it was all our fault.
“Nothing went wrong with the story. You asked for an estimate, which I gave you, but estimates are just what they are: estimates.” That’s my standard response, which I’ve been using for a few years now. If you’re a developer, feel free to make it yours. If you’re a Scrum master, don’t be mad at me; just be cognizant that even the weather forecast fails sometimes.
As far as my experience goes, tech people have no intrinsic problem working with Scrum masters, product owners, Agile coaches etc., so long as an atmosphere of collaboration and mutual respect is nurtured. No one likes hangmen, especially the ones who enact the tough, resolute and (allegedly) impartial archetype.
The list I’ve presented here is by no means exhaustive, but is a good starting point. If you’re a Scrum master and suspect your team wants to kill you, the first thing you need to do is listen. Put the Agile bible down and just listen. We do have a side in this story and we want it to be heard.
- These are just a few examples: 10 good reasons why working remotely makes sense; Why Remote Work Beats the Office Every Time and Remote Workers Are Outperforming Office Workers–Here’s Why. [return]