https://www.youtube.com/watch?v=3AMzRAjA0-o&t=3m36s
A Technical Keynote presented by Michael Feathers at the 2016 Mile High Agile Conference.
"Get business and development to work together" -> merge together -> get better at software development
cultural chasm between business and tech
we aren't seeing how endemic software is to the work we are doing
What metrics measure success? How many of our metrics are related to code? Velocity, burn down, team happiness, etc..
We spend an inordinate amount of time in this industry trying to deny the existence of the code
Think about lean. It's tempting to think about flow, as if software dev is about widgets on a delivery line like cars on an assembly line
if you think about cars, once they leave the assembly line they are gone. What happens to our code? We live with it forever.
We need to acknowledge that code is forever and needs to be treated as such.
- Business and tech talk in terms of features and estimates
- What is missing in this communication is the code
- This is an example of a leaky abstraction. The code leaks through to the system of work even though we're trying to abstract away from it. We can't abstract away from code in a system that produces code.
- Does it matter what order which features we implement in?
- Agile says concentrate on highest business value
- Make sure that everyone in product has a view of the architecture.
- Use boxes, not boxes and lines
- Each box can be graded by health, assess how easy we can add features.
- We can't do things in any order with no impacts in any system.
"what's going on, having you been taking care of the system, why is this happenining now?"
If the business is seeing health of the system this helps make "business" an owner of the systems we're producing. Technical debt should not sneak up on us.
- should we have domain teams? front-end, api, etc
- there is no right way, be aware of the effects
- because of Conway's law we'll have separate systems for separate teams. Is this desirable or not?
- Teams can be fluid and this can be used to leverage conways law.
- assess features against quality of code
- rejection of features happens rarely, but maybe should happen more often with legacy code systems.
people in business are often unaware of the impacts a particular decision will have on a code base
- Should we discuss tech in retros?
- What features were good and bad in retros?
- Is this important (LG: I think it is)
- can we ask developers if we're missing any features?
- Isn't this a valuable perspective to get?
- Should this apply to strategy?
- This might just be finding easy wins.
- Is there an opportunity for deeper collaboration?
- Could this mean that we set the team goal and allow the team to come up with the features?
- Perhaps everyone should be able to pair with a developer on a feature?
- perhaps this could give product and business perspective on what devs are doing?
- This could be the reverse. Maybe developers can be involved in product, strategy, sales and marketing too?
- We've proven that it's the handoff between disciplines that kills us in software development. Maybe we should blur the lines deliberately in order to try to address this.
- Not everyone will want to do this, particularly all the time.
- We used to think integrating/merging code was hard.
- we used to think deployment was hard.
- do it often.
- why not re-team regularly?
- code is real and has real demands. This can address custodianship in a different way.
- Code has a cost carry. Features have a cost to operate.
- Maybe delete things that don't offer enough value any more.
- "strive towards simpler systems"
we exist in a symbiotic relationship with the systems
- athropromophise the system. From the perspective of the system does it need anything? It is an actor in our system of work.