SCRUM is one of the top items on my priority list these days. I still believe that traditional ("waterfall") approach is safer (when done properly), but as majority of my recent work can at least partially be qualified as R&D, SCRUM-like agile methods are my preferred approach these days. However, agile methods are not that easy as people tend to think (that’s what SCRUM inventors say - "easy to learn, extremely hard to master"). So, as a part of my preparation for Professional Scrum Master certification, I’ve read the book I mentioned in the previous post "Scrum in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers, And Leave Competitors in Dust" (http://www.amazon.com/Software-Days-Customers-Competitors-ebook/dp/B007P6UPLG/ref=tmm_kin_title_0?ie=UTF8&qid=1340307136&sr=1-1). What are my impressions then?

  1. The title sound extremely dumb (discouraging really) and I’d never buy it based on just title - what drew my attention was the authors: Ken Schwaber & Jeff Sutherland. Who are they? Both are among people who created the famous Agile Manifesto (http://agilemanifesto.org/) and both of them are the creators of SCRUM itself. If there’s someone who knows agile and SCRUM perfectly, that has to be them :)
  2. There are several books on SCRUM and many of them considered good enough, so what does distinguish “Scrum in 30 days …”? It’s meant to focus on business reasoning of Scrum (majority of Scrum books are intended for developers) and it’s supposed to bring many real life Scrum cases with the exact description how did they solve actual problems. Getting some insider info sounds like a nice treat, doesn’t it?
  3. In 1 to 5 stars grade scale, I’d give it 4 stars, but:
    1. 1 star goes for full SCRUM guide that comes with the book (as an appendix)
    2. 1 star goes for all those real cases brought as the examples - they look quite realistic as both company and product names are not omitted
  4. That means that the general content (without guide and examples) is only 2 stars… why?
    1. This book is … shallow. It doesn’t even try to analyze why the “waterfall” is soooo bad, it just says that using it you deliver your software slower, release dates tend to delay and there’s an overhead cost. Blah, blah and blah.
    2. What’s even worse, it presents SCRUM benefits, but it IGNORES the risksit brings. There’s nothing about what you should look for in real-life SCRUMming. I can’t get rid of an impression, that authors were trying hard to avoid all possible tricky questions, like those:
      1. What about commercial relation (buyer-seller) between deliverers and sponsors? contracts? scope agreements?
      2. Product Owners and Development Team only theoretically are “on the same side” - I can imagine POs presenting an inaccurate vision of product on SCRUM planning, so developers commit themselves to deliver it in next sprint. No opinions on that?
      3. Testing and acceptance? I assume it always takes place before the SCRUM Review - but no details are given. Acceptance is based on what? Common agreement between PO and DT? If it doesn’t work in “waterfall” approaches, why should it work in SCRUM? Just because sprints are shorter? I don’t think so…
    3. One more world on the real-life examples - they look interesting, but they are not 100% credible. Scenario is like that: “We were doing the stuff waterfally for 18 months and failed, then we’ve switched to Scrum and BANG!6 months, half of the cost and everyone’s happy!”. No further details:
      1. What were the challanges with adopting SCRUM in that particular case?
      2. Didn’t success happen just because the PO was tired with previous failure and they’ve accepted unclear scope, because they were desperate to get anything? (so that means, that SCRUM makes sense only and traditional “waterfall’s” failure ;P)
      3. How did they deal with SCRUM in multi-phase long project where the technical debt can appear (to be honest, there’s a short section about technical debt in the book, but it’s VERY controversial) - without preparing a reasonable app architecture up-front (DESIGN! PLANNING!!) I can’t imagine the tech debt not appearing …
      4. Self-organizing teams myth - I can imagine such a team if you have really good and motivated developers, but some examples mentioned 100+ developer factories (organized in smaller teams of course) - did they have best possible people or did they manage to self-organize and self-discipline anyway?
So, as you can see, there are plenty of questions without an answer. And this book didn’t help in getting the answer even the slightest.
Share this post