4 ms·

I'm not an expert on this subject, but I feel like "agile" could be summarized as "a process for actively incorporating feedback early and often". That doesn't

I'm not an expert on this subject, but I feel like "agile" could be summarized as "a process for actively incorporating feedback early and often". That doesn't mean you need points or tshirt sizes or constant status meetings. You just need channels of communication with the right people and a chance to adapt to what they say.

beermonster 5y ago
This is a good one line summary. And it’s something that good devs will already be trying to accomplish anyway. There’s also the part about breaking stuff down into small parts so that small cycles of meaningful dev can be accomplished. But that’s mainly to be able to release small and often - another thing you should already be doing to incrementally update your app avoiding big releases. It also stands in the face of waterfall development, though I see lots of teams doing test at the end still, making it waterfally. I also see too many agile teams that have iterations that never finish, get feedback in prod, create half complete features that are weird or don’t gel - all in the name of agile. I think the kids that get it were already doing it as it’s common sense. The rest end up sticking an agile badge on their practices when it’s all but.
asplake 5y ago
That’s not a bad starting point. There’s more than one kind of feedback though! No matter how regularly you reflect on the process, if you’re ploughing through an unchanging backlog it’s still going to be a mediocre experience. Worse if the strategy keeps changing and you have no influence over it. Those unfortunately describe the experience of many - sometimes well-meant but an imbalanced and process-centric Agile with ironically little regard for the people doing the work.
jarl-ragnar 5y ago
This is how I see agile too. With it’s links to lean, it’s about minimising waste by minimising work in progress. Since the biggest waste is building something no-one wants, getting a small increment into the hands of a user/customer as soon as possible is key. The problem, in my experience, is many development contracts are still structured in such a way that this becomes too difficult. Management fearing early exposure to the customer will lead to scope creep and cost growth.
tablet 5y ago
I'd say agile is more about "shortening feedback loops" everywhere.
TameAntelope 5y ago
You need <anything> because of the hostile nature between the creator and the patron of the creator. The patron wants more, the creator doesn't want to create more, so you need to force a detente so the patron will continue to pay the creator, and the creator will continue to produce. You get t-shirt sizes and points when the patron feels the creators aren't doing what they said they'd do, so in a way it's a communication problem, yes, but the cause of the communication problem is that there is almost never an alignment between the two groups, and so you need some kind of shared language where expectations can translate, and accountability can exist at all, usually in some flawed form.

beermonster 5y ago

This is a good one line summary. And it’s something that good devs will already be trying to accomplish anyway. There’s also the part about breaking stuff down into small parts so that small cycles of meaningful dev can be accomplished. But that’s mainly to be able to release small and often - another thing you should already be doing to incrementally update your app avoiding big releases. It also stands in the face of waterfall development, though I see lots of teams doing test at the end still, making it waterfally. I also see too many agile teams that have iterations that never finish, get feedback in prod, create half complete features that are weird or don’t gel - all in the name of agile. I think the kids that get it were already doing it as it’s common sense. The rest end up sticking an agile badge on their practices when it’s all but.

asplake 5y ago

That’s not a bad starting point. There’s more than one kind of feedback though! No matter how regularly you reflect on the process, if you’re ploughing through an unchanging backlog it’s still going to be a mediocre experience. Worse if the strategy keeps changing and you have no influence over it. Those unfortunately describe the experience of many - sometimes well-meant but an imbalanced and process-centric Agile with ironically little regard for the people doing the work.

jarl-ragnar 5y ago

This is how I see agile too. With it’s links to lean, it’s about minimising waste by minimising work in progress. Since the biggest waste is building something no-one wants, getting a small increment into the hands of a user/customer as soon as possible is key. The problem, in my experience, is many development contracts are still structured in such a way that this becomes too difficult. Management fearing early exposure to the customer will lead to scope creep and cost growth.

tablet 5y ago

I'd say agile is more about "shortening feedback loops" everywhere.

TameAntelope 5y ago

You need <anything> because of the hostile nature between the creator and the patron of the creator. The patron wants more, the creator doesn't want to create more, so you need to force a detente so the patron will continue to pay the creator, and the creator will continue to produce. You get t-shirt sizes and points when the patron feels the creators aren't doing what they said they'd do, so in a way it's a communication problem, yes, but the cause of the communication problem is that there is almost never an alignment between the two groups, and so you need some kind of shared language where expectations can translate, and accountability can exist at all, usually in some flawed form.