Bug Status [3/11]

[Scarecrow71]

@The Aziz, @kdaviper

You both missed the intent of my question.  I'm not questioning what bug reports are for.  I'm questioning why it was closed without giving the reason why. I'd also like to know why, if the community is providing feedback on this issue AND it was originally reported as a bug, why is it simply listed as "Working as designed" when Dakota stated that this is merely meant to be "We are looking for feedback".  The community gave feedback, but the bug report is in the archive without any further discussion.  This is what leads to the community thinking "They implemented this, don't care, and aren't changing it".

[Dakota]

9 hours ago, Scarecrow71 said:

@The Aziz, @kdaviper

You both missed the intent of my question.  I'm not questioning what bug reports are for.  I'm questioning why it was closed without giving the reason why. I'd also like to know why, if the community is providing feedback on this issue AND it was originally reported as a bug, why is it simply listed as "Working as designed" when Dakota stated that this is merely meant to be "We are looking for feedback".  The community gave feedback, but the bug report is in the archive without any further discussion.  This is what leads to the community thinking "They implemented this, don't care, and aren't changing it".

This was moved to the archive for a similar reason. It is working as intended, but we'll evaluate the reports (and suggestions) as feedback.

This was explained with the status in the 1/12 K.E.R.B.:

Quote

The current behavior is how it was designed. We will consider the feedback.

There is more context in the replies as well, including Nertea's and Nate's thoughts on CommNet.

-

And again, bug reports and K.E.R.B.s are not meant to be used for feedback about gameplay. That's what the suggestions subforum is for. There are many threads in there asking for both CommNet features and maneuver node improvements.

[Flush Foot]

@Dakota, when you feed us the lions regularly, we're they're (probably / hopefully) less likely to snap at you 

[Scarecrow71]

22 minutes ago, Dakota said:

And again, bug reports and K.E.R.B.s are not meant to be used for feedback about gameplay.

Well, it was initially reported as a bug because it wasn't known that it was designed that way.  And the bug report was closed without indicating why in the bug report itself.  I get that it ended up in the KERB, but people aren't going to go combing through each KERB to see the status of a given bug they may be following.

[Flush Foot]

4 hours ago, Tooch__ said:

Why do I need to somehow pan my camera over to the part of the main trajectory in order to place a node rather than just doing it when im focused on the target?

Worse / weirder still is that it seems (to me, anyways) as if even upon planting that "next-SOI plan" by panning the camera into position, the prograde/retrograde/other markers on the planner do not correspond to pro/retro in that SOI but instead they're related to your current SOI's vectors.

Still looking forward to the day that stock-planner bestows upon us the gift of future-orbit planning (without having to timewarp into the future to see if 'now' is the best time to try a burn).

[kdaviper]

18 minutes ago, Scarecrow71 said:

Well, it was initially reported as a bug because it wasn't known that it was designed that way.  And the bug report was closed without indicating why in the bug report itself.  I get that it ended up in the KERB, but people aren't going to go combing through each KERB to see the status of a given bug they may be following.

Thank you for elaborating. I see your point much clearer now

[NoMrBond]

Does a sprint now mean potentially 0.2.2 mid April?

Without making any promises or guarantees of course

[Ruedii]

On 3/12/2024 at 3:41 AM, ShadowZone said:

I just have to add my voice to the people asking for #20 to switch from "works as intended" to "redesign going on based on player feedback".

It hampers more complex trajectory planning, same as the choice to limit maneuver nodes to stop working when exceeding the calculated dV of the active vehicle (which can be demonstrably wrong often times).

Please change this!

In modern software development and especially when using a framework called "Scrum", the development team works in short increments, usually 2 to 3 week cycles called "sprints". At the beginning the team pulls from a prioritized backlog what they believe they will be able to achieve during the coming 2 weeks. The backlog is usually prioritized by a product owner based on business value (based on answering the question: what will provide the most value to the customers/users of the software?).

This process of picking the body of work for the next sprint and committing to it is called sprint planning.

After a sprint, the development team presents their results and gathers feedback and after that usually sits down and discusses what went well and what could be improved in the upcoming sprints.

Switching to these shorter development cycles enables software companies to get feedback faster and improve on software faster than working months or years in the blind and then having to rework a metric ton of code at once if they realize they messed up a foundational feature.

 

At least that's the theory. Most software companies/teams use some variant of this process.

