Managing the Dynamic Datacenter

Datacenter Automation

Subscribe to Datacenter Automation: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Datacenter Automation: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Datacenter Automation Authors: Elizabeth White, Pat Romanski, Liz McMillan, Glenn Rossman, Moshe Kranc

Related Topics: Agile Software Development, Datacenter Automation, Microsoft Developer

Blog Feed Post

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

Read the original blog entry...

More Stories By Tad Anderson

Tad Anderson has been doing Software Architecture for 18 years and Enterprise Architecture for the past few.