Why This Book?

When I started my professional career in software development in the year 2000, my life was easy: every few weeks, my manager would give me an assignment, and I would be working on it while providing status updates until it was done. Once I had completed it, I would let my manager know, inform the quality assurance team, and have it tested by one of my colleagues on the test team. If everything was fine, I would get a new assignment; in case of any defects, I would proceed to fix them. My job was clear and simple, and I enjoyed providing good quality work on time to my manager. I never thought too much about who was using it and how; I was doing my job diligently day-to-day and taking pride in growing my mastery.

Then, on a bright morning of September 11, 2001, my husband and I were driving to our jobs toward Manhattan from Brooklyn where we lived with our one-year-old son, and we saw papers flying in the air, just regular office papers; then we saw heavy fog over downtown Manhattan – and we turned on the radio to find out whether there is a strong wind or a hurricane coming over. This is how we learned the news. I miraculously made it to my office in Brooklyn right in front of the Brooklyn Bridge, where my colleague and I watched the tragedy. One of the senior managers at the NYC Agency for Child Development, where I was working at that time, was worried whether her son, who worked for New York City Fire Department (FDNY), was safe. Later, we found out he was among the first responders to the September 11 events and never made it back. I felt that my personal duty was to support these people and families of those who suffered in this tragedy, and I applied for a software development position at FDNY.

After an extensive interviewing process, I joined FDNY, and shortly after that, I was promoted to a Java team lead. In parallel, I was assigned as an Oracle Forms and Reports developer (at that time, it was a powerful tool new to the market) to the division that was responsible for pensions and retirement support to the FDNY workforce. Soon, I found out that I was not comfortable working the same way I did before. I was not motivated by designing systems, giving assignments to my staff, and ensuring that those were delivered with high quality. I cared about the people we served. Even though I was responsible for the software delivery team, I no longer found satisfaction in just writing code and building systems; it was important to me what kind of customer experience those systems provided to the people they served. I did not see my job as writing code anymore; I saw it as delivering service to our customers, FDNY employees, the people who made me join FDNY, and whose experience I cared about.

When my team got an assignment to build a Telemetry system for FDNY establishing a workflow of prescribing, approving, and distributing controlled substances by NYC paramedics, I did not call my team to the office for a long kick-off meeting to discuss phases and deliverables, their own roles, or the new technology stack. Instead, I called the paramedic running this team and asked if we could shadow them in the work they are doing every day in the Telemetry office in Queens, NY. And this is how it started. My team and I would take our trips to the telemetry station, observe, then go back to the office to design and build, go back the next day to validate screens and sample workflows with paramedics, get their feedback, and go back to the office to make changes based on what we learned. Their existing system was slow and unreliable; it was based on email and had a heavy paper trail to maintain. We learned about their challenges and decided that it had to be a streamlined workflow with proper tracking, and most importantly, the cycle time from when the request from the field comes in till the decision is made by a qualified medical professional and approved via the required channels had to be limited to seconds because it was literally a matter of life and death. We were not motivated by writing clean code; we were motivated by saving people's lives, by thinking of those whose lives depend on us. We delivered the minimum viable product, or MVP (at that time, we were not familiar with this term), Telemetry system in three months to the highest satisfaction of our stakeholders and got the FDNY award for this application.

Frankly, at that time, we were not aware that the world was already open to these principles. The Agile Manifesto was already created in 2001. The understanding of customer interaction, the value of incremental delivery, the concept of MVP, and the benefit of developers working with the business and their customers were already known to the software world. However, my personal journey to Agile software development taught me these values through my own life experience, and it became my life goal to share them with others.

In over 20 subsequent years of my professional career, having led organizations in their digital transformations and changing the ways thousands of people deliver IT products to the customers, I have not been more proud of the work that my team has done. Nowadays, when I interview software developers and ask them what their biggest professional passion is, I hear a lot that they enjoy learning about new technologies, writing elegant code, implementing cutting-edge IT solutions, or designing new cloud infrastructure, but frequently, they are missing the most important part of software delivery – the product we are building and the customers we are building it for. This is the passion I pass to my students of Agile Project Management and Principles of IT Project Management at New York University – passion for Building the Right Product along with Building the Product Right – and now I am passing it to you.

