Meet John Bergin

CSP John Bergin lives in Arlington, Virginia, and is the Business Technology Officer for the Department of Defense Chief Information Officer.

For you, what is the main difference between where you began as a CSM, CSPO, or CSD and becoming a CSP?
Becoming a CSP shows my team and peers that I took the classroom experience, and demonstrated my proficiency in applying best practices to real world situations that delivered tangible results. The earlier certifications imply an understanding of the concepts and best practices, while the CSP indicates real-world proficiency.

What is your favorite part about being a CSP?
I enjoy participating in events with other Agile professionals. The events and opportunities to meet both virtually and in person with other experts in the field have opened my eyes to new opportunities and different ways to approach common problems.

How did you first find out about Scrum?
My former employer, EMC -- a large technology firm that was ranked 128 on the Fortune 500 list in 2014 -- sent me to Scrum training in order to serve as the product owner for a new development effort. EMC invested in Agile to deliver outcomes that would meet the business's needs in a fast-changing environment.

What do you find easiest about Scrum?
Nothing was easy at first! Adjusting my own preconceived notions of how to meet the business's needs, working through "the first Agile project" at EMC, and managing a globally dispersed team all were significant challenges. However, following the practice of daily Scrums and frequent prioritization sessions with the team and the customers allowed us to complete our project ahead of schedule and under budget. Utilizing the tools that Scrum incorporates, we overcame multiple language barriers, time zone issues, and physical location challenges to build single team working together.

What do you find most difficult about Scrum?
Interpersonal relationships between the ScrumMaster (SM) and the product owner (PO) are critical. All the other relationships can be worked on over time, but if the PO and SM do not work well together, conflict is bound to ensue.

What's your best/worst work experience using Scrum?
I believe that many POs would agree with me when I say that my best experience was delivering our first "product" more than a year early, and with half of the functionality required of the final product. Understanding the business's needs and delivering a just-in-time solution allowed EMC's Global Services division to achieve significant efficiencies and operational improvements prior to the formal "Full Operational Capability" announcement. That product, both the interim and the automated final, are still in production more than three years later.

How has using Scrum changed you?
Scrum has reinforced my belief that requirements matter and that requirements constantly change. Understanding that the requirements for a solution in January may no longer be relevant, or as important, in November is very challenging for the team that spent the intervening months building the capability. Every PO has experienced building a feature that was driven by "one loud voice," and I believe we all grow through that experience to become fanatics about quantifying the value of the requirements we are prioritizing.

If you could add one thing to Scrum, what would it be?
I would like to see people using the Scrum techniques outside of standard development environments. During my tenure with Booz Allen, I lead my consulting teams through a modified daily Scrum call. Scrum works well for me, because I believe that it balances accountability for objectives and the team spirit that are both essential to successful Scrum projects.

What advice would you give to someone new to Scrum?
I would recommend that you sit in on other Scrum meetings outside of your organization or team, find a way to see how your peers are running their meetings, and take away both the good and bad from that daily call.

Someone asked me once about how to prep for an interview at an "Agile development"-style company, and I suggested they do the same thing. Before joining an Agile team, I recommend sitting in on a Scrum call. That call will tell you if this is a well-oiled machine or a disaster.

What is your favorite quote? And why?
"It is better to beg forgiveness than to ask permission." My experiences working with development teams, civilian clients, and military clients have consistently shown me that everyone wants a path to "yes." In my experience, the easiest way to get people there is to show them a minimum viable product or an adoptable, relatable framework.