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

61–70 of 102 posts

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

#61

Post by lmm »

abacadaba wrote: post #59
lmm wrote: post #57

Earlier quoted context omitted.

Nah. Standup is for day-to-day current status. It's worth having a regular point where you have a think about how well your process is going over the longer term and if there's anything you want to change. You can always cut it short if everyone's happy with the current state of things.

and we're out here having meetings about how to make retro more actionable.. but ya it's really more scrum and associated bs that i have a problem with vs og agile.

> and we're out here having meetings about how to make retro more actionable..

That's something the retro itself should do. First part of the retro should be reviewing the results of the last retro and what's been done about them. (And WTF are you even doing in the retro if you're not coming up with actionable things?)

> scrum master or agile guru

Lol no, I think those are probably scams. Actually doing agile works, but those positions are probably anticorrelated with actually doing agile.

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

#62

Post by Silhouette »

siva7 wrote: post #32
mdgrech23 wrote: post #31

Earlier quoted context omitted.

Agile was always about selling training courses, books, certifications and what not. They managed to sell this by telling the business it would let the dev team move faster/need less people/save money. After years people are not finally realizing this sales pitch never came to fruition.

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.

Teams of good people have always been agile in the truest sense - they will find a way to organise themselves to collectively get the job done. They don't need to be "empowered" by some rigid Agile process to do that. In fact it will most likely get in the way.

Agile (capital A) processes have always been trying to sell the idea that a mediocre team can be elevated if they have the right process to guide them. Whether that actually works when the team isn't good enough to self-organise anyway is debatable but that's the sales pitch.

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

#63

Post by Scarblac »

glonq wrote: post #9

I've managed small-to-medium teams for a very long time. Agile is very often not the answer, because on a small team you don't have all of the people and roles necessary to do agile "right". I tend to just do Kanban with frequent demos and milestones. I agree on documentation. I try lead by example and document all the important bits to a "hit by a bus" level. Because on a small team losing one person means losing a…

To me a core part of agile is self managing teams. It makes sense that a team manager sees it as not the answer.

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

#64

Post by azangru »

redhale wrote: post #45
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.

Yes. Dave Farley added to this confusion by publishing a video, through GOTO conferences, titled Agile vs Kanban: Which is Better? [0]. And he, of all people, should know better.

[0] - https://youtu.be/N9coClM4qf8

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

#65

Post by azangru »

__pache__ wrote: post #48
BarryMilo wrote: post #37

Earlier quoted context omitted.

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.

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

What open-source projects in particular do you have in mind? And what do they run on, exactly? And what would this model look like if transplanted into a business setting?

I can see some aspects of agile project management in open-source projects. One, transparency/visibility. Two, working software over documentation. Three, customer feedback. In fact, some large open-source projects have introduced channels for early interactions with customers (i.e. developers) — for example, the RFCs initiatives of React or Lit, or community engagement in various html or css work groups.

I do not know how well developers on open-source projects coordinate/communicate between each other. Or how work gets prioritised. I've certainly seen a fair number of failures in that aspect of open-source projects.

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

#66

Post by azangru »

Silhouette wrote: post #62
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.

Teams of good people have always been agile in the truest sense - they will find a way to organise themselves to collectively get the job done. They don't need to be "empowered" by some rigid Agile process to do that. In fact it will most likely get in the way. Agile (capital A) processes have always been trying to sell the idea that a mediocre team can be elevated if they have the right process to guide them. Whethe…

> Teams of good people have always been agile in the truest sense - they will find a way to organise themselves to collectively get the job done.

The word "good" here is very vague :-) People can be well-intentioned ("good"), but disorganized, unskilled, or wishful-thinking. People can be strong programmers ("good"), but work by themselves, without coordinating with others. People can be good, yet have managers micromanaging them. People can be good, yet required to work on different projects at once, which breaks focus. People can be good, yet separated from the customers of stakeholders by a layer of managers. People can be good, but required to analyze and estimate the project before even starting working on it, and then be held accountable for their estimate when they run over time. And so on, and so forth.

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

#67

Post by sanderjd »

lylejantzi3rd wrote: post #58
Silhouette wrote: post #54

Earlier quoted context omitted.

That strategy does limit your documentation to text though. Sometimes a literal big picture and a few well-considered supporting diagrams can be worth more than a hundred screens of Markdown.

It's also only visible to developers.

Everyone should have access to the repo's web interface.

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

#68

Post by sanderjd »

Silhouette wrote: post #54
chinchilla2020 wrote: post #35

Earlier quoted context omitted.

Love this approach. It keeps everything in a 'one stop shop. There is nothing worse than having to chase a tangled graph of google sheets, word documents, readmes, confluences, and figma diagrams in order to understand a piece of code. Just put the whole bloody thing in a little documentation file in the class and be done with it. Better yet, actually use the python docstrings or java docstrings (whatever you call th…

That strategy does limit your documentation to text though. Sometimes a literal big picture and a few well-considered supporting diagrams can be worth more than a hundred screens of Markdown.

You can put images and diagrams in markdown documents.

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

#69

Post by lylejantzi3rd »

sanderjd wrote: post #67
lylejantzi3rd wrote: post #58

Earlier quoted context omitted.

It's also only visible to developers.

Everyone should have access to the repo's web interface.

That's ridiculous. You can't expect non-technical managers and graphic designers to try to dig around your code base to find what they're looking for, let alone make changes.
Post reply on HN