Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers, and Leave Competitors in the Dust 1st Edition, Kindle Edition

This is a hard review for me to write. I have a great respect for both of the authors and what they accomplished in the world of software development. I loved Ken's  Agile Project Management with Scrum (Microsoft Professional) . However, I did not like this book very much. Even considering that I'm not the audience, I do work a fair amount with management in organizations and I wouldn't give them this book. The book felt it was written in a hurry, it had awkward parts in it which most in the Scrum community would probably disagree with and it over-promised, giving me the feeling that Scrum is the silver bullet that magically resolves all problems. That said, it did also have some really good parts, which I'll try to point out also in this review.The book consists of 2 parts and a bunch of appendixes. The first part is the "why" which explains why traditional waterfall development is not suitable today and how an empirical process is better suited for the job.The first chapter is a "we are in crisis" chapter. Unfortunately, the only data it quotes is the CHAOS report, which has been challenged a lot of time already. Next to that, it provides some anecdotal cases. It introduces the Stacey diagram, which is great, except that it is significantly changed and Stacey doesn't use it himself anymore.The second chapter introduces the basics of empirical process and shows how it resolves problems in traditional waterfall development. It also summarizes major points on self-organization and the "new new product development game" article that influenced Scrum strongly. Also the third chapter explains the idea of just starting and getting and inspect-adapt loop going and that way evaluating whether Scrum produces any results. And chapter four explains the art of the possible and why transparency is essential and how Scrum assists with that. Chapter four was pretty good.Then, part 2. Chapter 5 is a short introduction to Scrum. Interestingly enough, it mentions that the ScrumMaster is 'a manager' which felt a bit odd and simplistic. The rest of the Scrum introduction was extremely short, just mentioning terms but not explaining them deeply.Chapter 6-8 give examples on how to adopt Scrum. From small project team (chapter 6) to the whole organization (chapter 8). Chapter 6 ought to explain how to start Scrum on a project level, but when looking at the chapter, the first half spends time explaining burn-down charts and the second half is trying to convince the world that 30-day sprints are "the right length". I found this somewhat odd as most of the world seems to recommend against 30-day sprints. It even calculates the overhead for shorter Sprints, but that is than contradicted by the Scrum Guide in appendix A which clearly states that the meetings are proportional to the Sprint length.Chapter 7 talks about "studio level" adoption, which seems to be a part of an organization. It starts with the suggestion to let everyone sign a contract that they'll use Scrum, which felt odd to me. Then it showed a survey for determining how people are aligned with Scrum assumptions, which was pretty good. Then it shows a "dashboard" of metrics for management to use which to me felt a bit simplistic (I know Ken is doing more work on this at the moment, and hope it will improve). It then calls velocity a measure of productivity (which can be quite dangerous) and suggests it to be measured in function points. I'm personally not aware of many Scrum projects that actually use function points, so I felt the mentioning of that was a bit odd. The end of the chapter related to technical dept was quite good again!Chapter 8 about adopting Scrum to the enterprise was 3 pages. Chapter 9 are the steps of a change project. This mostly is a summary of Kotter's change management ideas. Chapter 10 explains the concept of using Scrum to adopt Scrum, which is a summary of Ken's Enterprise Scrum book.Appendix 1 is terminology. Appendix 2 is the excellent Scrum Guide, which you can also find online. Appendix 3 is a play-book for adopting Scrum developed by Rally, which didn't seem to have changes much since 2005.All in all, the book had its good moments followed up by moments that made my head shake. The tone of the book was quite selling, which annoyed me a bit at times. The explanations of Scrum felt mostly shallow and then deep on surprising moments (3 pages on why the Sprint length should be 30 days, about as much as about adoption of Scrum to the enterprise). In general, the book didn't feel like one whole and felt like it was put together in a hurry. I had thought about giving it 3 stars, but think that would be too much as I wouldn't recommend reading this book. If you want a better introduction to Scrum by the same author, pick up the somewhat dated  Agile Project Management with Scrum (Microsoft Professional)  or just download the Scrum Guide (or alternatives).I had expected more from two respected and influential people in our industry.

Scrum is extremely misunderstood by technologists, management, and executives alike. This book is targeted for the executives and management of companies working with software development. It is still a great read for technologists to see the larger picture one may not see with The Scrum Guide (scrumguides.org) alone. Through the book, the creators explain and exemplify the value of following the agile software development philosophy (agilemanifesto.org) with the Scrum framework. There is a lot inaccurate material about Scrum out there along with the misconceptions; it's a chicken-egg situation. Reading, understanding, and implementing Scrum as described in this book can help you to improve customer experience, increase employee satisfaction, and save money.

This book has been absolutely insightful in terms of scrum knowledge and practical implementation of scrum to create not only a working software in 30 days but potentially utilizing scrum to successfully accommodate organizational change in iterations (I believe my fellow readers working in any org would agree so is a complex challenge)Kudos to the parent of Scrum, to provide a fresh perspective on it!

Printed on cheap paper but content is good, nice reference

It is ok book if you know nothing about Scrum. Wording is a bit repeating.

Bought this book as a recommended read for the PSM II exam prep. Good content for managers thinking about organizational transformation to Agile/Scrum. I'll have to see how valuable I think it was as a study tool after I take the exam.

The perfect book to help you better understand agile and scrum. Enjoy it and understand it. This will help you in your quest for being better at agile.

