Thursday, July 25, 2013

OSCON Rebooting the Team

The Rebooting the Team page on OSCON site.

Fran Fabrizio (Minnesota Population Center, U of Minnesota), Peter Clark (Minnesota Population Center, U of Mn)
1:40pm Thursday, 07/25/2013

POV manager in the private sector

a reboot is a conscious decision to engage in deeper more radical change than just incremental improvements
typically impacts staff structure, work implications...

purpose: wetware doesn't lend itself to engineering-style solutions. i.e. reboot tough for engineers to solve
reboot in between incremental and fire everyone.

Happy teams are very similar. unhappy teams are each unhappy in their own unique way

symptoms of requiring a reboot
- too quiet
- people are quiting
- you've been committed to things without your knowledge
- nothing ever ships
- no 1:1 meetings
- sick time spikes
- build is always broken
- people doing' take pride in their work

- etc.

Like "code smells' there is an "org smell":
patterns in a team or organization which hint at deeper flaws. usually not catastrophic themselves, but indicatieve of weakness in team...

getting to the root: (switch speakers)
the cubicle story
- e.g. complain about noise and distraction
- translates to "i'm bummed out because management doesn't seem to be listening to or valuing my needs."
- exposes a communication disconnect between engineers and management

organizational debugging
- when organizational debuggign is done collaboratively and with humility, respect and trust 9hrt) it prodcues momentum for change.

Big Secret - wetware problems land in one of these 3 buckets:
- communcation
- trust
- process

engage dev team
- create dedicatid time/space to focus on these problems (e.g. focus fridays)
- squishy book discussion. e.g. Team Geek
- meet privately with individuals regulary

1:1
- do you feel fulfilled when you leave work at the end of the day
- do you feel that your career has direction?

engage management
- provide visibility to the smell
- gain buy-in from the top
- roundtables with leadership group

solutions
- find easy wins mixed in with longer-term fixes
- make it collaborative

exampe:
 underinvestment in individuals
early wins
- do a job study across the dev team to clarify roles
- leverage org strengths (e.g. robust prof dev support)
long-term work
- address harder-to-sovle recruitemnt and retuntion issues

lack of focus on mission
early wins
- make all hidden work visible to management
- distration managemetn: prioritize work and outsource or kill fringe projects and other distractions. align effort to core mission

lack of team cohesiveness
early wins
- hipchat: persisten group chat tool
- monthly thinking thursdays: group lunch then gathering
long term work
- cross-project standardization (e.g. tiger teams)

operational deficitis
early wins
- evolve tools: svn to jenkins
- management support for our version of 20% time
long term work
- ongoing technical debt reduction

lack of customer-developer transparency
early wins
- formalize a quarterly planning process
- open work trackign tool to customers
long term work
- refactoring the communications model

measruing outcomes
most important one is qualitative
- ie..e it smells better now

not all solutions work out as planned
- solution doesn't work - symptoms don't go away
- fix to problem creates a new problem

No comments:

Post a Comment