- Scrum pros and cons
- Agile estimations with Scrum
- Help and hints to pass your Professional Scrum Master (PSM I) Certification test.
- Real life projects experience and practical know-how on how to deal with situations that we all have gone through any time in our professional lifes.
I leave you here with the foreword of this brand new edition (translation by Begoña Martínez. You can also find her on her LinkedIn profile. Proofreading by David Nesbitt):
“Extra! Extra! New edition Agile 101. Read all about it”
Your company has just appointed you project manager. You’ve heard about Agile methodologies, Scrum, Kanban, and lots of other things you’d like to try. You’ve started reading all about artifacts, principles, and manifestos, but nothing is crystal clear just yet.
You don’t know whether your lack of knowledge will put your project at risk, but probably what worries you the most is that all these things are nothing but buzzwords, the current fad, and that they won’t have any real effect on your day-to-day work… or even worse, that such a big change in what to call things and how to do them will make your team, your clients, and your company reject those ideas altogether. Luckily for me, or unluckily maybe, I have also gone through all these problems, so in this book I will tell you how I solved them (when I’ve been able to) or, at least, what I tried and what eventually failed.
Don’t expect this document to be an exhaustive Scrum guide. I don’t know everything about Scrum, and the implementation I follow is far from perfect. For a thorough knowledge of Scrum, I recommend following some of the popular Scrum guides that you can find either online or in books like the one by Henrik Kniberg, not to mention the one by Jeff Sutherland, creator of Scrum.
Even though I follow a survival Scrum style and I still have lots to improve, Scrum has worked for me. Using it, we have managed to gain credibility in difficult projects, projects that were not working the way we expected. We managed to reduce the amount of stressful situations that, luckily, now happen far less often, and we have increased the satisfaction of the clients who, sprint after sprint, get their money’s worth. We have not been able to follow Scrum methodologies to the letter in every project we have worked on, but just trying to be more Agile we have improved our results in the projects we are working on.
When we start using Scrum, we all tend to use the terminology of this framework, talking about daily sprint meetings, product backlogs or burndown charts. We follow our Scrum guides to a tee, when in fact no one understands them, not even ourselves. Not understanding the spirit behind these rules, we end up creating a waterfall project—like we always have done—disguised by jargon that makes us look more innovative.
Rather than telling you how to do things, or explaining in detail how many meetings you should have and how many minutes each one should last, in this book I want to describe what the purpose is behind those meetings, what the artifacts described in Scrum guides are for, and what you might get out of them. I’ll help you understand the Agile principles that underlie this way of working and that really make this work. I hope you find this book very useful!
You can find texts like this and many other about how to manage agile projects in my book Agile 101: Practical Project Management (available on Amazon).