The following notes are based off a talk done by Fred George at Gotocon 2017
Why managerless processes…
- Requirements uncertainty (waterfall worked when there was high certainty on what needed to be built)
- Fuzzy vs. Traditional Problems
- classified problems based on key traits and how the behavored
- complicated (cause and effect is clear)
- complex (cause and effect don’t exist)
- chaotic (effect? cause?)
Most of the time you are in a state of disorder and are not really sure where your problem exists.
As individuals we have predejuces on where things need to be and what quadrant they fit in
For complex problems you organize yourself with people that are going to try things out and know they may fail.
The real money is being made in solving fuzzy problems.
The competetive advatange to fuzzy problems is about going faster.
Things that are simplistic can be designed to go fast.
Actions to complement fuzzy projects
- fixed price proect (budget constrained)
- colocated team
- iterations == daily
- discarded most original backlog
Inhibitors for managerless
Theory: specialist are more products Practice: Overhead of communication is under estimated, unbalanced workload creates delays
Fate of roles: QA
- QA tools are programming tools
- Serivce arhitecture creates complex systems
- Shift toward monitoring over acceptance tests
Fate of roles: BA
- The middle person between customer & developers
- No need, developers can speak directly to customers, very rare when a problem is too complex for the developers to understand
Fate of roles: Manager
- The are the clerk
- Leader (but not necessariyly annointing the leader is not a good idea)
- The guy that talks to the outside world, coordinating depenencies, etc.
- The coach and mentor for the team
- The conceirge
- Sometimes turns into a power hungry boss
These are roles that the manager does, you can disperse these roles into the rest of the team
Begin to trust the organization, trust that…
- the programmers care
- leaders will emerge (situational leadership)
- problems will arise and get solved
- team composition will (should) morph
You want to have a delivery focus…
- all roles support delivery
- complete focus on cycle time
- constantly reiterated from the top (execs need to support things)
- if you are scared of making mistakes, waterfall process will creep back in
We are not going to slow down because we make mistakes, we are going to go faster.
Manager inversion, the manager works for the team.
- React to team needs (however trivial)
- Respect team decisions
Specialization institutionalized with titles