8
votes
Thoughts on agile and scrum
When I started working with development teams 3 years ago, I started learning all about agile and scrum. I'm currently a product manager working with two dev teams that loosely follow scrum. Since we don't have an official scrum master, I somewhat fill that role too. I've done my best to learn as much as I can about it and so far I'm a big fan. However I feel like most of the things I hear about it are from the scrum and agile community, which means I don't hear too many negatives. What's your experience with these been and if you were in the right position, how would you try to structure people to produce software?
JIRA's fine imo. Do you also use Tempo though? Because that piece of software is the real trash.
I think Jira is a good example of software that can be fine, and also can be trash, totally dependent on how it's used.
If Jira is just being used to keep track of work, maybe with some prioritization and a dash of "CYA", then I think it's very usable. If it's being used for that, and also recording points, epics, and keeping track of bugs and issues, I think that's mostly fine too. It's when it comes to burndown charts, time tracking, story cycle time measurements, etc. etc. that it can quickly becoming annoying.
Ah, for burndown charts and general reporting stuff, we have out own Python scripts which grab data from API and do whatever we need. For time tracking though, you're right, JIRA can be kind of painful. That's why we got Tempo but Tempo is even worse. It's constantly changing, frequently breaking, and the API isn't very well designed so we can't even build upon it effectively.
The scripts sound nice, and Tempo sounds horrible. Thanks for sharing; I'll keep an eye out to make sure that it doesn't trickle down to anyone I work with.
If you hate Jira I assume you haven't used axosoft, it was like a breath of fresh air moving to Jira from it.
Agile and SCRUM can be useful, but I feel like my current employer understands agile from a buzzword standpoint. Minimum viable product, sprint, points... okay, cool, that's part of the idea.
What's not part of the idea is deciding, before we have any kind of requirements to:
Set a definite timeline
Make that timeline part of a mission critical implementation
Artificially require that implementation halt progress to ensure the results of the imposed idea are tested.
Still not have requirements when all of that is put into place.
I get it. I do. We need to test the thing, but there are fundamental rules to development that are being skirted. And while they've up-ended my priorities by taking this approach, they are pretending I'm still on my other tasks.
No... no, I'm not. Because now I have this crowding out the other work. And I shouldn't have to tell them this. Looking at the requirements documents (big, therefore doesn't feel sprint-like) this isn't something I can do with a few hours here or there. It's obvious this is dominating my time.
But I have to tell them.
Basically, they've subverted agile to rationalize and formalize a complete lack of preparation - as a norm. That's not agile.
But they are doing a damned fine job of making sure people think agile is dumber than a box of nails. And that, long term, could be an issue. Agile is a cultural thing - absent leadership, it's just a sequence of requirements (as others have noted).
"Green field" development is different from "brown field" (existing) in that the overall structure of the thing is typically more well known and the timelines are better understood. New stuff... they get all kinds of fanciful with that. Before they know anything.
And, in my book, that's not Agile. And what they're calling a minimum viable product FOR A MISSION CRITICAL fucntion... it's not right. As in, objectively wrong. But they decided all that upfront before they talked to the people who would do the work.
So... Agile and SCRUM are tools. In the hands of a craftsman, they can be damned good. In the hands of someone who has no idea what they're doing, it's just another hammer to hit square pegs into round holes.
Developer here, 5 years professional experience, 10+ as an amateur. All 5 years in flavors of Agile.
IMO agile is great as long as everyone agrees on what the goals are, and don't play Cargo Cult with the ceremonies and process.
The main goals IMO are:
Those goals imply several things, first and foremost is communication. All the members of the team need to communicate often and clearly to each other, to their PM, and their PO. I would rather have a team of effective communicators than a team of "10x" developers any day.
I've also found that one of the easy to read signs of a dysfunctional team is that if someone walks up to a random team member and asks "whats your process for ______ " (getting a story approved and deployed for instance) and they can't answer, the communication is broken. Even worse, if you ask several people and they give different answers, or if they say the process but don't actually do it, the communication is severely broken.
:edit: @spit-evil-olive-tips linked to the Agile Manifesto which is a much better reference than just my personal bullet-list opinion.
I've been "using" agile and/or scrum and/or kanban and/or whatever_buzzword_isn't_waterfall for around 5 years, too. I've seen so many versions of these systems, intermingled and crossbred that I honestly don't know what's what anymore. I've seen so many different versions of all this stuff even among different teams at the same company.
Currently, my team is organizing work for the week, and following a mostly-automated kabana/laned system of "Open -> In Progress -> Ready for Review -> Deployed -> Done" in everyone's favorite software, Jira. I put points on my stories, most others don't. I make stories for everything I do, some others do too. Thankfully, we're not being required (right now) to log time to our tickets, which was hugely annoying.