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

91–100 of 102 posts

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

#91

Post by seadan83 »

mdgrech23 wrote: post #31
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…

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.

The first agile manifesto people were largely consultants who realized that initial requirements are often bloated and not quite right. Instead it is better to work with a client to gradually develop their ideas and to work with them for that.

The cottage industry came out of that pretty quickly and development process often turned into some manager or PM using the first Google result about SDLC.

I somewhat agree overall, but the origin story and the context that the original agile manifesto people were consultants I think is an important context

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

#92

Post by [deleted] »

nikau wrote: post #85
lmm wrote: post #52

Earlier quoted context omitted.

> 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. Apparently we do, since we still get people who want estimates months in advance (and then want to punish you if those estimates were wrong), who want to commit to a plan and then follow it and then change it without changing the deadlines, .... > My e…

> since we still get people who want estimates months in advance Its almost like the real world has deadlines and interactions with 3rd parties who need to schedule things too.

[deleted]

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

#93

Post by [deleted] »

nikau wrote: post #85
lmm wrote: post #52

Earlier quoted context omitted.

> 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. Apparently we do, since we still get people who want estimates months in advance (and then want to punish you if those estimates were wrong), who want to commit to a plan and then follow it and then change it without changing the deadlines, .... > My e…

> since we still get people who want estimates months in advance Its almost like the real world has deadlines and interactions with 3rd parties who need to schedule things too.

[deleted]

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

#94

Post by seadan83 »

nikau wrote: post #85
lmm wrote: post #52

Earlier quoted context omitted.

> 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. Apparently we do, since we still get people who want estimates months in advance (and then want to punish you if those estimates were wrong), who want to commit to a plan and then follow it and then change it without changing the deadlines, .... > My e…

> since we still get people who want estimates months in advance Its almost like the real world has deadlines and interactions with 3rd parties who need to schedule things too.

