Introduction to Agile Methods Book Review

At the beginning of the book the authors say they created this book to be used in a classroom setting. I agree that it is a great book for the classroom, but I would also recommend it to anyone who wants to learn about the current Agile methodologies. It does what the title of the book says it does, and it introduces the reader to Agile methods. It starts with a nice introduction to the Agile movement's history and then covers all the traditional topics that fall within the Agile purview. I have listed the chapters below to give you a high level view of the topics covered. Chapter 1. The History and Value of Agile Software Development Chapter 2. Organizational Culture Considerations with Agile Chapter 3. Understanding the Different Types of Agile Chapter 4. Describing the Different Roles Chapter 5. The New Way to Collect and Document Requirements Chapter 6. Grooming and Planning Chapter 7. Testing, Quality, and Integration Chapter 8. Tracking and Reporting Chapter 9. Agile beyond IT Appendix. John Deere Case Study I was initially worried about this book because the very first sentence has a typo, but that wasn't a problem throughout the rest of the book. Just really bad luck. This book is a snapshot of Agile processes and practices as they are taught in the software development world at this time. The Agile processes and practices in this book address small team development. They don't go into large distributed or enterprise level projects that would use Disciplined Agile Delivery (DAD) or Scaled Agile Framework (SAFe). They do hit a very broad range of subjects and cover them in enough detail that you walk away with a level of understanding that would allow you to work with an Agile team. They introduce Extreme Programming ( XP), Scrum, Feature-Driven Development, Dynamic Systems Development Method (DSDM), Lean Software Development, Kanban Method, and Crystal Family in one chapter. In the chapters that follow, they use different parts of the methodologies to explain how to accomplish tasks in an agile way, that are part of a normal software development lifecycle. Some examples are defining roles, eliciting requirements, planning, tracking assets, reporting, and developing. Throughout the book the authors have interviews with leading Agilists. This is a nice touch because this introduces real world experiences. The author's use a fictitious company named Cayman Design to show how some of the topics they cover would be executed. Cayman Design is moving in the Agile direction. For those starting to learn Agile processes and practices this book is the perfect place to start. It is necessary to learn how things should work, before learning how they really work. Meaning being agile is not easy, and there are a lot of books out now based on that fact. They include experienced based on the projects that fail, the few that succeed, and the many that are sold as successes. I would start here though if you are just starting with Agile. Let's make it three times in one paragraph, start here!! In real world development projects processes should be tailored for a given project. Allowing you to account for your team's skills and availability, your business's needs, the tools you have available, the environment you are working in, the difficulty of the solution, the working environment - team member locations, greenfield vs. brownfield development, and many more things that are usually not taken into consideration when a project is started. People leave, laws change, hurricanes happen, people get sick, and so on. The point is your process must be as agile and resilient as the software you create. That means the process must be changeable, extensible, as simple as it can be while still getting the job done, understandable, and the people involved must have the skill level to execute the required tasks. Always being low ceremony does not work. Low ceremony projects are smaller lightweight projects. They produce less documentation and artifacts in general. Low ceremony does not have anything to do with being agile, although many times experienced teams will run projects at the lower ceremony than a less experienced team would be able to. Agile is an enabled state that is only accomplished through experience. It can be learned, but absolutely not by doing less. This book helps the reader understand all the tasks in typical projects so that when you come across a tailored process you will have an understanding of the roles and activities being performed. Bill Gates said, "The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency." The same can be said about Agile and Lean practices: The first rule of any software process used in development is that Agile and Lean practices applied to an efficient development team will magnify the efficiency. The second is that Agile and Lean practices applied to an inefficient development team will magnify the inefficiency. There are two primary things you need to be part of an environment that uses Agile processes. The first is enough experience to execute your role's activities in a way that enables agility, and the second is an understanding of the Agile processes. This book can give you the later of the two. I highly recommend this book to teachers and to those who want to start learning about the Agile methods.

Introduction to Agile Methods

Introduction to Agile Methods

Developing Quality Technical Information: A Handbook for Writers and Editors, Third Edition Book Review

