Being Agile: Eleven Breakthrough Techniques to Keep You from “Waterfalling Backward” by Leslie Ekas and Scott Will. IBM Press: New Jersey (2014). 189 + xxiii pages. US$34.99.
Flexibility. Cooperation. Teamwork. Collaboration. These are all words that describe engineering managers. These are also all words that describe agile project management. Agile project management is an emerging practice to add efficiency and effectiveness to project execution, and many engineers and engineering managers are being asked to make their organizations more “agile”. Moreover, the EMBOK has added a section on agile project management, acknowledging the adoption of these practices in recent years.
“Being Agile” is a great book to help engineering managers and project team members learn tips, tricks, and new techniques in their transition from traditional project management to agile project management. The Agile Manifesto (www.agilemanifesto.org) was first published in 2001 to enhance software development. Since then, many organizations have adopted agile principles, such as stand-up meetings, Kanban boards, collaborative problem-solving, and sprints, to improve project management effectiveness. Unfortunately, many firms also struggle with this new way of doing things and despite a declaration to “be agile,” projects continue following old management styles.
Leslie Ekas and Scott Will offer eleven specific techniques to help teams move from traditional, waterfall project management to effective, agile product development organizations. The authors draw on their experience as practitioners and facilitators of agile transition in the software industry, particularly at IBM. However, many of their examples can be easily adapted for tangible product development and engineering design and construction projects.
Each chapter is built on principles and practices in which the authors share their personal stories and experiences. Then, they suggest some potential metrics to ensure the organization is driving forward in its quest to become more agile. Finally, each chapter concludes with a novel, breakthrough practice to implement agile project management in your own organization and a brief chapter summary.
For example, Chapter 1 describes the concept of “whole teams”. Like the authors, I have found myself leading, participating in, or facilitating project teams in which all participants are not available all the time. In a case where you need testing to verify assumptions in development or accuracy of coding, you may find that testing personnel are only available near the conclusion of your project. When the testing is finally completed, it’s too late – and too expensive – to make changes in the product. Often, the decision is made to launch the product anyway, leading to lower than expected sales or a backlog of bug fixes and endless quality improvement projects.
Instead, recommendations in “Being Agile” include acquiring a “whole team” that represents all necessary functions and for these staff to work together throughout the entire project life cycle. Speed-to-market improves as design, coding, and testing are done simultaneously and customer feedback is timely to development decisions. A simple metric is to track team membership from project initiation through execution and to closing and project launch.
The idea of whole teams overlaps with concepts presented in Chapter 4, No Multitasking and Chapter 10, Agile Leadership. Certainly, senior management must commit to the paradigm shift introduced by an agile approach. Moreover, customers must also understand their commitment to giving time-sensitive and effective feedback on product designs. This is also emphasized in Chapters 7 and 8.
Agile project management is not for every company and “Being Agile” focuses on the software industry. Even if your organization is not attempting to undergo the radical transformation that is introduced by agile management, engineering managers can learn from this book. In traditional staged and gated project management, teams should collaborate more and test ideas with customers frequently. Multitasking is a burden to any technical personnel and eliminating waste (Chapter 5) is a key concept to improve quality across the spectra of industry practitioners.
“Being Agile” is recommended for any engineer or engineering manager working in the software or computer industry. This is also a good book for anyone transitioning to agile principles or working within traditional project management systems but with a desire to improve productivity and efficiency. As a chemical engineer working in new product development, I admit that some of the software language bogged me down a bit; however, the concepts of moving 100% to agile practices far outweigh the few terms that were new to me.
What is your organization’s biggest challenge to becoming agile?
Teresa Jurgens-Kowal, PhD, PE, PMP, CPEM, NPDP
Global NP Solutions, LLC