Articles, Blog Posts, Books and Quotes on Agile Project Management
Agile approaches have few proposed specific rules or techniques that have become de facto standards. One of these technique is to use the “as a <type of user>, I want to <do something>, so that <reason>” format to define requirements as user stories. In this blog post, Jim Bird discusses the idea that this user stories format is not the best way to manage requirements.
Implementing Scrum is difficult and it is always difficult to answer the question of where to start this Agile Travel. In this article, Ilan Goldstein shares 10 tried-and-tested steps to help new practitioners get their Scrum show on the road.
Implementing Scrum is difficult and there might be nothing better than taking time and making mistakes to adopt Agile successfully. This being said, ” Scrum Shortcuts without Cutting Corners” by Ilan Goldstein is a book that can help you to choose better trails when you explore some of the Scrum practices.
This article by Tim Dahmen introduces a notation is based on a metaphor for software development, which is fantasy role-playing games. It explains a graphical and symbolic notation that allows to communicate about several Scrum phenomena.
How will an organization that is already truly self-organized before Agile changes its process to adopt a framework like Scum? In this blog post, the Lomio team, a worker-owned cooperative company with no bosses, discusses how they embrace Scrum.
As Rex Lester explains in this article: “Implementing Scrum involves adoption of a new paradigm across the organization. In most instances, the severe level of culture shift and change aren’t really appreciated”. The article discusses the difficulties of moving an organization from a Waterfall process to an Agile approach.
When you observe a well-knit team in action, you’ll see a basic hygienic act of peer-coaching that is going on all the time. Team members sit down in pairs to transfer knowledge. When this happens, there is always one learner and one teacher. Their roles tend to switch back and forth over time with, perhaps, A coaching B about TCP/IP and then B coaching A about implementation of queues. When it works well, the participants are barely even aware of it. They may not even identify it as coaching; to them, it may just seem like work.