Greg Cupal applies constructor theory (from physics) to agile software work #agileAndBeyond
Prevailing Consensus in science: from one state to one state, according to laws
Constructor theory: what can and can’t be caused to happen?
Get a solution space, eliminate the impossible, and what’s left could happen. This is more complex
Instead of from Here to There with a Plan “oh no, this person is gone, whatever shall we do”
From available inputs through tasks we could perform
to various points in the solution space.
We don’t know the end point, but we know where we can’t get.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
How do you take a legacy system toward fast flow of change? @suksr takes us through an evolution
using wholistic approaches including DDD, Wardley Mapping, and Team Topologies #QConLondon
The Wardley Map is only part of Wardley Mapping. There’s a whole strategy cycle
It’s not about how fast the team can program.
It’s about how fast the team can find solutions to each problem, uncover organizational secrets for how the domain works and should work.
There’s a conflict between cross-functional teams and the organizational hierarchy.
Enforcing the same JIRA workflow doesn’t make developers interchangable.
“It takes me weeks to develop rapport with teammates, months to learn domain and code, a few hours to learn a JIRA workflow.” @ntcoding#QConLondon
Smooth devex, sustainable flow:
“This is working in the government, six years ago.
No one else has an excuse anymore.” @ntcoding#QConLondon
They found best practices like: wrap each unit of work; report errors in a standard field; use span names that are specific enough to tell you what’s happening but general enough for useful grouping.