Agile Project Management with Scrum (Developer Best Practices) 1st Edition

I came at this book from several perspectives based on my background in Solutions Sales, Project Management (traditional -- PMP certified), Contract/Vendor Management, and SQA Management.I'll briefly explain how SCRUM has helped me consider new possibilities on each of the above mentioned areas. In addition, I'll start off with a general perception of this book.If asked to sum up my thoughts in one word on Agile Project Management with SCRUM, it would be "REVOLUTIONARY"!Even though the text is focused on software development as the domain where SCRUM is applied, it's easy to see how SCRUM can be applicable to any project.SCRUM is based on a well defined set of rules and a set of roles which include a ScrumMaster, a Product Owner, and a team(s). I found it revolutionary as it works exceptionally well in complex, chaotic project situations, and it empowers a team in new ways, and forges new optimized partnering between those delivering (the team) and those consuming (the customers). SCRUM also focuses on ROI and regular prioritized delivery of business value.The Solution Sales view:SCRUM offers a new approach to bid on complex, fixed-price, fixed-date RFPs. To do this, a bidding firm would have to collaborate with the client up front, to explain the differences between between a traditional waterfall-based approach and the SCRUM approach. An enlightened client will see the opportunity for partnering in new ways with a supplier, and how SCRUM minimizes risk and increases flexibility while keeping the spotlight on business value as defined by customer's prioritized needs. Communication is based on business value, not technical jargon, which also leads to increased customer satisfaction.The Project Management view (traditional):When I studied to become Project Management Professional (PMP) certified, I learned many formalized methods for managing, controlling, reporting, and delivering on a project. SCRUM is a complete paradigm shift, but it rapidly starts to feel good. The author illustrates through numerous case studies how a project manager, now a ScrumMaster, contributes and can still meet management's requirements for information reporting and results. The text also highlights CMM KPA's and how SCRUM still ensures compliance.The Contract/Vendor Management view:Having taken a formal program in contract management and having been both on the vendor and vendor management sides of the fence, I began thinking early into the book how SCRUM would impact these areas. My thinking here ties into my earlier thoughts on the Solution Sales view -- SCRUM provides a new model of Supply Chain Management (SCM) and partnering that can reduce costs and improve results. A side effect that leaped out at me is that I believe that SCRUM could have a dramatic effect on minimizing the need to offshore delivery. By having a resident local team using SCRUM, results look so positive based on the case studies I read, that SCRUM could increase onshoring due to its rapid results (achieved within a 30 day Sprint), team/customer cohesion, and more. Offshore delivery would still be very possible using SCRUM and improve results, however, I can imagine the value of the shared space partnership between a local team and local customers at its positive macroeconomic impact as well.The SQA view:I've been a QA engineer and manager. QA adds necessary value, however, it is often seen as a policeman role, or an afterthought where quality is "tested" in. The identification of last minute defects causes angst, anger, increased costs, and customer dissatisfaction. The latter often being due to great pressure to ship anyway or solutions that can't be fully tested in time which lead to customer identified defects (and costs), or bug-fix delays impact client schedules/needs.SCRUM makes testing a component of "doneness" -- embedded in a concept which SCRUM calls "sashimi" after the Japanese delicacy. In a nutshell, testing becomes everyone's job and the team partners to produce a complete result as committed to at the beginning of the Sprint. No more policeman. Instead, a committed team that works together in an optimized manner.In summary, SCRUM provides much to think about for Sales, Project Management, Software Development, Contract Management, and QA professionals. It is an exciting process that has undeniable value.

The Scrum principle is simple. It starts with some common observations: that projects generally succeed when someone sidesteps the formal process and gets the job done anyway, and that big teams spend more time tripping over each other than typing code. Scrum starts with the radical idea of announcing that we're going to do what we were going to anyway, then mixing in big handfuls of eXtreme Programming.This is a good second book. It attends less to the basics of running the team and working with the customers and corporate surroundings, although Schwaber does present all those basics. Instead, the focus is on case studies, especially ones that look like bad matches to Scrum management style. I like that emphasis: typical methodology books assume perfect compliance with fragile or rare prerequisite assumptions, then wash their hands of any circumstance that doesn't meet their delicate needs. This is a good bit more realistic - it's about the whole concept of cut-and-fit to get the most out of Scrum despite unfavorable situations and stakeholders.Late in the book, Schwaber makes the point that people will do whatever they're rewarded for. However obvious this sounds, it's an ongoing source of corporate inanity. Suppose that percent of the code covered in testing is a major goal: programmers will dutifully eliminate handling of exceptional conditions or invalid preconditions for which tests are hard to generate (NOT an improvement). Suppose reduced development time is rewarded: watch testing time plummet and bug counts soar. I agree that progress must be measurable, and agree at the top of my lungs that the wrong measurements are worse than none at all.Still, one theme comes through again and again: that, when the going gets weird, typical practitioners will rapidly find themselves in way over their heads. He, with more experience than any other Scrumster around, exerts the limits of his creativity to get past problems of fairly ordinary kinds (like intrasigent management). It's certainly a good recommendation for his consulting services. It's just not a message that a novice wants to hear. I have the strongest reservations about his fondness for bullpen office environments, as well.There's good to be had here, I'm sure, but I'd have to see Scrum in action before I could really internalize the way it's meant to work.//wiredweirdPS: It's just an amusing typo, not a deliberate act that "the ... team was going to use Scum [sic]," p.64

I bought this after hearing Scott Hansleman talk about it on his scrum podcast at [...]. I figure Scott seems to have had great success with Scrum at his place of work ([...]so any book he recommended on the topic ought to be solid. Indeed it is!The book's laid out in a series of stories which illustrate responsibilities and typical problems to overcome for the Scrum roles of Product Owner, ScrumMaster, and Team. The stories are short, concise, and followed up by Lessons Learned which cover salient highlights for the various points made in the section. Throughout the book runs Schwaber's theme of how one can use Scrum to solve any number of problems and increase the productivity of their development work.What's really nice about the book is that there are stories of failures as well as successes. Software development is rarely all roses, so it's nice to see a couple examples where things didn't work -- and a solid analysis of what went wrong in those cases.On the flipside, I'd have liked a bit more detail on constructing the sprint and product backlogs. I realize that traipses somewhat over into the realm of software estimation, but more fleshing out would have been helpful. However, there's a great example of scaling Scrum and rolling up numerous product backlogs from lower levels in to a larger backlog for a major system, so that's quite beneficial.The book's terrifically well-written, is an easy read, and is formatted such that you're able to quickly pick up the important bits of Scrum. It's a terrific read for anyone looking to bring some sensible, tailorable processes to their software development efforts.