Applying Systems Thinking to Teams and Software.pptx
•Télécharger en tant que PPTX, PDF•
0 j'aime•23 vues
Most developers really want to do good work. We talk about clean code, and plan great architecture, but despite all this, most long term systems degrade into the big ball of mud. We all know of code bases like that, but do we understand why it seems inevitable? Systems Thinking offers a new lens for looking at our challenges and how to overcome them.
Recommandé
Recommandé
Contenu connexe
Similaire à Applying Systems Thinking to Teams and Software.pptx
Similaire à Applying Systems Thinking to Teams and Software.pptx (20)
Plus de Lorraine Steyn
Plus de Lorraine Steyn (9)
Dernier
Dernier (20)
Applying Systems Thinking to Teams and Software.pptx
- 1. Applying Systems Thinking to Teams and Software Presented by Lorraine Steyn @lor_krs
- 3. Is the Big Ball Of Mud inevitable?
- 5. 1
- 6. 2
- 7. Environment Top 25% Bottom 25% Dedicated Floor Space 7.25 m2 4.27m2 Quiet workspace 57% 29% Private workspace 62% 19% Silenced phones 52% 10% Divert calls 76% 19% Often interrupted? 38% 76% Feel appreciated 57% 29% Coding Wars Stats Peopleware by Tom DeMarco and Tim Lister
- 10. Processes, Agile or otherwise… 4
- 12. Agile Manifesto: Individual and Interactions over Processes and Tools Responding to change over following a plan
- 14. Your system is perfectly designed to give you the results you’re getting ” “ W. Edwards Deming
- 15. Systems Thinking is a discipline for seeing wholes rather than parts, patterns of change rather than static snapshots, for understanding the subtle interconnectedness that gives living systems their unique character. Peter Senge
- 18. Feedback Loop Cards A Team has a Deadline - what is the loop if management asks for limited overtime? Part B - what if overtime drags on for months?
- 19. Inflows, Outflows and Stocks Ground Coffee Filter Papers Boiling Water Pouring a cup Used filters Heat Loss Evaporation
- 21. Applying Systems Thinking to Teams
- 23. Can we store happiness? Can we create or deplete it? Are there feedback loops?
- 24. Boundaries
- 27. Code as a Stock Can we store code? Does it have value? How does code gain value? What makes it less valuable?
- 29. Code Value is tied to Team Knowledge
- 31. 3 Is the Big Ball Of Mud inevitable? Yes, if… 2 1 4 5 Poor Management – low trust, rigid, controlling Disruptive working environment, lack of privacy Limiting architecture, poor tool & language choices Processes that don’t serve the team People are treated as interchangeable Lego blocks
- 32. Applying Systems Thinking (and common sense) Take a holistic view, get outside input if needed Fix the obvious things in the working environment Make time to remove development blockers The processes must serve the team not vice versa Treat your people as valuable, unique adults, invest in them 1 2 3 4 5
- 33. 2
- 34. 2
- 35. 3
- 36. 5
- 37. 5
- 40. Thinking in Systems – Donella Meadows https://donellameadows.org/archives/envisioning- video/ Intuition vs Analysis Boundaries constrain the problem (simplification) More Great Systems Thinkers: W Edwards Deming Gerald Weinberg Dr Russel Ackhoff Peter Senge
Notes de l'éditeur
- Lor; From CT, very windy, founder of a mid-sized software co, work closely with our various teams
- Code tends to big ball of mud Even with the best intentions Things like “just do this prototype” and 3 years later it’s production code What is the problem? Why does this happen?
- Are we actually idiots? If not, what’s stopping is?
- 1. Bad Management Introduce Deming – polymath Deming says it’s our management Mgt role to fix the system not the people
- Our working environment
- 166 programmers from 35 organizations 1984 but timeless 10x organizations are conscious of the cost of interruptions, and offer protect their teams from distractions No blinds on windows
- Open plan, sterile, no blinds Cosy, personality, has blinds, near the kitchen, has cats If you’re a manager thinking we’d like to be back in the office rather than in a corner in our house, you are wrong Drawback – getting family to respect that you are working, can be isolating
- Have to work around bad decisions Unfinished code, half implementations Bridge left unfinished since 1977 (45 years) Inappropriate choices, personal preferences Developer wanted to use old testing framework, because that’s the one he knows
- Let’s take ticketing. Who works with a ticket system? I love a lightweight Trello board – gives team visibility and focus. All too often, mgt brings in a ticketing tool. They collaborate to design the columns and workflow. They automate a few steps, all very pretty. Each ticket must be assigned to a category, because, someone will want those stats, right? Teams starts using the board, but then reality hits. The users are submitting duplicate tickets because Tom doesn’t check if Sally already logged the issue. So a meeting is held, and we all decide that there will be super user per dept The categories are turning out to be more difficult than we expected, not everything is fitting into the neat boxes defined by mgt, so we have more meetings about what we will call things. We keep adding processes to run our process. Soon we are serving the process, it is not serving us
- Frogs are smarter than us! The effort to maintain some process becomes huge, but no one notices, because we just believe this how it’s done.
- A final word on process, it told us to value people more than process, but we don’t It also didn’t say “no plan” Yes, we know things will change, but is no roadmap at all the right course Eisenhower said plans are useless, but planning is invaluable Manifesto is a trauma response to bad mgt. How much has changed?
- This is the idea that you can replace a developer who leaves with no impact to the team We are not interchangeable Lego blocks
- Encouraging, because we can change the system Let’s review what we mean by systems thinking
- Lor – how many devs in the room? Devs tend to be detailed people, and ST challenges us to look up and see the bigger picture To see patterns, and to see connections
- Lor – a system is defined not by its parts but by its purpose Nature is easy, harder to see the purpose in some organizations and teams
- All systems have feedback loops (except death) Bring variables back to a desired state – self correcting, stable
- Change is compounded to cause more change – instability, exponential growth, unstable Until the momentum runs out and the system returns to balance, but possibly at some new level
- Could be balancing if the overtime is enough to balance the extra work Negative reinforcing loop, with team getting tired and less productive
- Inflow outflow explanation with Team examples
- Causal loop diagram
- This is my team, we all work remote, and we have to be very explicit about our systems and processes. It’s not as easy as in-person
- Is a team a stock? We need 6 people for this job? Sounds like a stock of people Lego block view of people
- Is Happiness a stock?
- Especially with complex systems, define boundaries. Start small, swimming pool not ocean
- Look below, not just the obvious
- Take different perspectives
- Lor
- The actual code in human readable form Mental model of the code Developers, Testers, Scrum Masters … (people) More code does not equal more value
- Lor 1st gen developers have full mental models When the model breaks, you start to hack out pieces of the hedge to get anywhere!
- Change a team member, you change the team and the team knowledge
- 1. Bad Management Deming says it’s our management Mgt role to fix the system not the people
- Sustainable pace
- Things that really help – slack time
- Blockers Negotiating time to address the worst decisions in your code is the key step to gaining control and extending the life of the code
- Make sure you have safety to fail
- Great teams build great teammates Mentoring is never a waste of time
- Cape Town wind bends trees. Our systems mold our performance. We all adapt, just like the trees. But it’s not ideal.
- People want to do good work, let them
- We have 5 mins spare for any questions