Yes, the most common one is small bugs and high priority bugs are done AGILE, roadmap is planned Waterfall/Cascade, and implementation of major patches and roadmap steps is done SCRUM. 

AGILE does not work well with roadmap as it results in a constant moving target, but it works well with smaller and high priority bugs.  Leaning too much into AGILE planning methods will result in the project losing focus (e.g. KSP2 under the initial management team) but not embracing it enough will result in a lag between simple but game-breaking bugs from being fixed.  It is a balance to do things right, and generally multi-methodolgy is the way to go.

[ShadowZone]

6 hours ago, Ruedii said:

Yes, the most common one is small bugs and high priority bugs are done AGILE, roadmap is planned Waterfall/Cascade, and implementation of major patches and roadmap steps is done SCRUM. 

AGILE does not work well with roadmap as it results in a constant moving target, but it works well with smaller and high priority bugs.  Leaning too much into AGILE planning methods will result in the project losing focus (e.g. KSP2 under the initial management team) but not embracing it enough will result in a lag between simple but game-breaking bugs from being fixed.  It is a balance to do things right, and generally multi-methodolgy is the way to go.

 

Very hard disagree on this.

Whoever taught you that Agile is something that you can do or that is a methodology or framework like some kind of cooking recipe, was selling you snake oil. The Agile Manifesto is over two decades old and people apparently still haven't understood it - or are deliberately misrepresenting it. It's far more fundamental: Either you (meaning your organization) are agile or you are not. If your work adheres to the twelve principles outlined in the manifesto (or at least most of them), then you are agile, no matter what framework you are using to structure your work. Scrum is just a methodology that developed from the agile way of thinking. But you can be agile doing Kanban or XP or yes, in parts even waterfall.

I have done long term projects in an agile environment with a team doing Scrum. Notice the difference: the environment (the organization, the system within which you act) IS agile (meaning it and the people within it follow the principles). The team is DOING Scrum. There are a gazillion teams out there doing Scrum but that are not agile. They go through the motions, they work in sprints, but it's all meaningless and in the end these teams end up going over budget, over time and not meeting their goals and everyone is wondering why.

So how did we do long term planning ("roadmaps" if you will) with Scrum? It all boils done to setting the correct goals, rigorous prioritization and constant application of the maxim "inspect and adapt". Instead of meticulously defining what the OUTPUT should be, the long term strategy must focus on OUTCOMES. Which is why the role of the Product Owner is so important when you are working within the Scrum framework. This role has to constantly prioritize the backlog according to the desired outcomes. The dev team is responsible to generate the output that iteratively gets the software towards the desired outcome.

In the end, the customer does not care about waterfall, scrum, kanban, whatever. They want to be able to reach their business goals and the software you produce needs to enable them to do so. Most customers engage in the fallacy of coming up with specific features and asking developers to implement those instead of saying "I have this problem that I need solved" and the specialists, the software developers, take care of the solution. I mean, nobody goes to the doctor and says "I need you to perform procedure xyz on me". No, you go to the doctor because you have some weird symptoms and want them to go away. The same thing needs to be applied to software development. Detailed upfront specifications are mostly done to reassure everyone that things can be planned in a world that is very unpredictable and ever changing. "No plan survives first contact with the enemy", as the old saying goes. As soon as the customer sees the first draft, they will want to change something. Having an Agile mindset enables your organization to adapt to this type of changes instead of slavishly following a rigid plan. In the end the goal must be to deliver the highest possible value within your software. 

[modus]

37 minutes ago, ShadowZone said:

I have done long term projects in an agile environment with a team doing Scrum. Notice the difference: the environment (the organization, the system within which you act) IS agile (meaning it and the people within it follow the principles). The team is DOING Scrum. There are a gazillion teams out there doing Scrum but that are not agile. They go through the motions, they work in sprints, but it's all meaningless and in the end these teams end up going over budget, over time and not meeting their goals and everyone is wondering why.

Oh yes, so much yes.

I've heard many times (I work for a local government in europe), especially by external consultants, 'we're going to do this agile'. Uh no, you want to use scrum or some kind of variant. We are not agile, so don't pretend.

Same goes for some of the managers in the organization. 'Try to be agile'  when they want to keep the budget in check. Uh no  because we are not agile. I can try to be, but as long as we as a whole are not, don't pretend.

[Jaypeg]

On 3/14/2024 at 1:19 AM, Tooch__ said:

