Login access is only available to associates and administrative staff.

Book Reviews

You are here

    Home Resources Book Reviews

The Business Analyst’s Handbook

Submitted by pcadmin on Tue, 2015-09-01 03:11

The Business Analyst’s Handbook. By Howard Podeswa. Independence, KY: Cengage Learning PTR, 2008.

Early in my career as a Business Analyst, my mentor recommended this book and after reading it, I would so glad she did.

This book has it all. From identifying Business Analyst tools, checklists, helpful tips, in-depth details on planning and facilitating meetings and also various Business Analysis templates to get you started.

The author does a fabulous job identifying and describing the tools that a Business Analyst should have at their disposal and describes the situations where they should be used and why.

As the book progresses through various topics, the author carefully aligns the content with industry standards such as ITIL, the BABOK and UML.

I liked that the CBAP Qualification Requirements were outlined however I think it would be beneficial to also include the CCBA Qualification Requirements, especially given how beneficial this book is to new Business Analysts.

I think this book is a must read for everyone new to the Business Analysis profession, it certainly helped me early on in my career and it is a great reference book for the seasoned Business Analyst as well.

The book is available from Amazon. As always, I would love to hear your comments.

Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise

Submitted by Kevin Aguanno on Sat, 2015-02-14 16:00

Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise. By Scott W. Ambler and Mark Lines. Boston: IBM Press, 2012.

For years, critics have been highlighting the biggest weakness of Scrum and other agile methods -- their "lightweight" approach to methodology and governance will not be accepted in most large corporations, especially those with strict regulatory-driven (and similar) governance frameworks. Some agile practitioners take a naive approach and say "we don't need managers, financial forecasting, architecture review boards, and other unnecessary restrictions because we are being agile." While this sounds great in theory, it doesn't work in the real world.

Ambler and Lines, in this new book, close the gap found by the critics and present a practical structured approach to agile projects that gives the predictability and control required by governance frameworks, while still allowing the team to be responsive to change within the framework. It is a reasonable balance between the two competing priorities.

I found the book to be easy to read, well-structured, methodical, and enlightening. With the authors' experiences running or coaching agile teams in large corporate environments around the world, the book addresses the most common barriers experienced by teams trying agile for the first time in a large organization. All-in-all, it was a VERY GOOD investment of my time and money.

I HIGHLY RECOMMEND this book to everyone -- whether new to agile, or an experienced practitioner -- who wants to know how to make agile work in complex organizations.

The book is available from Amazon.

Agile Testing: A Practical Guide for Testers and Agile Teams

Submitted by Kevin Aguanno on Wed, 2015-01-14 16:00

Agile Testing: A Practical Guide for Testers and Agile Teams. By Lisa Crispin and Janet Gregory. Toronto: Addison-Wesley, 2009.

One of the interesting impacts of the agile movement is the elevation of testers from their second-class status to being strategic participants in delivery. Under traditional models, testing often gets compromised in order to maintain delivery dates and testers are often treated as the poor cousins of the developers. In the agile model, however, testing takes on a more strategic importance.

Under the agile methodologies, testing does not just happen at the end of the project; rather, testing takes place during each iteration of the project. The result: more time to find defects and more time to fix defects resulting in a higher-quality solution. Add to that the opportunity to regression test earlier work to ensure that it hasn't been negatively impacted by the newer additions, and you have a recipe for impressive quality improvements over traditional techniques. Testers can capture metrics about the quality of the solution and the development practices and present those back to the development team at the end of each iteration as input into a "lessons learned" (retrospective) activity. In such a manner, testing becomes a key driver to project efficiency, quality, and attainment of business value. Testers are no longer the poor cousins -- they are now strategic partners.

In "Agile Testing," Crispin and Gregory give a very good description of agile testing principles and practices. They start with an overview of what agile testing means and some philosophical principles underlying the practices. Once they have addressed the necessary introductory "fluff," they dive right in to the heart of the matter, addressing how to overcome cultural challenges to taking an agile testing approach, how to select and integrate agile testers into the delivery team, and how to transition a team into using agile testing practices. For many, that alone would make a good read, but there is more -- much more.