I like the examples to explain the stated concepts.It proofs the value of applying Scrum not just in developing software

Mostly a reiteration of previous books by the same authors. I am not sure this one is more convincing for management than previous ones. The last chapters are also available freely on the internet.

Good book, As i am already a certified scrum master most of the methods were already common to me. I feel this book would be grew for senior managers and leaders to understand Agile delivery.

Questions about who's a scrum master and what's their job. And similar questions for other scrum roles. This book clarifies such questions with anecdotes and real examples of how efficient managers execute scrum in different development and organizational transformation. You can see the experience of the authors poured very thoughtfully in this book. It's a great read and a must for every srum and agile software development enthusiast.

This book was recommended to me by the various websites when I passed my exam PSM1, as a good tool to prepare for PSM2.I haven't passed PSM2 yet, so I don't know whether this book really is a good preparation tool for this exam. As the guys of scrum.org don't really want to explain any further the material of PSM2 that we will be examined on than saying that it is the same Scrum Guide, just more profoundly, it is difficult to find any preparative material. An exam should not be a gamble. If it's not clear what you'll be examined on, it will not be clear what this exam, once passed, will demonstrate that you have acquired or know.And that's the whole thing. I find scrum surrounded with this laziness on a pedagogic and scientific level. Ken Schwaber isn't a pedagogic professional nor a researcher, But Jeff Sutherland is a doctor, therefore a scientific researcher and he should have warded better on the scientific level of the book. In this book, Ken dedicates a full chapter on the calculating of the performance of the team. He indicates the possibility of calculating rather finely as one of the clear advantages of scrum and one of the essentials of scrum. However, in his Scrum Guide, calculation is just being mentioned but not required and not explained. It doesn't make part of the pure scrum, and as such, he's not in accordance with his own rules. I shouldn't have had a question in my PSM1 exam about burn-down charts, although I did.This "laziness" goes further. In the beginning of his book he stipulates how scrum framework gives so many better results in comparison with the traditional methods like waterfall, referring to the CHAOS-research done on the subject. He is totally right. He shows that projects with waterfall, only 16% were realized within budget and time, and 56% had had problems. With scrum (agile), 45% of the projects were realized within budget and time. Clearly a much better result. Worth trying the scrum method. However, he forgets mentioning the 46% of the projects having problems as well with scrum. Half of the projects had problems, about as much as with waterfall. A number that intrigated me and that I would have liked mentioning and going into the subject. Schwaber forgets totally about this fact, although staring you in the face. Not very scientific. To his defense, I have to add that he talks in his book about many failures or semi-failures of projects.There is also the mania to compare all the time to the waterfall system (described as the epithetonic "more traditional development techniques"). Waterfall is very old by now, we have DSDM, Kanban, Wave rolls, and even other alternatives like MDA. It is worth by now to compare with these systems as well. I've got the impression that the comparison with waterfall stays for marketing reasons. The gain in success with more modern development techniques is probably way less. But from a scientific or statistical point of vue, it is not correct to compare with only one competitor development technique when there are more. Certainly taken into consideration that this book has been written in 2012. That's only five years ago and scrum had become at that time already the de-facto standard in the industry.Furthermore, Ken Schwaber, and to his defense none of the other authors of the scrum books I have read, talks about the drawbacks of scrum. In a promotional flyer, you don't have to. In a supposed neutral explicative book, you should. Scrum is very naïve, thinking you can automate testing, where my experience after twenty years of development is that with automated tests you test what's been tested before, and what you would have wanted to come out with an automated test, never comes out there, but unfortunately at very less comfortable moments. So, saying that development and testing to a releasable and deployable level should be done in a single sprint, is not realistic. Answering the tests should be automated, right, well, dream on! saying that all the right people should be in the development team. Yeah, great. No dependencies. Dream on again! I had an international bank for my clients. They had to report to the national bank. The national bank is not going to be member of my development team. If you want to bank on, you will have to follow their way, not the other way around. Then there is the lack of overview, the constant pressure, the development people being demotivated cause it's always the same, and scrum method problems with architecture of large systems and three-tier software, never mentioned with a word.Is it all negative then? No, of course not. This book reads well, you hear about a lot of stories how scrum developed itself, what problems they ran into, what is the basic idea behind scrum, why is it so important that nothing about the basic scrum is being changed, etc. Moreover, this is a book from Ken Schwaber, not the official statement of the scrum organisation.I'd say, read the book because you will learn about scrum and you will learn about Ken. But it should be refreshed nowadays with comparisons with more modern techniques. For the sake of taken seriously as a scientific, you cannot permit yourself to leave undiscussed the half of the projects that with scrum (agile) go bizurk, and scrum itself needs an update as well cause it doesn't take care (anymore) with the software development needs of today, nor the human needs of today.I'd say: it's a good book, but it's not a good book about scrum.Hans Wendel van Hespen, b.a., b.sc, mbasoftware engineer architectmanaging director Consui ltd.

ohne viel geschwafel und mit netten zugaben versehen.im anhang finfet sich der scrum guide, sowie ein playbook zur unternehmensweiten einfuehrung von scrum und ein glossar mit einigen wichtigen begriffen.ich habe das buch zur vorbereitung auf die psm 1 von scrum.org verwendet und offensichtlich hat es mir geholfen zu bestehen.