Seriously??? I gave KSP2 another try recently and 30 hours in that is easily number 1 or 2 on the list of things that have been annoying me the most. Whole maneuver system needs a full overhaul in my personal opinion.

Maneuvers were really clunky and obnoxious to use without mods in KSP1. I was really hoping that KSP2 would be improving the system but somehow its even worse

seems like they are working on it

[Scarecrow71]

2 hours ago, Jaypeg said:

seems like they are working on it

Which they claim to have been doing since the game dropped a year ago.  It really is time for the team to take the community seriously and work on the stuff we have been complaining about the most.  A year for the downgrade at maneuver nodes is simply uncalled for.

[herbal space program]

On 3/11/2024 at 11:51 PM, Darta01 said:

 

20	Can't create a maneuver node within another SOI	Working as intended. Evaluating as feedback

Reading through the comments so far I know I'm just piling on, but truly there are not enough rotten tomatoes in the world to provide sufficient feedback about this being an intentional feature. What gives? Why do you hate us so much? In KSP1, I would often plan  three maneuvers ahead, all in different SOI's. Losing that functionality is a major pain in the end that should not point towards space, and while I can be patient about waiting for somebody to create it, the idea that it might never be possible is demoralizing.

[magnemoe]

12 hours ago, herbal space program said:

Reading through the comments so far I know I'm just piling on, but truly there are not enough rotten tomatoes in the world to provide sufficient feedback about this being an intentional feature. What gives? Why do you hate us so much? In KSP1, I would often plan  three maneuvers ahead, all in different SOI's. Losing that functionality is a major pain in the end that should not point towards space, and while I can be patient about waiting for somebody to create it, the idea that it might never be possible is demoralizing.

This, the most obvious use case is to check that you can circulate at target, or what cost, Yes you have the intercept velocity but cost to reach low orbit is not the same on large bodies like Eve. 
Second use is setting up an more complex operation like Tylo braking with resulting Jool orbit to intercept outer moons. 

Like me sending landers to Eve, was not sure if I could circulate, turned out to be cheaper than expected so did not need the tanker. 

Edited March 19 by magnemoe

[herbal space program]

10 hours ago, magnemoe said:

This, the most obvious use case is to check that you can circulate at target, or what cost, Yes you have the intercept velocity but cost to reach low orbit is not the same on large bodies like Eve. 
Second use is setting up an more complex operation like Tylo braking with resulting Jool orbit to intercept outer moons. 

I actually have 5 probes currently inbound at Jool, and I found it extremely annoying that I could not place nodes in the Jool SOI for these probes while they were still in the Kerbol SOI. If for no other reason, I want those nodes there so that I am reminded in the tracking station to attend to those craft at the right time, which becomes quite complex when you've got 10 missions going at the same time as I do now. As it is now, the tracking station doesn't even show you your future nodes for a given mission when you when you click on it, which makes juggling multiple interplanetary missions much harder.

[Fizzlebop Smith]

7 minutes ago, herbal space program said:

I actually have 5 probes currently inbound at Jool, and I found it extremely annoying that I could not place nodes in the Jool SOI for these probes while they were still in the Kerbol SOI. If for no other reason, I want those nodes there so that I am reminded in the tracking station to attend to those craft at the right time, which becomes quite complex when you've got 10 missions going at the same time as I do now. As it is now, the tracking station doesn't even show you your future nodes for a given mission when you when you click on it, which makes juggling multiple interplanetary missions much harder.

This is exactly why i upvoted the issue. 
The game immediately ram rods you into travelling beyond Kerbins SOI but fails to adequately equip you with the tools to do so.

My in game DV calculator was slightly off with regard to staging, and burn calcs. I executed a couple maneuver's less than optimally..  3 times i attempted to circle moho with some probe systems. All three attempts failed. 

Number 4 i over engineered the living dickens out of my rocket and achieved success. I have a hard a time comprehending this as a conscious choice, but more of an effort to divert attention to things more easily addressed?
Havent a clue why anybody would consider this to be the natural evolution as KSP1s successor.

I may not have been able to figure all the quirks out by launch number 2, but would have been much better equipped if I could at least test maneuvers prior to entering an SOI

[Jaypeg]

23 hours ago, herbal space program said:

