I learn something new every day, or so it seems — often times quite serendipitous lessons. Until I read this book, I wasn’t familiar with the term “AGILE” when used to describe development projects.
The authors point out that When Nehemiah led the successful reconstruction of Jerusalem in 52 days, the project was an application of the AGILE principals — 2450 years before AGILE became a buzz word (that I hadn’t heard) Nehemiah may not have had a buzz word, but he had a vision and a plan — a simple system that he could explain and SELL to the numbers of people he needed to help him get this goal accomplished. He didn’t let worriers or naysayers or enemies mess with the system — every day each one did exactly what he or she needed to do to build that day’s section of wall. Tomorrow’s section of wall was tomorrow’s business.
Using Nehemiah’s techniques in comparison, the authors then approach other modes of development and the placeholders in each Agile project. They also know that some projects won’t fit the Agile model. The writers DRUM the
Most of the case study/example items are based on application development and some of the terms will make more sense to App Developers. When I could get past these tech terms and stories, I saw some structure in the Agile model which could have application with other people and their projects — authors could apply Nehemiah’s pattern to their techniques, as could artists, builders/construction people, military people and more.
The Nehemiah Effect is one of those books that does more than think outside of the box. It goes back into the box, looking for cracks or hidden doors. While I don’t plan to build an app, am not the Master on any team, but I ‘get’ simple and how it can be better for me. If you are fortunate to be stranded somewhere with this book, you will come out more confident in how to ‘work’ what you know than you were before.