I’ve spent a large majority of my time as a software developer researching and integrating process. It all started from working in a chaotic environment as a single developer trying to figure out how to come up with accurate estimates. Following a 5 day course on IT Project Management, I asked the instructor how I should approach planning in my situation. He recommended I look into agile development. From there I found a book called “Agile Estimating and Planning” by Mike Cohn. This was my introduction to the concept of User Stories, Planning Poker and different ways of breaking stories down to a size where they can be estimated. I was hooked on learning about being agile from that point on.
This all happened around 2007. In 2008, I changed employers so that I could be part of a software development team and company. Before that, I had been developing software within a decent sized company in the promotional products industry since 2001.
Working for a startup software company still in the works of developing process sparked me to buy and read the book “Succeeding with Agile: Software Development using Scrum” by Mike Cohn. This was one of the first, and by far the best book that I’ve read about this topic. Not only does it touch on every topic that I can think of, it also has many side notes about different employees’ objections, hesitations and responses for them. He wrote the book as a consultant while facing all of those issues. I highly recommend this book to anyone that is interested in, or having trouble with implementing agile software development.
Another great one is “Planning Extreme Programming” by Kent Beck and Martin Fowler. There are subtle differences between Scrum and XP, and it is in your best interest to understand both.
“User Stories Applied” again, by Mike Cohn is another great book that helps with how User Stories can best be written. I will not try to summarize it here in detail, but let’s just say that it clears a lot of things up about how to write user stories, use them for acceptance testing, etc.
The reason that I have not written about agile development after over a decade of research is because there is so much that can be missed without diving into these books, reading them fully, taking notes, coming up with questions and finding the answers to them, and fully learning everything there is to know before bashing or praising it. So many people tear it apart based on their experience of bad implementations of it, or by reading clickbait type articles to further reinforce their negative opinions without doing the research of finding out how to make it work.
Attempting to make it work is more like a marriage. It takes a lot of work with trial and error, and all parties must be willing to make it work and be positive with potential solutions instead of non-constructive criticisms. The whole point is continuous improvement. Not all companies are the same, so not all companies will come up with the same improvements. There are many examples out there with improvements that can be made. Read the suggested books from this article for the best ones that I could find.