As an enterprise and software architect the one thing I hate most about my job is documentation, yet the importance of doing documentation on sizable projects is what I find myself preaching about the most. One reason I understand the importance of documentation is that I came from an electronic engineering background. As an electronic engineer 93% - 97% of my time was consumed doing proof of concepts and documentation. Almost all of that time was documentation. It was just my luck that my boss was an English grammar teacher before moving into engineering. My documents came back very bloody. He used a red pen to mark up my documents. It took me 2 years, and a whole lot of tongue biting, but I started getting papers through him without a red mark. I still remember the first one. I walked outside to where the smokers took their breaks and let out a screaming "YES, Finally!!!" I have been without my grammar teaching boss for over 18 years now, and I am pretty sure if he came across the book reviews I am writing now, he would be sending me bloodied up copies!!! I really needed this book!! Technical documentation is a hard skill set to learn, at least doing good technical documentation is. I have been on Template Zombie projects where teams considered documentation complete when they had filled in enough templates to overwhelm the customer to the point where they would not have time to review 1/10 of what was being written. One project I was on built a documentation generator so it was easier to duplicate documents and only change the title and a few pieces of content. The sad part of that project was they got paid for each document handed in. The criteria for getting paid for use cases were that they had to have something underneath every heading in the document. Documentation should not be something you check off of the project's task list, it should add value to the project or it should not be done. This book will definitely help you make valuable documentation. I have listed the chapters below to give you an idea of what the book covers. Part 1: Introduction Chapter 1. Technical information continues to evolve Chapter 2. Developing quality technical information   Part 2: Easy to use Chapter 3. Task orientation Chapter 4. Accuracy Chapter 5. Completeness Part 3: Easy to understand Chapter 6. Clarity Chapter 7. Concreteness Chapter 8. Style Part 4: Easy to find Chapter 9. Organization Chapter 10. Retrievability Chapter 11. Visual effectiveness Part 5: Putting it all together Chapter 12. Applying more than one quality characteristic Chapter 13. Reviewing, testing, and evaluating technical information Part 6: Appendixes Appendix A. Quality checklist Appendix B. Who checks which characteristics? Glossary Resources and references When I came into the Dot Com Boom I found some software engineering, but most of what I found was the wild west and cowboy coding running rampant. The industry has not changed much since then. We just gave names to the chaotic processes to justify our lack of discipline. I continued my engineering practices and quickly learned how to document software processes and architectures, but convincing others to do it was a different story. The only way I have been able to show it has value is do it myself. After the team sees I am willing to suffer the boredom of documentation they tend to step in and help. That wouldn't happen if we didn't make use of the documentation and they didn't see value in it. It has been years since I have had someone to officially review it. This book really helps keep the important things in mind, and since there is no one else to review it, I can use all the help I can get. Right now one of the things I do to catch issues in my documents is have them spoken back to me using the speech capabilities on my computers. This helps me catch sentence structure issues, and some typos. It doesn't catch using the wrong their/there, insure/ensure, except/accept, and many more like sounding words that I mess up. I use Sparx Enterprise Architect to document systems. Behind every diagram you find the information that explains them. If that information is not simple to understand, and easy to read, the diagram's value falls greatly. Throughout the process you need to write for several different audiences. Your stakeholders are interested in different aspects of the system. Creating a clear view of what each type of stakeholder wants to see is a painful process, but it always pays off. It makes me think about the solution from angles I normally wouldn't. Not only think about them, but diagram and describe them in a way that the solution's diagrams and associated documents can stand on their own. It makes me justify and clarify all the decisions made about the system, before it is in production! Doing documentation is like coding. You start with a shell of what you are building, and you add the details to the different topics with each iteration of your development cycle. Your goal- to make simple, complete, accurate, logical, easy to understand documents. That is exactly what this book will guide you to do. There are tons of examples showing the original text, diagram, or screen shot of a design, and then the revised version. There are two really cool appendices and a nice glossary. The first appendix is a huge checklist for quality characteristic. The second appendix is a big chart showing which roles should be reviewing the different aspects of the document. Over all I found every chapter of this book valuable. As time goes on, the hardest part for me is keeping it all in mind. For that reason, this book will be staying by my side just like each of my current most useful programming books. If you do any documenting of software systems, this is a must read. Every software architect, enterprise architect, CIO, developer, tester, and project manager working on a software project, should have this book in his or her hands. You own to your stakeholders and yourself.

Developing Quality Technical Information: A Handbook for Writers and Editors (3rd Edition)

Developing Quality Technical Information: A Handbook for Writers and Editors (3rd Edition)