Scrum / Agile

jnoble · 2019-08-17T14:24:53.080Z

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:

https://ronjeffries.com/articles/018-01ff/abandon-1/

Your mileage may vary.

eblomquist · 2019-08-17T14:25:37.072Z

Thanks for the responses. Sounds like I need to understand GitHub and KanBan better!

I definitely get the paid to develop context and how this clearly isn’t that at all…

csboling · 2019-08-17T14:31:18.537Z

jnoble:

no code versioning repository

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.

Jonny · 2019-08-17T14:33:43.129Z

Also, it’s worth reading the original Agile manifesto ideas to see how far the corporatized stuff has gone. I’d say that monome is closer to Agile already.

https://agilemanifesto.org/principles.html

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Working software is the primary measure of progress.

Continuous attention to technical excellence and good design enhances agility.

jnoble · 2019-08-17T14:42:22.398Z

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.

xenus_dad · 2019-08-17T16:15:01.509Z

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/

xenus_dad · 2019-08-17T16:16:41.326Z

Curious, are you saying you’ve abandoned source control? That seems brave

rvense · 2019-08-17T16:22:02.075Z

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.

murray · 2019-08-17T16:39:52.022Z

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.

csboling · 2019-08-17T17:01:15.727Z

jnoble:

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

jnoble:

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

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.

mzero · 2019-08-17T17:20:17.790Z

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.

csboling · 2019-08-17T17:43:12.135Z

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.

karst · 2019-08-17T18:16:02.645Z

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.

PaulBatchelor · 2019-08-17T19:20:02.926Z

Jonny:

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.

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.

sleahy73 · 2019-08-18T14:32:35.237Z

eblomquist:

I’m already thinking about how I can use it with my own musical 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?

karol · 2019-08-18T14:57:55.303Z

jnoble:

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 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 add
git merge
git commit -m
git push
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.

TheTechnobear · 2019-08-18T16:32:25.021Z

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

eblomquist · 2019-08-18T16:41:24.075Z

Well, the first thing that I’m doing is implementing a Trello board for the collaboration so we can track the progress of a fairly large number of Ableton sets we’re working on.

We live 90 minutes apart and have very busy lives so getting together in person is infrequent at best. We’re both pretty prolific at starting projects but not so good at sorting out what to do to get them into releasable shape.

So some kind of very informal and mellow version of some of the scrum/agile principles seems to be potentially helpful in keeping track of who is doing what and creating a bit of accountability, albeit in a relaxed way.

I’m still new to this stuff (scrum not music), so trying to muddle my way towards a more “productive “ workflow. Recognizing at the same time that music is fun and not work, but releasing things is part of the fun…

sleahy73 · 2019-08-18T18:19:04.597Z

That is interesting! I can see how some of the rituals from Scrum might be useful in oganizing communication and accountability. And if you’re trying to more clearly define your process/workflow, Trello should prove to be helpful.
In my mind, one of the big/important features of all forms of Agile is delivering completely working (as in customer facing) parts at short intervals. (Perhaps I have that wrong, but that’s my understanding). To that end, I don’t see how Scrum applies. Really, if you have a well defined process, a clearly defined outcome, and you know the desired outcome will not change, you should probably just do Waterfall. (Or “Scrumfall” if you need to deliver working parts along the way).
Here are some of the methodologies and their purposes (oversimplified) that I’ve been looking into. Maybe one of them might pique your interest…
Waterfall - best when neither process nor deliverables will change (factory/assembly line)
Agile (all forms) - gets management out of workers’ way, anticipates deliverables will change along the way
6 Sigma - a methodology for discovering and fixing hidden waste in complex processes
Lean - Methodology to reduce waste and speed up processes by reducing work in progess (Kanban, the concept not the Agile method, actually comes from Lean)
Design Thinking/Lean Business Startup - A method that incapsulates creativity and iterative process in order to get the (hopefully) best outcome.
You might also find “Design Sprints” interesting. It’s kind of the middle ground between Design Thinking and Agile… sort of…
I’m not an expert in any of the above, so it’s quite possible someone more experienced with them might have a more nuanced view. But I find them all to be interesting, and, in part, applicable. Maybe you will too…

eblomquist · 2019-08-18T22:37:35.324Z

I love this! Covert psy-ops is very Burroughsian…