Mark Pearl

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

Cynefin Model

  • 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

  • over-specialized

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.

Team Concierge

  • React to team needs (however trivial)
  • Respect team decisions

Specialization institutionalized with titles

blog comments powered by Disqus

Want to get my personal insights on what I learn as I learn it? Subscribe now!