Reading through the comments so far I know I'm just piling on, but truly there are not enough rotten tomatoes in the world to provide sufficient feedback about this being an intentional feature. What gives? Why do you hate us so much? In KSP1, I would often plan  three maneuvers ahead, all in different SOI's. Losing that functionality is a major pain in the end that should not point towards space, and while I can be patient about waiting for somebody to create it, the idea that it might never be possible is demoralizing.

I feel there is a bit of a miscommunication between what they say "working as intended" means and what the community takes it as meaning. Simply put, in gamedev and how they mean it it actually just means "we designed it to work this was as a compromise/for the moment".  Not a complete engineering decision. Same as commnet. They want to add it but the system they have now works well enough and is designed to work in the way it does, but will be replaced later.

 

On 3/19/2024 at 11:07 AM, Scarecrow71 said:

Which they claim to have been doing since the game dropped a year ago.  It really is time for the team to take the community seriously and work on the stuff we have been complaining about the most.  A year for the downgrade at maneuver nodes is simply uncalled for.

agree, sadly, but its workable enough. There is a mod for it if you want though

[herbal space program]

24 minutes ago, Jaypeg said:

I feel there is a bit of a miscommunication between what they say "working as intended" means and what the community takes it as meaning. Simply put, in gamedev and how they mean it it actually just means "we designed it to work this was as a compromise/for the moment".  Not a complete engineering decision. Same as commnet. They want to add it but the system they have now works well enough and is designed to work in the way it does, but will be replaced later.

Well if that's what it really is, then I'm fine with it. I said as much upthread. They just need to know in no uncertain terms that they have to make this feature work better ultimately, and not leave it in the lousy state it's in now. "Working as intended" does not communicate that so well. It should really be something more like "Not fully implemented yet" or "Still under development". That way we won't think they just hate us and want the game to fail so they can move on to the next thing.

 

 

 

[Fizzlebop Smith]

This is a huge division among members of the community ATM. 

Well enough, is a subjective matter. I play with mods and feel KSP1 stands on the success of its modding community. 
However, i personally feel there is a level of expectation when following a game, but with so many features that feel worse.  Even though i play with mods, i feel the game should have the ability to stand on a vanilla build. The UI regarding orbital manuevers, in general, is extremely lackluster compared to what was already in place. 

I  fully understand stop gap measures and using them. Too much of this game is dependent on using orbital maneuvers successfully. Eventually they intend us to plot extra solar trajectories. They *push* you to leave Kerbolar SOI very quickly. Yet the maneuver UI is fundamentally unusable without the mods to assists.

This is only my opinion, but i have an incredibly difficult time not getting the planets to spin like crazy when trying to slight adjust camera angle,
The majority of the time the node indicators on the node itself are completely eclipsed and do not persist on forefront,
I cannot select celestial bodies that i have a relay around,
I cannot create nod inside another SOI,

I can go on about the things that others have articulated far better than I. Why was something so foundational to the game not weighted with more importance pre-development. Why did they not "communicate" with the community when deciding to completely overhaul the maneuver system?  Why did they not seek feed back when deciding to ditch all orbital info that was once available?

I love the franchise and will be a die hard fan even if the game goes to spit. I know the modders will save it. But i am consumed with frustrations and want to voice them in what i feel is a constructive manner.

By offering suggestions on what needs to be fixed and how i feel it could be better.

I wish more people would just offer alternative opinions about these things instead of telling me i don't understand whats going on, or just be patient, stop complaining about the game.. they don't need to hear that


If The devs will stop communicating if we give negative feedback, then the EA was not really the goal.

"You dont need more mission content in a mode they proposed was to completely replace the mission mode, you should enjoy flying ships and all the great sand boxy ness."
 

Edited March 20 by Fizzlebop Smith

[Superfluous J]

12 minutes ago, Fizzlebop Smith said:

If The devs will stop communicating if we give negative feedback, then the EA was not really the goal.

I agree with most everything you said, but I'd like to clarify:

The devs don't mind NEGATIVE feedback. The problem is NON-CONSTRUCTIVE feedback.

A lot of the details in this very thread are great constructive feedback. Detailing why it's important to be able to make a node in Jool's SOI when you're in Kerbol's SOI is great feedback.

People foaming and complaining that the devs don't care and they ruined KSP and why did it take years for this garbage - no matter how much better you feel after saying it and no matter how reasonable it may (or may not ) be - doesn't help one lick and if 99% of the feedback is like that, yeah I'd ignore it too.

[Ruedii]

