|I'm sure that most of you have worked within an agile environment with scrum at some point or another. If you want to get better, this is the right book for you, especially if you are running into problems or questions. It is full of suggestions that could have saved my team time and my company money. If you're just getting started with Agile you'll want to consult a begginer's book before reading this, but keep it in your wishlist!|
Twenty years ago changes in companies were very rare. A change in the team composition or a new boss were regarded as dangerous and problematic. Don't let me start with technologies.
Things are often still like this today. Scrum solves this problem in a really good way because it takes change from sporadic to consistent. Small, verifiable changes which bring value to the business are in fact the main concept of scrum. In this way you don't see the changes, you are actively making them.
So if you are a manager, a project manager or you manage someone you should read this book. If you are a developer, let me be honest, this book is boring. But, I think you should read it even if you are a developer or a "non manager" person. Today's developers are forceed to deal with growing complexity and projects and teams are getting bigger and bigger. For this reason, as developers, we cannot just sit down at our desk with headphones on. Instead, we have to focus our attention on the team and the relations between team members.
With this change, the focus is not about the technologies that we use but is more on how we communicate what we do. Between you and me, developers are not good in dealing with communication. We are getting better, but there are still a lot of strange characters and special individuals between us to say the least. That is probably why scrum and other methodologies are growing more quickly in IT departments than in any other areas of business.
The author knows what he is talking about. You can really tell from the way he is explaining concepts. The book is generally well organized. In my opinion, it is just a little too much like a list. Although, the list does cover very good points.
The book covers all the aspects of scrum. From how to manage multiple teams on a big company to how to manage yourself is a small team. It is divided in five main big parts.
The first part is just an overview of the reasons that are making scrum so successful. It includes statistics coming from the observation of projects in big companies in the last decade. Those are useful if you need arguments to present scrum to your boss.
The second part is focused more on individuals and how they are affected by the adoption of scrum. It advises you on how to deal with different reactions while presenting and adopting scrum.
The most important part is probably the third. It's about teams and how they should be organized. It also covers how they should work and deal with other subjects in the company and so on. In my experience with scrum, the most important achievements are in managing teams. You should read this chapter very carefully.
Even though your team is the best scrum team ever, you will not go far if you are not spreading the "verb" around you. To help you in this, the fourth and last parts are what you need. You'll find all sorts of advice on how to see scrum when dealing with multiple teams and with people of different backgrounds. In my opinion, this part is geared towards what a CEO should know. If you want to use scrum successfully no one in the company can escape from it.
This is overall a really great book and it gives a comprehensive overview on Scrum with suggestions on recurring problems. I definitely recommend it.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)