Not sure if this is the right place to put this, and I didn’t find it elsewhere, so please Mods move if you want…
I must start by saying that I am not a coder, nor really any kind of IT professional. I am an attorney by trade, but my job asked me to do Scrum Master training because a lot of our folks are using the Scrum methodology. So that’s what I did the past two days.
One of the things that occurred to me while I was learning this stuff was that the Lines community might be able to benefit from something like this for firmware and software development. I see a lot of wonderful efforts being made, but do not see (and maybe I’m not looking in the right place) much in the way of structured collaboration. Perhaps that’s what GitHub provides, but it seems (to me) to be more oriented towards individuals pushing stuff back and forth.
Maybe the Scrum approach feels too corporate, but I’m already thinking about how I can use it with my own musical projects…
Just a very well-intentioned question, I do not presume to know how folks are actually working in this area.
On Github’s free interface the most commonly used organizational features are issues, pull requests (AKA merge requests), and its wiki functionality. Many pro software development workflows, whether they’re using scrum or not, also rely heavily on pull requests, and will generally use some type of ticket tracker software which may or may not be integrated with their source control. I am sure there are shops around that use neither source control nor ticket trackers, I generally hope to find this out before leaving the interview so I can run like hell.
That stuff is sort of a level below scrum, though the issues on a Github project are basically its backlog. The rest is maybe hard to map to open source community projects. In larger, company-sponsored projects where multiple people are paid part- or full-time to work on them, those teams probably are using scrum, just a lot of the planning happens elsewhere. You can do standup meetings in some group chat, voice or text, which could make sense for really active projects but I think core contributors in those cases are probably in enough online contact / different time zones that something like “standup is 9:30 - 9:45 GMT” seems weird. Sprints also seem like kind of an ungainly schedule to use when lots of the people contributing to a project are basically its users, who work on stuff if and when they feel like it. I would even guess that being informally structured and lacking the implied pressures of schedules or “product value” is probably a big part of what makes this kind of community open source model effective, since people can contribute in small, focused ways without necessarily feeling obligated to a schedule or roadmap.
This is not to dismiss or express distaste for scrum in general, I think it has served a valuable function in organizations I’ve worked for.
There are many aspects that would be hard to ‘enforce’ and put into practice. If we had a scrum master asking why their tickets or tasks weren’t done in this setting, it would be kind of odd. Scrum is also centered around daily stand-up meetings and things that go with a 9-5 schedule.
There are some other methodologies that might be worth looking at too, like Kanban.
No offense to practitioners/believers, but … Scrum: “process, process everywhere but not a drop to drink!” (with apologies to Coleridge). I feel so fortunate to have final say in technical matters in my companies. We have almost no process at all (no code versioning repository, it felt so good to get rid of it!) and get a lot done in a low stress way with a very small team.
One of the original signers of the Agile Manifesto puts it better than I can:
I have to know more about how this works when you have more than one person involved. I cannot imagine how I’d keep things straight or avoid being paralyzed by fear of breaking stuff, I version control everything I do, possibly especially including my own projects / experiments that no one else will likely ever see.
We have areas of responsibility and let each other know if we need to do anything outside those areas. In practice we’ve stepped on each other’s code maybe 3 times in the past 5 years. We’re a web/hybrid app shop, so our needs are a little different from an avionics firmware outfit.
I found that I never referred back to previous versions when using cvs/svn: what I’m doing today is better than what I did yesterday, or I wouldn’t be messing with it. Getting rid of the process overhead was wonderful, and the loss of the perceived safety net absolutely enforces a certain discipline which (for us, a very seasoned shop) results in improved results in both time and quality.
I don’t think this scales well or works with less well-functioning/competent teams. But I also think most small to mid sized projects don’t need so many people in the first place, especially compared to 20 years ago.
To me a key component of Scrum is each working having a relatively consistent amount of time/effort per sprint, so that you are able to size the amount of work when planning a sprint. This seems like it would be hard to do in a volunteer effort unless everyone was very disciplined.
Kanban might work a little better for less structured schedules, and can be done for cheap/free with Trello among other tools. https://trello.com/
Agile is a religion: A couple of very smart people wrote down some very general, well-meant advice… then a little while later there’s an entire cottage industry of self-help books and motivational speakers telling me I’m living my life wrong.
Agile/Scrum in my experience has always been used by management of my past organizations as a crutch to make up for a lack of technical knowledge in order to generally understand and measure the work being done in regards to business agreements.
The first time I’ve had technically competent management as of a few months ago and we’re using a whiteboard, kanban (only viewable by our team of 7), and git.
This is an interesting perspective! A web application, or native application where you push updates, perhaps has more freedom to live in this kind of eternal now: version control (at least for the active deployment) is redundant because there is a single canonical version. I find that appealing in a similar way to some perspectives found in various “patching from scratch” discussions. In more fixed deployments where there are lots of versions in the field, like traditional desktop apps or, say, Eurorack module firmwares, or any software that makes calculations that must be reproducible across revisions, I find precise version information incredibly important, and version control is a very effective and convenient way of managing this.
I’m quite fond of continuous integration as a lightweight (sometimes…) process, and this is what’s pursued by lots of projects (incl. code for monome devices) on modern social-coding type sites, which typically make it relatively easy to set up. This is orthogonal to scrum but definitely in keeping with the goal to “deliver working software frequently”. The idea here is to do a basic automated screening to find changes that would/could cause a problem: does it compile? does the program run, or crash immediately? does it pass this set of automatic checks that smaller pieces of the code are producing the right output? did two people make different changes to the same line of code at once that will need to be resolved? It’s not perfect, and it’s no substitute for a human firing up the program and trying to use it, but it filters out plenty of little and big mistakes or oversights that are made by people with lots of different levels of experience. I have no idea how you would do this, and make use of its ability to tell you what’s wrong, without version control software, and this kind of tool in addition to the “safety net” of plain ol’ source control certainly lowers the amount of stress involved in my programming workflow(s).
Manual testing also benefits a lot from having a reliable change log, which many people are good at keeping by hand, and I am not without machine assistance. Distributed version control and the issue / discussion / PR / review and run CI type of simple process that is typical of Github projects suits my scatterbrain. Scrum doesn’t quite, in particular I kind of dread assigning story points or even delineating self-contained tasks sometimes: I want to write down the code that’s in my head, I may need to change some stuff along the way, this sprint I will commit to another sum $ fix ((0:) . scanl (+) 1) points of getting shit done; in this mindset I can definitely resonate with the freedom to identify and pursue what needs to happen. Some type of quick daily check-in makes a ton of sense to me though, 5-15 mins a day dedicated to getting on the same page with one’s team doesn’t strike me as onerous as some complaints I have heard about scrum would suggest. As an internal structure adopted by teams for breaking off actionable work, I think scrum is a pretty reasonable tool. It is nice to have a pattern to follow. As an implement of micromanagement, I am of course less of a fan.
Just some historical notes since no one brought them up:
“Scrum”, as a trademark’d process / course / business…
…grew out of “agile”, a concept / manifesto…
…which grew out of “extreme programming”, a book by Kent Beck.
Kent Beck was an programmer, leading a team of consultants, that recognized that the formal methods of producing software at the time (think “waterfall”) - no longer made sense, because the assumptions about the discipline had changed. Our practice as programmers used to be: write on coding sheets, have someone card punch, submit deck to run, retrieve printout an hour later… (I learned to code in this era!) This meant that debugging and code change was costly and re-architecting was impossibly expensive…
But this was no longer true: Kent was an early Smalltalk programmer - and Smalltalk pioneered the concept of development environment (inventing most of GUI as we know it today along the way!) And so, Kent and his team went about creating a process that took advantage of the speed those development environments offered. Coupling it with strong automated testing, they found a process that was the opposite of process-laden methodologies – and was agile.
The approach they developed, and outlined in extreme programming was developed by and for engineers, to make them faster at delivering just the right code without bugs. They did it because it worked for them. In the book they stress that every group should take and use what they need from their work, and adapt it as needed to work for them. I’d say “certified Scrum-master” is pretty antithetical to what they were sharing.
I really recommend the book extereme programming as well as the few other volumes in the series. They are very short, and to the point. I think afternoon or two reading them is worth more than any Scrum™️ course I’ve ever seen.
Super interesting! I have read at least most of this book and had some awareness of Scrum™️ the company but guess I did not realize somehow that capital Scrum was (at one point) trademarked. Wikipedia ascribes the term to this Harvard Business Review article, which uses a photocopier case study at Fuji-Xerox, a company which both paid Alan Kay’s group to develop Smalltalk and makes a different product which I did not realize was a trademarked word for many years.
one other thing that scrum can really struggle with are open-ended investigations that have a high probability of failure, or at least of many uncovered dead-ends before success.
this is mostly due to, as @murray said, the need to measure and track work without deep technical understanding and the strong need to maintain “sprint velocity”. back when I doing the tech thing, I’ve seen scrum often lower the ambitions of teams because what was being investigated was difficult to write into a ticket that would definitely result in success.
Yup. Having been on a few FOSS projects, I can say from experience that practices like SCRUM wouldn’t work well. You’d need a certain kind of consistency that most FOSS projects lack. Sometimes you’ll have weeks where a core dev needs time off and things sort of halt. Or, you’ll have a dev that suddenly stops contributing because they got a new job that prevents them from doing X due to a clause in their contract, and this surprise can also slow things down. Sometimes, you’ll get drive-by contributions from random strangers. These can be helpful (and maybe a time sync too, depending on the contribution), but it isn’t one of those things you can really expect regularly. Or maybe, for a period of time, you get a dev who is a specialist at Y, so for a few months you get a bunch of cool features related to Y. When they leave, nobody knows how to maintain/improve Y so that functionality stalls.
These kinds of things happen all the time, and for this reason, it is very hard to accurately measure/predict the growth and development of FOSS projects.
I’m not an IT pro either - musician, actually - But I do hold CSM and SAFe Agilist certificates (keeping a long story short, just something I’m interested in). I’m curious about how you would approach applying Scum to your musical projects. Care to elaborate?
I don’t know a lot about previous source controls system (had to use svn only in my first job) but I don’t think that git adds too much overhead. Basically almost everything that you need is git checkout -b
git commit -m
and this adds a whole history to the system where you can check why somebody commited something, can easily distribute the source code by using the git server, easily try new ideas on code etc.
I guess workflow varies between companies but I used git from hardware related projects to web based apps/microservices and never felt that it was slowing me down. If you your last experience with version control was svn then I strongly recommend at least checking git.
And to get back on topic in more informal projects the approach that suited me best was to just create small cards for tasks (for example in trello) and then whoever has time can pick it up.
Agile was largely marketing …
The idea that before it devs were still using waterfall is nonsense - the industry had already been doing rapid prototyping and evolutionary prototyping for many years - preaching a lot of very similar concepts to agile eg the importance of involving users, getting feedback early on, and the fallacy of estimates.
None of this was new, and largely came around not due to some magic book/workflow but due to way the development tools had changed which made the dev cycle much quicker, particularly in the UI/data area.
but managers like to be sold silver bullets, so loved the agile consultants esp when they came with pretty coloured cards and pens