Next, the authors address how agile teams perform four different types of testing: technology-facing and business-facing tests that critique the product and/or support the team. They seem to cover the gamut from how agile teams test non-functional requirements, testing web services and APIs, writing test cases, dealing with test data, and managing defects. This portion of the book is a good crash course in software development testing practices but with an agile spin.

A section on test automation deals with the pros and cons of this practice, as well as strategies for automation, what one should and should not automate, how to choose the right automation tool, and managing automated testing.

Finally, the authors pull things all together by walking through the daily activities of an agile tester, from estimating user stories and planning testing during the early days of the iteration, through defect prioritization and interacting with customers and developers in the middle of an iteration, to participating in demons and retrospectives at the end of the iteration. There is even discussions about what happens after the last development iteration: supporting user acceptance and final end-to-end integration testing, verifying production readiness, and more.

I have recommended this book to many others as it provides a solid background on software development testing practices in general, and a good description of agile testing practices in particular. If you have any interest in agile software development testing practices, buy this book. You won't be disappointed.

The book is available on Amazon.

Leading a Software Development Team: A Developers Guide to Successfully Leading People & Projects

Submitted by pcadmin on Tue, 2013-03-12 16:00

Leading a Software Development Team: A Developer’s Guide to Successfully Leading People & Projects. By Richard Whitehead. Toronto: Addison-Wesley, 2001.

“Congratulations! You have been promoted!… Your reward is that you have been named a team leader,…” This book’s foreword captures the slightly bemused states many technical people find themselves in when “promoted” to the position of project manager. I picked this book up to understand a bit about the IT world, but found much of it applied to anyone from a technical background being faced with the prospect of becoming a project manager. The book describes in simple terms the responsibilities of a new project manager. I might suggest it is almost an A-Z guidebook, covering everything from specific responsibilities, to organizing a team, motivating team members, approvals, meeting management, leadership, and a high-level overview of the design process. It does not address Agile or the detailed design process, and this is NOT a book about software development.

Richard Whitehead’s style is straightforward and easy to read. The book is well-organized, with good headings and titles. One could almost use this as a guidebook for new project managers promoted from development, programming, design engineers, or, dare I say it, even design or systems engineers from the traditional mechanical, electrical and civil disciplines. The reviews on Amazon were not particularly good, but I would argue that the reviewers seem to have been looking for a book on software development, rather than project management.

The book is available from Amazon. As always, I would love to hear your comments.

The Moses of Rovno

Submitted by pcadmin on Sun, 2013-02-10 16:00

The Moses of Rovno. By Douglas K. Huneke. New York: Dodd, Mead & Company, 1985.

This book is an accurate and true account of a project manager, Fritz Graebe, during the WWII Holocaust. Fritz Graebe was a German Christian engineer assigned to expand the railway lines in the Ukraine. He was horrified by what he witnessed and used his position to employ Jews and Polish peasants, in that way saving their lives while putting his own at great risk. He maintained immaculate records and documentation, and, as a result, was one of the key witnesses at the Nuremberg trials. Herman Friedrich Graebe was honoured by the government of Israel as “Righteous Among Nations” in 1965.

This book is an easy and quick read. I am almost tempted to suggest it is a must-read for all project managers. It did not embellish and at times, had notes of humour in the darkness, as Fritz Graebe works around German military officers and manipulates the system. It was a horrifying time, and, as an employee of the German military it was easier to do as you were told, not ask too many questions, and adopt a mask of ignorance by being purposefully absent during purges. Friedrich Graebe was determined to bear witness. He did not shirk his responsibilities or his moral code. His behaviour and decisions are noble examples of maintaining personal and professional ethics as an engineer and project manager.

The book is available used from Amazon, as it has not been in print for years. Maybe we can change that?

I would love to hear your comments.