Book: Succeeding With Agile

I finally finished another book from the pile I decided to read over Christmas. Succeeding With Agile is definitely worth a read if you’ve rumbling down the agile road since it offers help in many areas when travelling the agile highway:

  • Scrum touch more than just development (page 4) – Unfortunately this is probably the most missed point on adopting agile. How many times have you see agile teams with no testers? And no changes to sales, marketing, finance etc
  • If a team doesn’t try new technical practices early, it might never try them (page 56) – I’ve found it very common for “new” agile team to try and get started with coding ASAP, ignoring test-driven development (TDD – page 157), pairing etc. Once you start down a road, its very hard to change 😦 Hence why I push for for the use of new technical practices on projects (where possible)
  • There may be strong resistance to some practices (page 56) – This is possibly one of the reason why the previous point is encountered. Teams need to try simple design, pair programming, and test-driven development
  • Improvement backlog (page 62) – If you haven’t got one, you probably need to
  • Test mercenaries (page 76) – experienced engineers with a passion for and expertise in testing
  • The Role of the ScrumMaster (page 117) – Worth a read to remind yourself of what they do. No command-and-control here!
  • The Product Owner (page 125) – Definitely worth a read. Former project managers often become the ScrumMaster, product owner, or team member
  • Programmers will be expected to talk to customers and users (Page 147)
  • User Experience Designers (page 151 coupled with page 271) – check out figure 8.2, and read “How UCD and Agile can live together”
  • Standard pair programming objection (page 165) – Unfortunately management is often short sighted, and forget about the impact of defects
  • Feed them Two Pizzas (page 177) – Good team sizing metrics
  • Small Team Productivity (page 180) – Really goes hand in hand with the previous point. Very valid if you have project managers who think the world should run on one large team
  • Favor Feature Teams (page 182) – Used this a few times, and it does have benefits for the reasons listed in the book
  • Do a little bit of everything all the time (page 206) – You really don’t want to wait to the end of sprint to finish everything and do the testing
  • Foster Team Learning (page 209) – openness to new ideas!!!
  • Developer are NOT coding monkeys (page 215)
  • Shifting from Documents to Discussion (page 236) – Business Analysis (BA) often find the transition to agile challenging, since they are so used to dealing with functional specifications. Chapter 13 provides some insight that should assist.
  • Product Backlog Iceberg (page 243) and grooming (page 244) – so many teams are confused about what a backlog is, and what it should contain.
  • FitNesse (page 252) – As written about by the Agile Testing book
  • Potentially Shippable (page 258) – To many team don’t understand what this means, missing the zero defects end of sprint goal
  • User Experience (UX) need to remember that a sprint must deliver Something Valuable Each Sprint (page 262)
  • UX team members need to remember that they are part of one team, but need to spend time looking further down the product backlog at upcoming items. Yet remaining ONE team and working on one sprint at a time to assist in the coding and testing (page 272). Mike’s view here is key, and something that needs to be followed to stop the creation to a UX and Development team (Sprint n-1/Sprint n) view of the world
  • Keep the right data (page 297)
  • Quality (Chapter 16) – No much to say here. We’ve all experience technical debt. Either accept the pain, the overtime and nightmare, or move into a better world and start the project with good engineering practices (page 321)
  • Part of a large agile project? Read chapter 17!
  • I know of one Single Dealer Platform (SDP) project that has the server team in the UK, and the client team in India. I hope they read chapter 18
  • It’s fairly common for agile teams to interact with waterfall teams (Chapter 19)
  • I still can’t believe the pain I go though getting team to use a task board (page 419)

Mike’s Succeeding With Agile book should be a must read of everyone on an agile project. It reminds us of what is required to make an agile project successful. The only downside is that in some areas the book could me more explicit in the steps of how agile should be adopted to fully ram home the message. If you don’t want you agile project to fail read Mike’s book.

~ by mdavey on January 6, 2010.

4 Responses to “Book: Succeeding With Agile”

  1. I dunno Mat, I really miss my old task board! Test mercenaries, that sounds like fun. No mention of Self Directed teams? You can’t have testers in the team, if the team is not self directed. any mention of teams conducting their own recruitment?

    Only 4 books to go before I let myself get some more! 🙂

  2. […] Book: Succeeding With Agile Tales from a Trading Desk – Mike’s Succeeding With Agile book should be a must read of everyone on an agile project. It reminds us of what is required to make an agile project successful […]

  3. Nice and very useful review! Thanks

  4. I read this book in November before it’s official release. I was so impressed by it that I recommended it to everyone in my company. I bought multiple copies for my team with no prospect of getting reimbursed (but they did after the fact). After years of Agile practice this book has given me the tool to explain Scrum to my co-workers and management. I do not have to go to multiple sources.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

<span>%d</span> bloggers like this: