Couple months ago, I was promoted to a ScrumMaster role at DocuSign. In light of it, I decided to brush up on my agile development skills and theory by reading. My choice fell on the highly acclaimed Succeeding with Agile: Software Development Using Scrum by the guru of Agile Development and Scrum — Mike Cohn.
Here is a short overview of the first half of the book, or gist as programmers call it:
- A ScrumMaster has more responsibility and authority over processes, but a limited authority over people; the role is akin to a fitness trainer (a yoga teacher analogy fits me better): enforcing the agile process.
- Every sprint team needs to deliver shippable (and tested) code: features, bugs, etc.; if the task is too large — split it.
- Developers should work with product managers/owners directly on requirements.
- Different developers should work on all parts of the application / code base.
- Agile is not for the developers who likes to work in privacy putting their headphone and not talking to people (Bummer). :-)
- Team functions better with a mix of generalists and specialists; avoid all-specialists teams at all cost.
- When possible use feature teams rather than component teams.
- Keep teams small. Four to nine people is an optimal size due to the social loafing (having more people reduces average productivity) — this was one of the reason our DocuSign team was split into three smaller teams!
- A non-coding architect and project manager are obsolete roles on a Scum team.
- Don’t let team members multitask. Each additional task reduces productivity; however, after three and more tasks the reduction becomes smaller and smaller. Direct quote: “Individuals assigned to work on multiple projects inevitably get less done”
To be continued…
What I really liked about the book so far is that it’s not just boring theory. Each point is supported by data, references to sources and personal three-decade-long (anecdotal) experience of the author (Mike Cohn). If you liked the bullet point above, get Kindle Succeeding with Agile on Amazon.
Totally agree on Feature vs. Component point.
Sergey, to clarify these points properly like Mike Cohn did, it’ll take a book to write. ;-)
Feature team: team is responsible for the whole feature: database, front-end, UI, UX, API, servers, etc. Component team: team is responsible only for a component: API, or a widget, or database, or CSS library.
Short and probably incomplete answer: Pair programming and constant developer-product owner interaction reduces “offline hours” to 0. I don’t fully agree with this personally, but that’s what’s productive and agile (and in the book).
Nice post. Could you clarify on few points:
“When possible use feature teams rather than component teams.” – What the difference between feature and component in your situation?
“Agile is not for the developers who likes to work in privacy putting their headphone and not talking to people (Bummer). ” Odd, what if one needs to concentrate and get the job done? Should there not be “office hours” vs “concentration time”?
“Don’t let team members multitask.” – ehh, so true, but rarely possible in early stage startup.