On 3/17/2024 at 4:07 AM, ShadowZone said:

 

Very hard disagree on this.

Whoever taught you that Agile is something that you can do or that is a methodology or framework like some kind of cooking recipe, was selling you snake oil. The Agile Manifesto is over two decades old and people apparently still haven't understood it - or are deliberately misrepresenting it. It's far more fundamental: Either you (meaning your organization) are agile or you are not. If your work adheres to the twelve principles outlined in the manifesto (or at least most of them), then you are agile, no matter what framework you are using to structure your work. Scrum is just a methodology that developed from the agile way of thinking. But you can be agile doing Kanban or XP or yes, in parts even waterfall.

 

OK, let me put it simply, Agile purists are the absolute worst hypocrites in software. 

Following a specific manifesto and process as a means to complete software is a clear contradiction of Principal 2, and 12.  Not adapting your development workflow and priorities and instead staying on a fixed set of priorities is against the very principals of Agile.  So entering new methodologies, setting teams on other methodologies, is important. 

Furthermore, Agile's 12 principals are seriously in contradiction to each other, because 6 assumes everyone works in the same way favoring face to face contact, but 5 says everyone should work in an environment best suited for them.

I for one do NOT communicate best in face to face contact.  I find this sort of generalized broad brush fallacy a sham, which is exactly why you should never subscribe to a single management philosophy, lest you lose the ability to adapt to your fellow team members, and the needs of the project.

I should say you should do an agile inspired methology with some things.  You need to do much more rapid cycles and much more frequent changes to requirement in certain aspects of development.   Fixing bugs and limitations are one of them. Honestly, the vast majority of Agile theory is extremely effective at triaging and addressing common bugs and limitations.

However, Agile is also very short-sighted and many functions require things it frowns on.  For instance, forking a team and the codebase to add something that will take a lot of time.   I find it one of those things managers come up with that don't really understand how programming and codebases work.  Many major key items require a very large amount of base code and invisible background features.  Agile is not very accommodating to the development of such code.

When managing the roadmap you can take some inspiration from Agile.  Determining what features should be delayed or canceled to get a new feature put in the roadmap is very consistent with agile. 

Simply put, while it's a good theory to learn, it is rather short-sited, and broad brush to think it has to be applied to everything.   Additionally, claiming it should be applied to everything is hypocritical in that it expressly says you need to adapt to the needs of your team and your clients.  Sometimes what your team and clients need is not something Agile will provide, in which case you need to introduce other management and methodology theories.

[ShadowZone]

7 hours ago, Ruedii said:

OK, let me put it simply, Agile purists are the absolute worst hypocrites in software.

Amen to that. Fundamentalists of any kind should be treated with caution. To stick with my earlier wording, these people are just selling you a different kind of snake oil

Quote

Following a specific manifesto and process as a means to complete software is a clear contradiction of Principal 2, and 12.  Not adapting your development workflow and priorities and instead staying on a fixed set of priorities is against the very principals of Agile.  So entering new methodologies, setting teams on other methodologies, is important.

I like to say that they're principles, not commandments. Or to quote Jack Sparrow (sorry, Captain Jack Sparrow), "they're more like ... guidelines". The whole idea behind the agile movement (or at least, the value that I personally took from it) is to make things more flexible and to be able to react to a constantly changing situation. If you try to force everyone to follow a rigid set of rules (and remember: rules != principles), then you are not agile, no matter mow many Scrum Alliance certifications you paste onto your LinkedIn page.

To me, it boils down to the axiom of "inspect and adapt", which coincidentally is also reflected in principle 12. So yeah, people that try to "make you agile" by prescribing certain processes or try to prevent you from coloring outside the lines are oftentimes making things worse.

When in doubt, refer to principle 1: is what you are doing helping you to deliver valuable software to your customer? The trick here is how to measure whether or not you're actually doing that.

Quote

Furthermore, Agile's 12 principals are seriously in contradiction to each other, because 6 assumes everyone works in the same way favoring face to face contact, but 5 says everyone should work in an environment best suited for them.

I for one do NOT communicate best in face to face contact.  I find this sort of generalized broad brush fallacy a sham, which is exactly why you should never subscribe to a single management philosophy, lest you lose the ability to adapt to your fellow team members, and the needs of the project.

