Succeeding with Agile, Brief Overview I

Succeeding with Agile

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.

Succeeding with Agile

Succeeding with Agile

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.

--
Best Regards,
Azat Mardan
Microsoft MVP | Book and Course Author | Software Engineering Leader
Azat Mardan avatar
https://www.linkedin.com/in/azatm
To contact Azat, the main author of this blog, submit the contact form or schedule a call at clarity.fm/azat and we can go over your bugs, questions and career.

3 thoughts on “Succeeding with Agile, Brief Overview I

  1. Azat Post author

    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).

  2. Sergey

    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.

Leave a Reply

Your email address will not be published. Required fields are marked *