This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (6)
- # announcements (1)
- # babashka (2)
- # beginners (51)
- # calva (14)
- # cider (1)
- # clj-kondo (15)
- # cljs-dev (2)
- # cljsrn (1)
- # clojure (9)
- # clojure-czech (2)
- # clojure-spec (5)
- # clojure-uk (45)
- # clojuredesign-podcast (2)
- # clojurescript (4)
- # clojutre (3)
- # cursive (4)
- # datomic (8)
- # duct (8)
- # jackdaw (1)
- # joker (1)
- # keechma (1)
- # off-topic (127)
- # om (1)
- # reagent (1)
- # reitit (6)
- # shadow-cljs (22)
- # testing (3)
Any insights on “processes” for making small teams (2-4 devs) in small companies (10-15 people) effective?
I’m not a big fan of scrum and the chopping up of work in tiny chunks, as it seems to me way too much overhead, but perhaps it’s a necessity after all?
@orestis, I have found that small chunks of work, delivered frequently, that are based on perceived needs of your audience, then tested with your audience, help you to build something that is meaningful to your audience.
short feedback loops help you to both optimize process and keep you from straying down unfruitful avenues
I agree with all that, but I have trouble putting them into practice in the context of a team.
How short is a short feedback loop? Hours, days, weeks? What if the team isn’t delivering fast enough? Too little tasks have a coordination / handover overhead, but large tasks might take longer.
It takes a while to find an appropriate cadence for a team. Your first feedback loop length would be a comfortable guess. Maybe a week, maybe two, whatever feels good. Then try it out, find what worked, what did not and adjust. Then repeat.
I’ve always been suspicious of any rigid methodology, your team can decide to keep what works and tweak what does not.
you still have to chop things down to smaller deliverable units ... but it removed awkward scrum date boundaries that really don't improve anything
tiny example - a piece of work can be done in 2 steps , 3 working days each .... if you run a weekly scrum cycle , then by the book, it will take you 2 scrum cycles to do it and the fastest you can do it is in 8 days
because nothing should be open / on the board when you finish the sprint . if something is open by the end of the sprint you should call the sprint a failure.
our approach with kanban is more fluid and we don't have weird artificial deadlines set up that would somehow disrupt the work rhythm. we get the thing done in 6 days and nobody feels bad about the process.
to me, personally, it feels like scrum is designed for the mid level management, to improve the predictability and control over devs ... it's not a process by the devs for the devs
Sprints are especially useful if you have more teams and/or have external dependencies. Not that it's easy to get estimates right, but to some degree you can know if the current planning would likely cause an impediment.
we moved to from sprints to flow at the last place I worked at for this reason. We still had weekly demos. And we could tell if a team member was getting stuck.
after all, a developer has a few good hours per day (certainly not 8 high end productive hours). if you get them into a good flow within those hours and you don't context switch them between tasks - you get the best out of them
with kanban we still have a plan , we have small tasks, we can predict when things get ready and we demo when stuff gets ready 🙂 (we also have a weekly retro for the team where we reflect back on the week and discuss how to improve) ...
In practice that's is about 20% that is changed within sprint in our case through, sometimes we do more work, in points, but didn't deliver everything we promised, which is kind of fine.
back when i was in skype, we started to get release pressure on the day(s) before the sprint end , because everyone wanted to get their stuff out into production to succeed with their scrum sprints
but it's definitely not a good idea to have ~50 people releasing like hamsters for a deadline that nobody asked for
Yes, we kind of having a problem with sre being on the same schedule. So sometimes we have infra issues right at the end if the sprint..
and it's not a problem to start with a 3 day task on wednesday, finish it up on monday morning and release on the monday
needless pressure and nobody really wins (and ops/devops teams get anxious , because those days can turn from sunny into hell real quick)
of course if you are more liberal with your scrum following, you can maybe play around the rules a little bit to get more reasonable work balance 🙂
we went to kanban exactly for these reasons ... and when you look from far enough, agile is still agile ... and things get done in the order they are supposed to happen
i still consider scrum and kanban both still way better than the big jump waterfall that i witnessed before 2009 all too often .... people wrote code for 4 months, then tested for regressions for a whole month, ... then released and hotfixed in panic 😄
we even had a dedicated release room for those days, we called it the war room. lots of coffee, lots of energy drinks, countless packs of cigarettes exhausted by the door and handful of gray hair every time ...
and unsurprisingly the room had no windows ... so if you had been releasing and hotfixing stuff for 8 hours in a day - you sure were happy to get out of there eventually
can I ask how do you see some [or maybe most] of startups that are not using waterfall, but definitely are 100% depending on one or two bright developer to turn a bunch of scratch in a paper into a product? There are no "agile" rituals over that, only trial and errors. I've witnessed this 3 times over the last 6 years. There are good aproaches for greenfield projects?
What about user stories? Who writes them? Who defines them? Should devs be expected to go chase the PM to flesh out details? Or is there a whole cycle before something is “ready for dev” that’s missing?
we usually have lead developers per product, who are the first contact for product owners ... they stop incomplete things way before it reaches the rest of the team
but usually very incomplete stories hint that the person ordering the fix or feature, doesn't really care too much
Has anyone read Shape Up? If so, has anyone worked with the process presented in it? https://basecamp.com/shapeup
I haven’t worked with it, but I really like the thinking behind it, and would like to try it out.
in the long run only real features that customers need matter ... and sometimes what matters is that your product is scaling to need and maintainable for the developers instead of extra features for corner-corner cases
That’s very interesting. I feel like as an experienced dev I can play the role of the lead dev that stops incomplete stories, but I’m lost when it comes to the story creation etc.
and something from my own drawer - i really dislike the term project manager. these are usually the guys who get their own feature done (for which they may earn fame, credit or financial bonus) ... but they tend to close the door as soon as they have the first release done. they don't really invest into maintainability or refactorings, technincal debt. and if people let the latter pile up then you're in for some really tough times. hard codebase to work with and a high flow of hirings-leavings due to stress or lack of work satisfaction ... at least this was a pretty popular model of doing things 10 years ago ... since then i haven't been working for a company that was driven by short-lived projects nor the project managers.
the approach of product owners is more healthy (still depends on the personality of the people of course) - but at least by design they are accountable in a long run. not just until next paycheck.
Wow, first gem in shape-up: 6-week cycles. That does make sense in my situation because one or two weeks is way too little to get anything done.
In short: - There are two “tracks”: shaping and building - The purpose of shaping is to do research (user or otherwise), interact with stakeholders, etc. to in the end produce a brief that describes something worthwhile to work on. It should be pretty detailed as to what is supposed to be accomplished, but pretty rough when it comes to designs and exact implementation. It should explicitly contain what is not to be built (scope limitations). - The building stage implements the thing described in the brief. As understanding of the problem is expected to grow during building, the building team can (and should) hammer down the scope further than what was presented in the brief. Briefs are scoped to (theoretically) be buildable by a team of two developers and a designer over six weeks (plus testers as necessary towards the end). Testing with users is included in this timeframe. - Shaping and building happen in parallel. During the time that some are building, some are shaping the next batch. - Deciding what goes from shaping into building happens in a meeting. - There’s no backlog: ideas that didn’t make it remain with the creator, who can continue to work on them and bring them up at a later date if desired. - The team implementing an idea organise themselves however they want. - After the 6 week cycle, there are 2 weeks where everyone can do whatever they want: work on bugs, improve infrastructure, what-have-you.
Additionally, - No daily standups (unless the team wants to do that themselves). - Progress reporting is made as asynchronous as possible. In this case, of course, they use Basecamp report on progress as they proceed with the building, but that’s circumstantial. The point is, progress reporting is done such that a stakeholder can understand the status without talking to (interrupting) the team, unless it’s absolutely necessary.
There are a lot of more details to this in the book itself that I can’t include here without reproducing the book. All in all, it adds up to something that sounds healthy to me, and has me intrigued.
meaning there must be more deliverable steps to get to the end goal, whatever that is
and meaningful should be "this thing delivered actually provides extra value or feature"
For me the crucial secret sauce that Basecamp describes is the close collaboration between devs and designers, given a “shape”.
just chopping a big feature and still releasing it like a waterfall ... really isn't splitting anything and means taking a big risk
Hi all, not tryna hijack the convo, just wanted to let everyone know that: If you're interested in learning Japanese and want to support the development of an awesome project, please check out the overview at Japanese Complete ^_^ http://www.japanesecomplete.com/overview (built entirely with clojure and clojurescript)
I’ve seen designers on their own go on a mad trip of designing everything in pixel perfect detail, which becomes a nightmare to implement, and then very vague descriptions and extending the scope for another two days, and three days, and two days...
Which of course points that we’re missing some role in our org, I’m just trying to figure out which one :)
the question is, do the actual consumers of the product care about the pixel perfect ? 🙂
doesn't mean that things have to look ugly .... but most of the time people are happy with "good enough"
But if the chopping up of work is based on a very detailed design, that’s also very prone to ballooning of work, because the designer never considered the implementation costs, and the dev lacks the big picture.
That’s not to say that our people aren’t willing to change their minds - it’s just that communication is hard!
you can not effectively chop up work for more than 2 dev sprints, in my experience ...
but you can say ... "yes, the partner wants us to have a highly configurable recurring billing system with discounts, free trials, promotions, all bells and whistles .... and within 1.5 weeks i can deliver something that can do repeatable payments and we advance from there (and we may even be able to sell that part to some partners already)"
knowing your destination direction is good but if you can effectively technically plan something that takes months to do, with a day precision in estimate or even a vague techincal plan, you're superhuman 🙂
especially since the partners who order a feature don't even know by themselves what they want in the end, to the pixel perfect level.
and to compensate they use the universal estimation formula .. you take the smallest estimate, the biggest estimate, you add them together and multiply at least by two ...
also ... i don't do those projects anymore ... i gave up 14 years ago on those, life is too short to drown it into those.
6 weeks to do both design and dev seem reasonable to me. Our platform is similar to basecamp in that it’s highly visual, so perhaps that’s why I see the value.
Thanks for the link @henrik - so far it looks very nicely written and reasonable. Have a great Sunday everyone and thanks for the discussion 👋
any Japanese speaking in the house? I want to know the translation of 'keredomo hyaku percento gambarimasu'. Google translate says something else than the person I got this from says it means.
friend tried to translate: Something (not sure the word) 100% let's do our/your/my best
Ah, that's exactly what the person said, but google translate says: "However, there is a lot of perks.", weird.
The context of this question: Student asks a zen master: what is the meaning of life? His reply: No reason, keredomo hyaku percento gambarimasu.
Nice article by Douglas Hofstadter, fluent in I think 4 languages, getting deep into how rough Google translate is compared to a fluent human: https://www.theatlantic.com/technology/archive/2018/01/the-shallowness-of-google-translate/551570/
if we take the definition of collections from Clojure's oficial website. Clojure collections "collect" values into compound values. There are four key Clojure collection types: vectors, lists, sets, and maps. Of those four collection types, vectors and lists are ordered. we might say, that "values" is the word you are looking for?
Not really, as "value" also include collections. There's a word specifically for non-collection values that I've got on the tip of my tongue...
Depends on the the domain you have in mind, could be scalar [to oppose vectors/collections.. resamble some aspect of dimension to the value at hand]
Not sure which official Clojure site page you are referring to, but it seems accurate to me to refer to something as both a "collection" and a "value" at the same time.
https://clojure.org/guides/learn/sequential_colls , I think in this definition he is using the word 'compound' to make some sort of distinction between values
It seems legitimate to me to subdivide immutable values based on whether they are a collection or not. Do you see some problem with making such a distinction?
no problem. I didn't say scalar at first because for me the distinction of unit and collection is more about dimensions of these data structures. Scalar for me has a physical meaning and the opposite of that would mean that collections have direction and magnitude associated with it. I dont have a background in CS so I dont know if this word is used with other meaning
certainly in some parts of math scalar vs. vector is a common distinction. Values in general need not have a direction or magnitude, though. What is the direction or magnitude of a string of characters?
I think the programming language uses 'atom' or 'atomic' for some such values, but that has overloaded meaning in English, too.
If one is willing to accept a set or a Clojure map as a collection, the idea of a "dimension" does not seem to me to have any applicable meaning there
dimensions are calculated in set theory and linear algebra too. But as the general case, I agree with you.
my book of set theory has an great quote from von neumann "in mathematics you don't understand things, you just get used to them" hehehe\
I do not claim to be anywhere near as good at mathematics as von Neumann, but it makes me a little sad when experts say such things. I believe it lends to others thinking "well, it isn't supposed to make sense, then", rather than striving more often to ask questions so that it does make sense, and if it doesn't, to look for better answers where it does.
I think it deserves some context about this quote. At least, what I've been told and makes sense with Von Neumann trajectory. He was one of the guys that made a lot of criticism about mathematics because it was overly complex and unintuitive and there are a whole branch of mathematicians that do not see any value in transforming math to be more intuitive and clear as long as you prove your theorems. He is claiming just the opposite of what you said. I agree that without context and attaching the text to the figure it can feel the other way around