4 ms·

"Is [Huge pile of recently promoted buzzwords] not the silver bullet you expected? We've got the answer: [A new pile of buzzwords]!" Does your team produce pro

by apeace 9y ago

"Is [Huge pile of recently promoted buzzwords] not the silver bullet you expected? We've got the answer: [A new pile of buzzwords]!" Does your team produce products on-schedule 100% of the time, receive positive reviews from customers, and consistently generate more and more revenue for the company? In my experience, a big part of what a team works on is making these things happen consistently, and then maintaining that consistency as you add members. Your reaction suggests to me you haven't spent a lot of time thinking about how engineering teams work and scale. Sure, software engineering is easy given a couple constraints: - Everyone on your team is on the same skill level, and everyone communicates well naturally - The problems you're solving are small, the system you're building is not complicated, and in general there isn't tons of work to do But if those things aren't true, it's harder to scale a team, and the type of stuff in this article is really useful. There are teammates who are weak in certain skills and stronger in others. Bottlenecks arise. There are people in the company who want to take control of the product and drive it in an unproductive direction. There are departments who provide a constant flow of small/medium requests, and departments who once-per-quarter request a large feature. There are valuable customers who don't quite fit into the model your product supports. Agility helps you react to all of these things and fix them quickly. I think this article stands apart from the rest in that it emphasizes team learning. There is only one diagram, and it's about things you can get good at, not steps you should follow. Nobody is blindly reading this and following the steps (because there aren't really steps, if you read it). It exists to help build a common language and encourage thinking about how you can learn and get better. What's wrong with that?

jmull 9y ago
Well, I've been developing software for more decades that I'd like to admit, so I've engaged all the issues you mention (and many more). However, the fact that these problems exist doesn't mean this agile fluency model has anything to do with solving them. Generally, my problem with this model is that it's arbitrary, vague and subjective. You, your team, and other stakeholders will need to take the time to learn the model, restate your issues in terms of the model and then... what? Even then, what steps or anything else actionable could result? In fact, the agile fluency model itself is pretty daunting, what with all the new terminology (all based on terms that are already massively overload, of course). We'd probably need an Agile Fluency Model Fluency Model, so we can label and discuss the stages of learning and applying the agile fluency model itself.

by apeace 9y ago

jmull 9y ago

Well, I've been developing software for more decades that I'd like to admit, so I've engaged all the issues you mention (and many more). However, the fact that these problems exist doesn't mean this agile fluency model has anything to do with solving them. Generally, my problem with this model is that it's arbitrary, vague and subjective. You, your team, and other stakeholders will need to take the time to learn the model, restate your issues in terms of the model and then... what? Even then, what steps or anything else actionable could result? In fact, the agile fluency model itself is pretty daunting, what with all the new terminology (all based on terms that are already massively overload, of course). We'd probably need an Agile Fluency Model Fluency Model, so we can label and discuss the stages of learning and applying the agile fluency model itself.