Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What I learned after managing a small team for 2 years

luispcosta.com

Post reply on HN
Print view View original

41–50 of 102 posts

Re: What I learned after managing a small team for 2 years

#41

Post by screye »

Genuine question, Do we need Agile, Scrum, Kanban, Waterfall, etc. ?

It's glorified to-do lists with an opinionated cadence on how often features get deployed. Do we really need an entire discipline to communicate those simple things.

How flexible are we with requirements ? How many stages are in the to-do list ? How many hierarchies are in the todo list? How often do we features to be deployed ? What more do you need to know ?

Takes 1 long meeting establish a well-communicated bespoke development cycle for each team. Do we really need a phrase for that ? My experience tells me that the system gets sub-optimally molded to suit the implicit development style of the team whether you like it or not.

Re: What I learned after managing a small team for 2 years

#42

Post by paulddraper »

lylejantzi3rd wrote: post #3

> Documentation is everything What I learned after managing a small team for 2 years is that documentation is only good if the team can find it, if the team bothers to look for it, and if the team takes the time to read it. I can't tell you how many times I've linked pertinent documentation in Confluence from the Jira task, only to have the developer ignore it. What black magic do you have to cast to get devs to look…

AKA "write-only memory"

Re: What I learned after managing a small team for 2 years

#43

Post by paulddraper »

stock_toaster wrote: post #5
lylejantzi3rd wrote: post #3

> Documentation is everything What I learned after managing a small team for 2 years is that documentation is only good if the team can find it, if the team bothers to look for it, and if the team takes the time to read it. I can't tell you how many times I've linked pertinent documentation in Confluence from the Jira task, only to have the developer ignore it. What black magic do you have to cast to get devs to look…

> What black magic do you have to cast to get devs to look at the documentation? Not use Jira and Confluence? More seriously, I have found that confluence is where documentation goes to die. Something about the tooling, the slowness, poor search, admin tools leading to overzealous compartmentalization, not-quite-good plain text format, awkward gui editing tools, versioning system, distance from the code[1]... somethi…

There is truth to this. Notion, etc are far more pleasant, readable, and lend for better organization.

Re: What I learned after managing a small team for 2 years

#44

Post by timmit »

lylejantzi3rd wrote: post #3

> Documentation is everything What I learned after managing a small team for 2 years is that documentation is only good if the team can find it, if the team bothers to look for it, and if the team takes the time to read it. I can't tell you how many times I've linked pertinent documentation in Confluence from the Jira task, only to have the developer ignore it. What black magic do you have to cast to get devs to look…

I guess it would be better to rephrase it like

> Good, Well Indexed and Easy to Find documentation is everything.

Re: What I learned after managing a small team for 2 years

#45

Post by redhale »

azangru wrote: post #29

> But most of all, agile doesn’t fit in the context of this particular project, because the client changes priorities very frequently. The whole point of agile software development was to make it possible to adapt to an environment with frequently changing requirements. The hint is in the name — agile. How can "very frequently changing priorities" be a factor against agile software development is completely beyond me…

There maybe just seems to be some term confusion. Scrum is one flavor of Agile. Kanban is another flavor of Agile.

> The previous system the team was following was something very close to a Kanban system.

The team was already operating in an agile way.

Re: What I learned after managing a small team for 2 years

#46

Post by paulddraper »

azangru wrote: post #29

> But most of all, agile doesn’t fit in the context of this particular project, because the client changes priorities very frequently. The whole point of agile software development was to make it possible to adapt to an environment with frequently changing requirements. The hint is in the name — agile. How can "very frequently changing priorities" be a factor against agile software development is completely beyond me…

For those wondering "then what the heck is Agile?", it is this: https://agilemanifesto.org/

Re: What I learned after managing a small team for 2 years

#47

Post by gerdesj »

A delightful post and there is a very decent message in amongst the happy puppy grows up stuff:

"If I had to do it all again, I would have immediately sat down with each team member individually to hear their thoughts about:"

Do that and then do it again collectively and do it repeatedly. People need to be needed. People need to be valued. People who feel needed and valued tend to perform best. You don't have to be best mates or even like each other - that's tricky but do able.

Re: What I learned after managing a small team for 2 years

#48

Post by __pache__ »

BarryMilo wrote: post #37
siva7 wrote: post #32

Earlier quoted context omitted.

Delivering faster was never the promise of Agile. It also can't turn a shit team into an agile team. But it certainly empowers a solid team to deliver what business needs while moving faster.

Agile is better than nothing, which is what most teams would/did have as an alternative.

Huh? Why don't lots of successful open source softwares run on agile, then?

Pretty sure having motivated people who find the work kinda fun destroys agile/any other methodology. When people wake up excited to pull down tickets or just get shit done, you're doing business right.

Re: What I learned after managing a small team for 2 years

#49

Post by __pache__ »

screye wrote: post #41

Genuine question, Do we need Agile, Scrum, Kanban, Waterfall, etc. ? It's glorified to-do lists with an opinionated cadence on how often features get deployed. Do we really need an entire discipline to communicate those simple things. How flexible are we with requirements ? How many stages are in the to-do list ? How many hierarchies are in the todo list? How often do we features to be deployed ? What more do you nee…

No, we don't need all this nonsense (on small teams)

I hate all the meetings, which we can "feel" don't make sense. When we all "feel" a meeting makes sense, we naturally hop in. Totally different vibes.

Re: What I learned after managing a small team for 2 years

#50

Post by ajb »

lowercased wrote: post #36
rented_mule wrote: post #24

Earlier quoted context omitted.

> I just fail to see how one can build anything if priorities change on a daily basis. I experienced something like this in a startup where I was one of five engineers. We were lucky to have individual offices at the end of a hallway. The CEO would walk down the hall a couple of times a week, stopping in each office, and change priorities on us. He had no idea how disruptive it was and always laughed when we told him…

> The CEO would walk down the hall a couple of times a week, stopping in each office, and change priorities on us.... Eventually the CEO saw that we were making very little progress... I'm flummoxed as to how someone can not see this. Can you not run a little thought experiment on yourself, like... "How much could I get done if every 3 days, I told someone to stop in the middle of their 4 day task and do something di…

Because that's not how the CEO's job works - his job is to keep a bunch of plates spinning, and switch quickly to the one that's about to wobble off its pole. Sales is similar. If your CEO came up via sales, it's hard to believe that other professions need to work differently.

I tried to convince a CEO of this once and he initially just got angry, then started to parse it as my personal need that he might need to make allowances for due to neurodiversity or something. That all his engineers might work better if they could focus on a task for more than a day was too far outside his world view to be believable to him. And this wasn't a stupid guy, no matter what it might sound like.

Post reply on HN