what about being clear (quantification rather than blah blah) about the higher priority improvement you expect from a project? and on that basis asking, at every sprint, did we move towards our goal? If not what must we change?
well, 'talking to' is maybe not the best way to discover their values. Listening to, and observing, sound more productive. A real agile way is to deliver some improvements and listen to them about that, and see how they react to it, and then pivot if necessary (agile, you know). BTW Customers is one interesting segment we serve, but consider the other 50 stakeholders (like users, financier, potential customers).
This is an easy one for me since I'm working on a solution to what I believe is the new problem statement:
“How do we integrate distributed business, design, and technology disciplines to deliver valuable software competitively and accurately?”
We're in a world today where context is fragmented in “user story” tickets, and high bandwidth communication is fading into a past where co-located teams can be in the same space without getting video call fatigue.
High context and communication are present in all high performance teams. Any new solution needs to address these two fundamental aspects.
I think it's really cool that you're working on this. Let me know if you would like a chat.
I appreciate where you're headed with your statement. But I immediately miss the "good for teams" part of the original manifesto. Moving forward, I think that focus is crucial. Everything we build uses human capital. And human capital is messy, organic, and has needs that we should pay attention to.
Thank you and I would love to chat. I'll connect with you.
I agree on the teams aspect and the mess! Here are some lines from www.narrativedriven.org where we're building this practice in the open:
"Narrative-Driven Development is an emerging approach that employs an iterative process designed for collaborative software development, acknowledging the complexities and uncertainties inherent in human creative work. Its workflows and tools facilitate conversations, creativity and problem-solving."
I agree the problem statement can be be explicit about good for teams. My attempt at saying integration of distributed disciplines doesn't quite cut it!
Yes yes yes. I do wonder, though, if shareholders might care if they knew that well cared-for teams are more responsive, flexible, and creative--and thus more productive.
My cynic agrees with your cynic. My experienced optimist has seen happy teams produce a lot of money.
Specifically, I’ve seen dozens of teams across different companies and tech stacks build solid, profitable, maintainable, and largely defect-free software. They used TDD, pairing (and mobbing in one case), and CI. They were opinionated and respectful of each other—it often felt like family. They used their big brains to solve real business problems.
Was there pressure to deliver? Yes. Was there conflict? Yes, both the healthy kind and the destructive kind. Were there sticky, frustrating problems involving legacy code, pushy stakeholders, and team dynamics? Of course.
But with each of these teams, they prioritized being a functioning social group, in service of building software they could be proud of. You might even say that they loved each other. I know I loved them.
As for what corporations want, I can name a few things from my own experience:
1. Decreasing cost of development
2. Increasing speed of development
3. Increasing quality of development
But non-programmer managers do not know how to do this. The software is intangible and unknowable to them. I believe there is a way, but that it will take strong leadership from someone with lots of authority and technical expertise. Only they can find the path.
The failure mode of Agile that I've seen most commonly is this: As management feels they are losing control of the delivery, they demand stricter adherence to "standard Agile practices" (scrum, stories, points, etc.) instead of doing a real analysis of how the work gets done and trying to improve it. In other words, they don't know how to manage, only to "do Agile."
But can this change without it being driven from the top?
Hi Eric. Thanks for sharing your thoughts here. You've got me thinking.
I'm suspicious of the assumption that change needs to be "driven" from the top by someone with lots of authority and expertise. My favorite quote on this topic comes from an anthropologist who knew a thing or two about people, Margaret Mead: "Never doubt that a small group of thoughtful committed individuals can change the world. In fact, it's the only thing that ever has."
We need folks who are willing to take on the skills and consequences of social change. In some cases, that may mean walking away from the kind of dysfunction you describe above, instead of trying to fix it from within, from a position of little influence. Sometimes it's best to leave a system alone to suffer it's own repercussions.
I'm not saying put your ability to pay your mortgage at risk. I am saying look for your fellow thoughtful and committed individuals and experiment. Start your own community or even your own company. Be the change. You never know -- you might come up with something cool that spreads.
That's what I did. I'm working alone now. But I'd love to work for a place with strong leadership.
My attempts to affect change have always been stymied, usually by my own lack of energy to continue. I can see the problems but can't navigate through to solutions.
Eric, you are right. Those 3 things Cost, speed, qualities. And you are right that managers (of programmer and non programmer) are not trained to master these things. For a start they cannot clearly define qualities, like security, usability, tech debt. Bad education in my opinion. So step 1 is to move to real software engineering. Real engineers can define reliability, maintainability, and compute the availability from that. Programmers and managers do not even know that thyme not now. If you do not know how to do this, ask free ChatGPT, it does.
Perhaps the real goal is how do we build software for our managers so they get the credit when executives like what the team has done and avoid the blame when executives are unhappy with the result.
If thats the real goal then traditional waterfall project management meets this goal better than agile does because its all about getting sign off from senior managers on detailed documents at each stage of the process so that you can point to those approvals when youre getting blamed.
Starting with a new joint problem statement is a great target achievement. Thanks Erika for sharing.`
what about being clear (quantification rather than blah blah) about the higher priority improvement you expect from a project? and on that basis asking, at every sprint, did we move towards our goal? If not what must we change?
For me its still the same.
We don't Talk to customers lets do that.
Hi Muhammad. I absolutely agree that's a huge missed opportunity for feedback. Do you feel like that's the primary gap?
well, 'talking to' is maybe not the best way to discover their values. Listening to, and observing, sound more productive. A real agile way is to deliver some improvements and listen to them about that, and see how they react to it, and then pivot if necessary (agile, you know). BTW Customers is one interesting segment we serve, but consider the other 50 stakeholders (like users, financier, potential customers).
Agreed. I am more interested in users because (most of the time) they bring real feedback.
This is an easy one for me since I'm working on a solution to what I believe is the new problem statement:
“How do we integrate distributed business, design, and technology disciplines to deliver valuable software competitively and accurately?”
We're in a world today where context is fragmented in “user story” tickets, and high bandwidth communication is fading into a past where co-located teams can be in the same space without getting video call fatigue.
High context and communication are present in all high performance teams. Any new solution needs to address these two fundamental aspects.
I think it's really cool that you're working on this. Let me know if you would like a chat.
I appreciate where you're headed with your statement. But I immediately miss the "good for teams" part of the original manifesto. Moving forward, I think that focus is crucial. Everything we build uses human capital. And human capital is messy, organic, and has needs that we should pay attention to.
Thank you and I would love to chat. I'll connect with you.
I agree on the teams aspect and the mess! Here are some lines from www.narrativedriven.org where we're building this practice in the open:
"Narrative-Driven Development is an emerging approach that employs an iterative process designed for collaborative software development, acknowledging the complexities and uncertainties inherent in human creative work. Its workflows and tools facilitate conversations, creativity and problem-solving."
I agree the problem statement can be be explicit about good for teams. My attempt at saying integration of distributed disciplines doesn't quite cut it!
The original statement still fits but needs it's emphasis and order needs changing:
How do we help teams solve customers problems in a way that keeps both teams and customers happy *and* provides a return on shareholders investment.
Happy teams keep working -> customer problems keep being solved
Happy customers keep paying -> shareholders investments return value
Happy shareholders reinvest -> go back to beginning
Hard to implement, yes, but do shareholders really care how things are done, as long as they are done?
Yes yes yes. I do wonder, though, if shareholders might care if they knew that well cared-for teams are more responsive, flexible, and creative--and thus more productive.
I'd like to think so but the cynic in me thinks money is the bigger driver more often than not
My cynic agrees with your cynic. My experienced optimist has seen happy teams produce a lot of money.
Specifically, I’ve seen dozens of teams across different companies and tech stacks build solid, profitable, maintainable, and largely defect-free software. They used TDD, pairing (and mobbing in one case), and CI. They were opinionated and respectful of each other—it often felt like family. They used their big brains to solve real business problems.
Was there pressure to deliver? Yes. Was there conflict? Yes, both the healthy kind and the destructive kind. Were there sticky, frustrating problems involving legacy code, pushy stakeholders, and team dynamics? Of course.
But with each of these teams, they prioritized being a functioning social group, in service of building software they could be proud of. You might even say that they loved each other. I know I loved them.
Yes, this is rare. But it shouldn’t be.
Hi Erika,
I'm on a similar quest.
As for what corporations want, I can name a few things from my own experience:
1. Decreasing cost of development
2. Increasing speed of development
3. Increasing quality of development
But non-programmer managers do not know how to do this. The software is intangible and unknowable to them. I believe there is a way, but that it will take strong leadership from someone with lots of authority and technical expertise. Only they can find the path.
The failure mode of Agile that I've seen most commonly is this: As management feels they are losing control of the delivery, they demand stricter adherence to "standard Agile practices" (scrum, stories, points, etc.) instead of doing a real analysis of how the work gets done and trying to improve it. In other words, they don't know how to manage, only to "do Agile."
But can this change without it being driven from the top?
Thanks for the thoughts,
Eric
Hi Eric. Thanks for sharing your thoughts here. You've got me thinking.
I'm suspicious of the assumption that change needs to be "driven" from the top by someone with lots of authority and expertise. My favorite quote on this topic comes from an anthropologist who knew a thing or two about people, Margaret Mead: "Never doubt that a small group of thoughtful committed individuals can change the world. In fact, it's the only thing that ever has."
We need folks who are willing to take on the skills and consequences of social change. In some cases, that may mean walking away from the kind of dysfunction you describe above, instead of trying to fix it from within, from a position of little influence. Sometimes it's best to leave a system alone to suffer it's own repercussions.
I'm not saying put your ability to pay your mortgage at risk. I am saying look for your fellow thoughtful and committed individuals and experiment. Start your own community or even your own company. Be the change. You never know -- you might come up with something cool that spreads.
That's what I did. I'm working alone now. But I'd love to work for a place with strong leadership.
My attempts to affect change have always been stymied, usually by my own lack of energy to continue. I can see the problems but can't navigate through to solutions.
Eric, you are right. Those 3 things Cost, speed, qualities. And you are right that managers (of programmer and non programmer) are not trained to master these things. For a start they cannot clearly define qualities, like security, usability, tech debt. Bad education in my opinion. So step 1 is to move to real software engineering. Real engineers can define reliability, maintainability, and compute the availability from that. Programmers and managers do not even know that thyme not now. If you do not know how to do this, ask free ChatGPT, it does.
Perhaps the real goal is how do we build software for our managers so they get the credit when executives like what the team has done and avoid the blame when executives are unhappy with the result.
If thats the real goal then traditional waterfall project management meets this goal better than agile does because its all about getting sign off from senior managers on detailed documents at each stage of the process so that you can point to those approvals when youre getting blamed.
real agile would deliver measurable business value results every sprint. Not just code.
I agree