I think the issue is in the intrinsic unpredictability of software development and secondly that Scrum is not even intended to help with that scheduling problem (it's meant to protect the developers schedule, not the clients schedule!).

What do I mean by those two claims?

The first, software development is inheritently unpredictable. To explain with an analogy, software development is more like writing a mystery novel than it is like building a house. In construction, the steps for each part are mechanical and the time to do so is well trodden and predictable. When a construction project starts, you can schedule the concrete trucks for specific days and generally be 99% right. Software development on the other hand is more liking writing a murder novel.

Rather than commiting to writing a novel which you then might not like, instead we say, "okay, we're going to show you each chapter after we write it and you'll reserve the right to change up the entire story entirely as you see each chapter that is written." That allows the customer things like: "ooh, I really like this secondary character, could we start writing them into the story more!"

From a requirements perspective, it's akin to film-making (film making is even more predictable than software development!!) - it's like getting the requirements: "write me a star wars prequel movie!", I then go off and do it and you get Jar-Jar binks - it's a shame to find that out all the way after the film has been made.

So, the main conflict I see is we are trying to use a process to say things like: "this book will be done in about 3 months [6 iterations, because we have estimated the product backlog and divided by a well known velocity, and we have even left time for unknown ops problems, bugs and even tech debt pay-down!]. At about the 2 month mark we can bring in the compliance and legal teams (or something like that)." Yet, all the Scrum process really allows is to give the client the right to change direction, it's not there to protect that 3 month time frame. Thus, the claim it's not meant to protect the clients schedule, Scrum is not there to protect that 3 month time frame (if anything it's there to help ensure that time frame can be adjusted [probably upwards] as the product develops)

In a way, it's like blaming the maps app for scheduling problems. The maps app can help, but inherently it's not there to make sure a meeting can start on time.

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

#95

Post by [deleted] »

sanderjd wrote: post #90
lylejantzi3rd wrote: post #89

Earlier quoted context omitted.

Similarly, if you were on my team, I'd probably fire you[0]. You have no self-awareness. You've doubled down on your flawed misinterpretation of my attitude, even though you've already admitted you came to that conclusion in error. You're the type of person who can't ever be wrong. That sort of thing is murder on morale. [0]: After multiple warnings, inevitable complaints from the other team members, efforts to help…

Edit to start with this: I think you're right that I was too hasty with my "you need to look in the mirror" comment, and this whole discussion would have gone better without that comment. So I'm sorry about that one! Ha, I sincerely doubt our higher-context interactions in an actual working environment would go the same way as our internet strangers with no context discussion. But it is definitely possibly that we wo…

[deleted]

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

#96

Post by nikau »

seadan83 wrote: post #94
nikau wrote: post #85

Earlier quoted context omitted.

> since we still get people who want estimates months in advance Its almost like the real world has deadlines and interactions with 3rd parties who need to schedule things too.

I think the issue is in the intrinsic unpredictability of software development and secondly that Scrum is not even intended to help with that scheduling problem (it's meant to protect the developers schedule, not the clients schedule!). What do I mean by those two claims? The first, software development is inheritently unpredictable. To explain with an analogy, software development is more like writing a mystery nove…

> From a requirements perspective, it's akin to film-making (film making is even more predictable than software development!!) -

Its actually the exact opposite - when making films they don't shoot the scenes in the sequence they are viewed, they will shoot every scene at the same location in one go due to the cost of setting up equipment, getting staff onsite etc.

The exact opposite of agile.

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

#98

Post by seadan83 »

nikau wrote: post #96
seadan83 wrote: post #94

Earlier quoted context omitted.

I think the issue is in the intrinsic unpredictability of software development and secondly that Scrum is not even intended to help with that scheduling problem (it's meant to protect the developers schedule, not the clients schedule!). What do I mean by those two claims? The first, software development is inheritently unpredictable. To explain with an analogy, software development is more like writing a mystery nove…

> From a requirements perspective, it's akin to film-making (film making is even more predictable than software development!!) - Its actually the exact opposite - when making films they don't shoot the scenes in the sequence they are viewed, they will shoot every scene at the same location in one go due to the cost of setting up equipment, getting staff onsite etc. The exact opposite of agile.

I was not very clear in that example. My intent was to use 'film-making' as a bit of an analogy for waterfall. IE: requirements are defined in the beginning and the end date is fixed. It would be a very different concept if after shooting each scene a potential audience could decide they want the whole thing up to that point to be re-done to tell a different story and that they want to change the ending every couple of weeks.

Scrum really jettisons a "final" date idea, which is something you have in movie-making. Scrum tries to optimize for reactiveness so that a correct product can be made, those potential changes in direction allowed by Scrum all add time to the final product being completed.

It's an interesting analogy I think overall because software development is viewed akin to construction of a building. On the spectrum of predictable schedules, movie making and construction are on the predictable sides of the spectrum, software development is way on the other side of that spectrum.

In short, when someone says "hey, in the real world we have things like 3 month deadlines. Using Scrum, we'll help ensure we hit that!". I just want to point out that Scrum is not a tool to help hit a 3 month deadline at all. It's just there to ensure that you don't commit to a 3 month deadline, build something that turns out to be the wrong thing and needs to be thrown away at that 3 month mark. It's actually a process to extend deadlines! Every 2 weeks you can get a change in direction that causes a one week (or more) of extra scope increase and/or churn or redoing previous work.

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

#99

Post by chinchilla2020 »

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.

It isn't. It's a basic wiki-style web UI. That's the whole point of things like sphinx and javadoc. All the documentation in your code is easily accessible.

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

#100

Post by lylejantzi3rd »

chinchilla2020 wrote: post #99
lylejantzi3rd wrote: post #58

Earlier quoted context omitted.

It's also only visible to developers.

It isn't. It's a basic wiki-style web UI. That's the whole point of things like sphinx and javadoc. All the documentation in your code is easily accessible.

And, as I've said in other places in this thread, it's not reasonable to force non-technical people to deal with your repo. Maybe that's where this whole conversation went off the rails. When I say documentation, I don't mean javadoc. I mean architecture diagrams and business reasons for what to build and why at a high level.
Post reply on HN