Previous weekend I was preparing for gaining Scrum Master Certificate. If Scrum is new to you and you are interested in it, I strongly advise you to take a look at this video where one of the Scrum inventors is talking about its implementation at Google.
In preparation for Scrum curse I have read Agile Project Management with Scrum by Ken Schwaber. The book is excellent and I recommend it to anyone interested in Scrum. Thing I liked the most about it was the way book was written. Main thing about Scrum is that it is simple, pragmatic and lightweight and the book is just the same. Book is short, simple and knowledge is passed to reader through real world examples. Most of these examples were examples of Scrum misusage, which are extremely valuable because they keep us from repeating common mistakes and at the same time enables deeper understanding of Scrum driving forces.
Next thoughts were most interesting to me:
- Role of managers is to shape the organization not through the power of will or dictate, but rather through example, through coaching and through understanding and helping others to achieve their goals.
- There are three legs that hold up every implementation of empirical process control: visibility, inspection and adaptation.
- Scrum uses power of time-boxing to instill the art of the possible and avoid pursuit of perfection, the practice of incremental delivery to improve engineering practices, and the practice of empowerment and self-organization to foster creativity and worker satisfaction.
- Every increment of potentially shippable product functionality that is demonstrated at the Sprint review must be done. Done means it contains all analysis, design, coding, testing, documentation, and anything else appropriate for application.
- Many development teams accept the risks and don't discuss difficulties and options with stakeholders until the end of the project. This is natural result of an environment in which developers don't really know where the project stands any better than management does.
- Scrum relies on high-bandwidth, face-to-face communication and teamwork. Cubicles and unneeded artifacts promote isolation and misunderstandings.
- Build the infrastructure for scaling prior to scaling and always deliver business value while building it.
- You can get through almost anything if you don't try to impose rigid solutions before problems even arise, instead devising solutions as necessary when problems crop up.
- Retrospectives that don't result in change are sterile and frustrating.
In my previous post what to code next, when I discussed choosing next module for building I completely ignored importance of business value and ROI (return of investment). This was noticed by my dear friend Aleksandar Mirilović (who's blog is still under construction) and confirmed in Scrum. Fact that something has greater business value or is urgent can not be ignored. Also business value is excellent test for early system architecture. If you respect ROI and deliver complete functionalities at the end of each print, you will be able to go live with incomplete product at any time, which I argue is very valuable flexibility for business.
In my next posts I will cover things I have learned in course so stay tuned.
Do you have any real world experiences with Scrum? Are you planning to?