Why Today?

Despite Agile software delivery becoming a mainstream way of delivering IT products and services to customers, our higher education institutions are still significantly behind in the way we educate our students. I am proud to be part of a team that makes an effort to build education around customer-centricity and product-based thinking. The concepts of design thinking, validated learning, user research, and incremental delivery are now included in college curricula around the world.

However, this process is still slow, and many higher education organizations are still teaching their IT students based on traditional concepts of phased software delivery (also referred to as “Waterfall” because of the sequential nature of IT delivery – Conception, Initiation, Analysis, Design, Construction, Testing, Production/Implementation, and Maintenance) and ignoring that modern technology supports rapid delivery. There is no need to wait until the analysis is completed to design the system and no need to wait until the system is fully designed to start building functionality for users to test and provide their feedback about.

Frequently, college graduates come to job interviews with high grades but without a clear understanding of how customer needs impact the software delivery process. They are well prepared to answer questions about multitenant databases, architectural design principles, microservices architecture, cybersecurity, authentication, and machine learning, but they are not aware of the nature of a cross-functional team or the value of collaboration in IT delivery. Instead of thinking end to end from envisioning their system to the experience their customers have and the value these systems provide to the customers, they think code, testing, security, automation – all the right topics, but definitely not sufficient for IT professionals nowadays.

We are not designing systems for the sake of building them. We do it to provide value to our customers in order to empower them in solving their regular challenges – whether it is to buy food from a store, build a house, give education to their children, or manage their life’s savings. We build systems for people, and the goal of this book is to facilitate and expedite the transition from an execution-focused approach to a customer-centric one.

This ability proves to be career changing nowadays. In my experience, IT professionals who employ product-based thinking, who care about their customer experience, and who understand the need for incremental delivery and risk management have a significantly higher chance to advance in their fundamental knowledge as well as in their career progression. While there are thousands of IT professionals who have advanced technical skills, the understanding of customer value and team-based delivery proves to be a career-changing differentiator in getting job interviews and landing the best job opportunities. Those IT professionals who understand both how to build the right product and how to build it right have a career advantage over those who are only focused on the technical aspects of IT delivery.

Who Is This Book For?

This book is meant for graduate students and early career professionals who want to advance their careers to the next level. While the primary audience is graduate students in computer science and engineering, every professional will benefit from getting themselves familiar with the concepts described in this book. The examples used in this book are primarily related (though not exclusively) to computer science and IT, including software products and services, IT operations, computer hardware, and telecommunications. It touches multiple industries and provides real-world examples in IT and beyond.

There are two ways to read this book. First, it is a textbook. The concepts provided here cover product envisioning (building the right product) and delivery (building the product right), intertwined in the concept of incremental and iterative delivery. Each chapter is built on previous ones and is equipped with learning materials, tips, references, and case studies. If you are a college professor, you can take this as a textbook for your IT project management, Agile delivery, or software delivery life cycle (SDLC) course – it has questions, quizzes, and a list of material for extra studies. There is a project throughout this course where each assignment builds on the concept learned in class. If you are a student, there are templates, concepts, and techniques that will prepare you for the real world of IT delivery. This book will also prepare you for a job interview and establish foundations for your success in the workplace.

Second, this book can be used for self-learning, whether sequentially or as a reference book. In the Glossary, we provide references to major concepts related to modern software delivery. For project managers, IT managers, or HR professionals, this book provides an interactive and powerful guide to mastering complex concepts of IT delivery in a simple, concise, and logical way. If you are an Agile practitioner, this is a way to get a comprehensive overview of this important area of study as well as get helpful tips on common challenges, such as getting leadership buy-in for Agile transformation or which framework to pick for your enterprise. If you are a new Scrum Master or a development lead on a newly created Agile team, this book will provide a solid foundation for your Agile thinking.

It is not a replacement for your software delivery or IT project management textbook, even though it can be successfully used for either course – it is a new book for a modern generation of software engineers, IT professionals, and forward-thinking and customer-centric leaders.

The Legend

Disclaimer

None of the content of this book directly reflects on my employment experience, past or current. Any company-specific examples and case studies referenced in this book are either fictional or based on public sources.