This thread is for general questions about agility in general and the book in particular. For questions/comments on the actual material in the book, please use the comments at the end of the individual posts. What I’m mostly after here is ideas about what to talk about, what I’ve missed, what I don’t need to talk about 😄, and general questions about the book and the process.
Hi Timothy. Sorry. The last couple months have been rough for me, but I'm starting to get back to work now. While I've got you, what topics are you particularly interested in? I've got my own list, of course, but it seems reasonable to "understand the customer's needs" rather than make something up 😄
Hi Paul, I'm doing a #No Keynote at at conference in London (sddconf.com) Tuesday (5/16/23). It will be recorded and I'll get a link to it up here as soon as it's available. All this is to say that I've finally got off my butt and will start writing for real 😄. Sorry about the delay.
Here’s a good one that I’m also diving into…the actual reason for agility. Not the history of the devs, manifesto, or user stories. The actual heart and soul behind why someone would want to be intentional about being lean an agile at home and work. I’ll keep my eyes peeled. Also, you get a tip of the hat for writing a book in the “Marty Cagan Way.”
Hi, are there any articles here? I just started second week as a PM and was hoping to read some of your stuff, but I’m not seeing anything. “No” indeed, lol
For me, the most undervalued aspect of "Agile" is the importance of habitable code. Because if the code don't wanna play nice, no amount of post-its and beanbags is gonna increase productivity.
Hi Allen, Are you planning to cover how can agility co-exist with cross cutting concerns that require analysis at the architecture level and traditionally done early on during the system lifecycle? For example security and functional safety?
I know that you're very opinionated about some actions or rituals that teams follow and you consider that are not actually agile. I think that most teams do things that lead to that "this is not completely agile" situation, ones more often than others. Do you think it's a good idea to include in the book some examples of scenarios where those actions are taken/followed and the impact you think they cause?
This is timely, as we're now (finally!!!) being intentional about process improvements across the value stream. Historically, we've had a waterfall planning process (100+ days is the average age of an issue in the backlog, and that's *after* lots of roadmapping, discussion, spec'ing, and design), then an "agile" engineering blip (average eng + code review + QA of two days), then a waterfall delivery process (zero automation, on a six week cadence, often longer for reasons), and almost no observability. We're making strides with automation, and running experiments on moving work downstream with less planning and more feedback for iteration. Our biggest concern now is, are we asking the right questions?
Hello Allen, Hope the writing is coming along well.
Throughout my career in Automotive Software, I have seen several persistent ideas come in to undermine Agility despite being well intended, for example:
- Setting up a Product Owner or Project Manager as "interface" to stakeholders and customers. This happens in companies that don't truly believe in transparency and are afraid of awkward interactions between "Engineers" and customers. So, they end up forcing engineers into playing telephone with the customer, rather than training them to become capable of managing stakeholder discussions (which I did many times and isn't that costly/time consuming).
- "The customer is always right" when the customer asks for a specific solution that doesn't make much sense and poses risks to the quality of the product. How might we bring the discussion back to the problem space so that engineers can figure out the optimal solution?
- Agility means we will build a solution in a (iterative + additive) manner: how might we avoid the discussion to end up to be dominated by Project Managers who are used to managing Scope+Time+Cost triangle and ending up with artificial "deadlines" and estimations? At the end of the day, the company has do decide whether investing a certain budget makes sense, but what's the alternative to writing down feature lists and due dates?
- When I talked to a Quality leader about how agility might help engineering bring money to the company from customers early on. He answered "Oh yes, they change their mind a lot. I said many times the solution is to have more up-front engineering and have solution architects write down technical requirements and baseline it". How do we deal with strong stakeholders who still think more upfront "engineering" will prevent changes from being costly?
Hi Timothy. Sorry. The last couple months have been rough for me, but I'm starting to get back to work now. While I've got you, what topics are you particularly interested in? I've got my own list, of course, but it seems reasonable to "understand the customer's needs" rather than make something up 😄
Hi Paul, I'm doing a #No Keynote at at conference in London (sddconf.com) Tuesday (5/16/23). It will be recorded and I'll get a link to it up here as soon as it's available. All this is to say that I've finally got off my butt and will start writing for real 😄. Sorry about the delay.
Here’s a good one that I’m also diving into…the actual reason for agility. Not the history of the devs, manifesto, or user stories. The actual heart and soul behind why someone would want to be intentional about being lean an agile at home and work. I’ll keep my eyes peeled. Also, you get a tip of the hat for writing a book in the “Marty Cagan Way.”
Hi, are there any articles here? I just started second week as a PM and was hoping to read some of your stuff, but I’m not seeing anything. “No” indeed, lol
For me, the most undervalued aspect of "Agile" is the importance of habitable code. Because if the code don't wanna play nice, no amount of post-its and beanbags is gonna increase productivity.
Hi Allen, Are you planning to cover how can agility co-exist with cross cutting concerns that require analysis at the architecture level and traditionally done early on during the system lifecycle? For example security and functional safety?
Hi
Looking forward to this book. I don't see any content here after a paid subscription. Is this still being used for delivery and discussion?
Congratulations on starting this book!
I know that you're very opinionated about some actions or rituals that teams follow and you consider that are not actually agile. I think that most teams do things that lead to that "this is not completely agile" situation, ones more often than others. Do you think it's a good idea to include in the book some examples of scenarios where those actions are taken/followed and the impact you think they cause?
This is timely, as we're now (finally!!!) being intentional about process improvements across the value stream. Historically, we've had a waterfall planning process (100+ days is the average age of an issue in the backlog, and that's *after* lots of roadmapping, discussion, spec'ing, and design), then an "agile" engineering blip (average eng + code review + QA of two days), then a waterfall delivery process (zero automation, on a six week cadence, often longer for reasons), and almost no observability. We're making strides with automation, and running experiments on moving work downstream with less planning and more feedback for iteration. Our biggest concern now is, are we asking the right questions?
Hello! I am new here. Any chapters available? I do not see any, maybe I am not yet used to the app. Thanks.
Immediately subscribed based on reputation. However, there does not appear to be much so far here. Compare with this: https://tidyfirst.substack.com/
(Sort of contradicts the intent to write the book in an agile manner.)
Allen any updates? Big fan, just hoping to see more content here, hoping I am not missing something
Hello Allen, Hope the writing is coming along well.
Throughout my career in Automotive Software, I have seen several persistent ideas come in to undermine Agility despite being well intended, for example:
- Setting up a Product Owner or Project Manager as "interface" to stakeholders and customers. This happens in companies that don't truly believe in transparency and are afraid of awkward interactions between "Engineers" and customers. So, they end up forcing engineers into playing telephone with the customer, rather than training them to become capable of managing stakeholder discussions (which I did many times and isn't that costly/time consuming).
- "The customer is always right" when the customer asks for a specific solution that doesn't make much sense and poses risks to the quality of the product. How might we bring the discussion back to the problem space so that engineers can figure out the optimal solution?
- Agility means we will build a solution in a (iterative + additive) manner: how might we avoid the discussion to end up to be dominated by Project Managers who are used to managing Scope+Time+Cost triangle and ending up with artificial "deadlines" and estimations? At the end of the day, the company has do decide whether investing a certain budget makes sense, but what's the alternative to writing down feature lists and due dates?
- When I talked to a Quality leader about how agility might help engineering bring money to the company from customers early on. He answered "Oh yes, they change their mind a lot. I said many times the solution is to have more up-front engineering and have solution architects write down technical requirements and baseline it". How do we deal with strong stakeholders who still think more upfront "engineering" will prevent changes from being costly?
Thank you!