I don't see the contradiction, because 5 and 6 are aimed at different aspects of a software development organization. Principle 5 is more aimed at upper management and how to treat your employees (especially the "trust them to get the job done" part. Oh boy, did I have heated discussions with managers about that one...). Principle 6 is more aimed toward the day to day operations. But you have to acknowledge the time the manifesto was created in, more than 23 years ago. Kent Beck's "Extreme Programming" was only released two years earlier, bringing the concept of "pair programming" to a wider audience (yeah, it had existed decades earlier, but Beck popuralized it).

For me, there's a two key things in principle 6:

• efficient and effective method of conveying information
  • to a development team
  • within a development team

Me as a product owner, I'm responsible for the "to a team" part. In my experience, the most efficient way of explaining a feature, or a problem the customer has, is to sit down with the devs and have a conversation about it. The best outcome is when I get a gazillion questions and we can refine the item there on the spot with everyone walking away with the same understanding of what needs to be done. While principle 6 states "face to face", I have had good results with doing it via Teams/Zoom/etc and collecting everyone's input and thoughts on a digital white board (I'm a "drawer & pacer", I need to scribble on a whiteboard and walk around constantly when I'm thinking. I rarely have my camera on in remote meetings because I'm pacing up and down the office or my living room when I'm talking). Again, the manifesto was written almost a quarter of a century ago. They didn't have our means of communication. E-Mail was laggy, chat was minimalistic (yes, I remember and was part of various IRC servers in the Nineties), phone was cumbersome.

I know people who prefer writing meticulous JIRA tickets. I have had colleagues who recorded their "tickets" as a video and upload them as attachments to the relevant JIRA issue. It all boils down to this: "are you practicing an efficient and effective method of conveying information"? But it has to go both ways: just because that product owner likes to record videos does not mean the dev team is able to distill their tasks from it. Is has to work for both sides.

The signatories of the manifesto wanted to break the death spiral of "throw a spec over the fence, write dozens of e-mails back and forth until you really find out what needs to be done". To come back to the "inspect and adapt" part: if you and your co-workers are comfortable with the current way you communicate AND it enables you to be effective and efficient, then you do you. As before, the question is: how can you measure whether or not this is the case? A dev team might feel good about themselves, but they can still be inefficient and therefore not delivering valuable software early and continuously (principle 1).

Quote

I should say you should do an agile inspired methology with some things.  You need to do much more rapid cycles and much more frequent changes to requirement in certain aspects of development.   Fixing bugs and limitations are one of them. Honestly, the vast majority of Agile theory is extremely effective at triaging and addressing common bugs and limitations.

However, Agile is also very short-sighted and many functions require things it frowns on.  For instance, forking a team and the codebase to add something that will take a lot of time.   I find it one of those things managers come up with that don't really understand how programming and codebases work.  Many major key items require a very large amount of base code and invisible background features.  Agile is not very accommodating to the development of such code.

I fail to see see how forking a team and code base has anything to do with the principles behind the agile manifesto. There's nothing in there that says "you need to do x" or "you have to use tool set y".

You mentioned things that "take a lot of time". If you have features that cannot be done within the confines of a single sprint, you have two options: preferably, put your heads together and try to split the item into more easily digestible chunks that chain together over the course of multiple sprints, or - less preferable - carry an issue over multiple sprints. Over the course of my career, I rarely had the latter situation. Yes, it can happen, but only after you made sure there's no other way.

Also, sprint cycles and release cycles do not necessarily have to be aligned. You can have two week sprints but release only every three months.

If I ever get into the unfortunate position of being a manager, I would be completely hands off about key development tasks like how to set up your code base or branching strategy or whatever. YOU as developers need to be able to work with the tools available, not me. If you have the plumber come over, do you lord over him and say: "No, don't use the wrench, use the screwdriver, I read that in a book ten years ago."? No, you don't. You trust the specialist that they know that the heck they are doing.

Coincidentally what you describe, managers interfering into direct dev work, is in contradiction to principle 5. They don't trust you to get the work done, so they mess with the environment because they (wrongly) believe they know better.  Screw those people!

Management needs to get out of the way of day to day development (principle 5), the team needs to figure out how to best deliver themselves (follow principle 12 to be able to live up to principle 1). This is why the Scrum Master role is so important. They need to keep overbearing managers in check but also need to make the dev team really inspect how things are going and help them figure out what to adapt to constantly improve (which is in line with the Deming cycle and Kaizen both of which were inspirations for the agile manifesto).

Quote

