Great Development Teams

Get Started. It's Free
or sign up with your email address
Great Development Teams by Mind Map: Great Development Teams

1. Roadmap + Scrum

1.1. A spec DOES NOT have all the answers

1.2. Minor course corrections along the way

1.3. Hard to have failure states

1.3.1. No Black box

1.3.2. Harder to be genius in the lab

1.4. Team engaged with the product

1.4.1. IMPORTANT: Operational phase of measure and iterate

1.4.1.1. It's living

2. 2. Some Failure states

2.1. Not seeing the big picture

2.1.1. Connect to business

2.1.2. Think about people as well as code

2.1.2.1. Code is law

2.1.2.1.1. You make the rules

2.1.2.2. e.g. Mick testing one of my applications

2.1.2.3. e.g. Pressing 'Back' on a form

2.2. Genius in the lab

2.2.1. Enforcing own coding principles

2.2.1.1. Boost?

2.2.1.2. English language methods or tightly compressed strings?

2.2.2. The need for perfect architectures

2.2.3. Black Box Problem

2.2.3.1. Request goes in, feature comes out - perhaps

2.2.4. Refusing to integrate into a process

2.3. Multiple sources of truth

2.3.1. The evil spreadsheet

2.3.1.1. Jay's spreadsheet

2.3.2. Evil email

2.3.2.1. Jared's inbox

2.4. Fear

2.4.1. Fearing to say you're stuck

2.4.2. To be seen as bad, lazy or slow

2.4.2.1. Over promising creates a team of failures

2.4.3. Fear of leaving comfort zone

2.4.3.1. Throw yourself at it and see what happens

2.5. Not aligned on focus

2.5.1. Sub-optimal project planning

2.5.1.1. How does the team decide what is in this sprint?

2.5.1.1.1. How are decisions made in realtime?

2.5.2. Confused customers

2.5.3. Poor realtime decision making

2.5.4. DEFINE: Knowing the end objective.

2.5.4.1. Small sets of clustered functionality.

2.5.4.2. Measurement and iteration

2.5.5. Velocity alignment with business

2.5.5.1. Going too fast

2.5.5.1.1. Make problems for later

2.5.5.2. Going too slow because...

2.5.5.2.1. Too perfect

2.5.5.2.2. Too scared

2.5.5.2.3. Unclear focus

2.5.5.2.4. Overwhelmed

2.6. ? Observations in your team?

3. 4. A squad needs a process

3.1. Automate Automate

3.1.1. Unit testing

3.1.2. Automated releases

3.1.3. Continuous integration

3.1.4. Jason Hoffman: Joyent

3.1.4.1. Failure to administratively scale

3.1.4.1.1. Werner Wogels: Amazon: 80% crap 20% creation inversion

4. 3. Serve the business

4.1. Know the roadmap

4.1.1. Startups

4.1.1.1. Runway thinking

4.1.1.1.1. Leads to focus

4.2. Know the objective

4.2.1. Why are people selling what we build a certain way?

4.2.1.1. Where do we change how/what we build?

4.2.1.2. Where do we educate the rest of the business?

4.3. Communicate out

4.3.1. Educate how the parts connect

4.3.2. The entire business is responsible

4.3.2.1. Help everyone else engage with you

5. 1. Pre-Amble

5.1. Background

5.1.1. Kazaa

5.1.1.1. 300 million users / 5 million concurrents

5.1.1.2. Team in 5 countries

5.1.1.3. Significant security threats / hackers

5.1.1.4. Legal battle

5.1.2. Pollenizer

5.1.2.1. 40 startups

5.1.2.1.1. Everyone has the same problems

5.1.2.1.2. Most have insufficient process

5.2. Today - What I have seen of great teams