When managing the roadmap you can take some inspiration from Agile.  Determining what features should be delayed or canceled to get a new feature put in the roadmap is very consistent with agile. 

Simply put, while it's a good theory to learn, it is rather short-sited, and broad brush to think it has to be applied to everything.   Additionally, claiming it should be applied to everything is hypocritical in that it expressly says you need to adapt to the needs of your team and your clients.  Sometimes what your team and clients need is not something Agile will provide, in which case you need to introduce other management and methodology theories.

From what you write I get the feeling you have a more agile mindset than you give yourself credit, especially the way you recognize that organizations need to be flexible and structure themselves to be able to react to change and offer a good environment for developers. These are some of the most important aspects behind the agile manifesto.

But your final paragraph talks about methodology and application. As I said in my previous post, the principles are none of those, but just what they say the are: principles. They should be a guiding light to how you organize your work. Some of them might shine brighter for you than others. All of them need to be interpreted and adapted for your use case. I have heard of companies building ships that have adapted their work to incorporate the principles.

One big pitfall is what I repeatedly said about "how can you measure that". This is where most organizations start to flounder, because they often fall back into command & control rythms or try to create a tight noose around everyone with some KPI, OKR and whatever fancy management metric they come up with next. People like safety and large Excel files with a lot of numbers give the illusion of being able to control the chaos when in fact you can't often times. One of my other pet peeves I regularly have heated discussions about with our management staff.

Another pitfall is scaling. The manifesto is geared towards a single team working together but nowadays you often have large organizations with multiple teams. Along came LeSS, SAfE, CAS etc to muck things up even further, selling the illusion of a "one size fits all" framework you can put to your company. Snake oil, all of them.
History time: I was in a well functioning development organization that managed to implement a custom scaling strategy based on scrum and following the agile principles. It was not perfect, but it worked for us most of the time. Then we got new management and they immediately needed to mess things up by forcing SAfE onto us. We were forced into a box, nobody really liked or understood and the end result was less efficient development, lots of dissatisfaction which led to long time employees leaving but management still selling it as a success because THEIR plan was implemented. Textbook failure of principle 5 and also 12. We didn't inspect and adapt, we followed a fixed plan, to everyone's detriment.

In closing, I just want to say I really appreciate this discussion, even if I disagree with you on some counts. This is how we can move the conversation forward how to best organize software development work. Maybe someone from the KSP2 dev team takes note and can pull something out of this for them to improve how they do things

Edited March 20 by ShadowZone

[Jaypeg]

21 hours ago, herbal space program said:

Well if that's what it really is, then I'm fine with it. I said as much upthread. They just need to know in no uncertain terms that they have to make this feature work better ultimately, and not leave it in the lousy state it's in now. "Working as intended" does not communicate that so well. It should really be something more like "Not fully implemented yet" or "Still under development". That way we won't think they just hate us and want the game to fail so they can move on to the next thing.

 

 

 

yeah. Its just an issue between tech/indurstry speak and what people usually expect.

[Ruedii]

21 hours ago, ShadowZone said:

In closing, I just want to say I really appreciate this discussion, even if I disagree with you on some counts. This is how we can move the conversation forward how to best organize software development work. Maybe someone from the KSP2 dev team takes note and can pull something out of this for them to improve how they do things

Yes, I agree.  It seems we are actually on the same page, and you misinterpreted what I meant by "Do agile"

Yes, I meant the full philosophy of cyclic feedback, not just going through the motion, and also to be adaptive on it.  It seems we both have the same beef with the people who take agile philosophy too by the book and not enough as a philosophy.

At the time Agile was created, before it became popular, there were not tools to have proper conversations in notes, so I absolutely understand the face to face thing.    I find it annoying when people take that concept of face to face so literally.

While I don't have a team, per say, I regularly work with bug reports of my interest on open source projects.  I do have one open source project feature that I've been considering undergoing since.  I commonly use a hybrid approach that does consider Agile principals as key values.  Keep everyone in the loop as to what you do and plan to do.   Inform people of your next steps and what the current blockers are.  Receive and consider feedback, and provide more information as necessary, then go back and repeat at the predetermined time.   This often is waiting on someone else's dev cycle, of course, since for volunteer work I don't have time for an intense cycle on every GIT commit relevant to my bugs.

 

[Sade]

I'm ready to receive those 0.2.2 fixes. So thanks for waiting for me, but you can release it now.