Tag Archives: Scrum

Are you a Veteran moving into Tech? Yes? Then forget about the PMP.

Are you a Veteran or transitioning servicemember interested in obtaining your PMP and looking to jump into a tech job with (hopefully) one of the industry greats like Amazon, Apple, Google, Facebook, Microsoft, T-Mobile, AT&T, Capital One, Need I Go On? Not so fast!

PMP (Project Management Professional) certifications are becoming virtually obsolete in the technology industry. In thinking about your transition and employment goals and desires, ensure you’re future-proofing your plan as much as possible. Just as we don’t build tomorrow’s technologies on yesterday’s platforms, if you want to work in tech you need to build your resume for the future and not base it on certifications of the past (at least in this industry).

Alternatively, if you are interested in working for companies and institutions like public utilities, construction, shipbuilding, manufacturing, or in other complicated environments, then the PMP probably is the best answer for you and the right way to go. True, there are many manufacturing (hello Lean!) companies increasingly becoming agile, and many other industries and sectors are experimenting with agile methodologies and applications. However there is more than enough traditional project management work out there if you’re flexible about where you’re going and what you’re managing.

If the traditional project management world is where you want to be, the good news is that everything you’ve learned throughout your military career  has set you on course to fulfill your PMP requirements and obtain your certification. We wish you the best of luck!

If, however, the tech industry is where you want to be, then don’t waste your time on the PMP. Instead, start learning how to leverage your knowledge, skills, and experience operating in the complex environment of technology.

Your first challenge is going to be the reality that many of those very same technology companies do not fully understand what they are seeking in a job candidate. Companies which regularly espouse their “agility” and agile practices still put “PMP” on their hiring sheets in either the “Required” or “Desired” skills section. I guess because it is the way they’ve always done it (terrible!) and it’s like a warm, snuggly blanket of reassurance in the otherwise dark night of human resource uncertainty.

Yet typically once you get to the interview, things fall apart because – it turns out – the people hiring you are not the people who put the proverbial ad in the paper and they ask you questions about obscure, farcical conceptions such as Agile, Scrum, Lean, SDLC, Test Driven Development, iterations, continuous improvement (hey that one at least sounds good), and a host of other words that are relatively alien to a standard PM.

Unfortunately, those words are the core components of their business methodology, and the PMP has absolutely nothing to do with any of those concepts (although continuous improvement still sounds good).

The good news here is that your knowledge, skills, and experience actually are the key abilities technology companies seek, although it often requires some translation on your part. The first part of translation is knowing the language, so you need to start learning about Agile. Today.

Here are just a few ways to get started.

  • Look into the PMI-ACP (Agile Certified Practitioner) certification. There are lots of courses and strategies for getting the knowledge you need – the actual hands-on experience may be harder, but this is a great certification which gives you the exposure, vocabulary, and talent to show that you understand Agile theory, methodologies, and practices.
  • Take a course on Lean. This is another great agile methodology more geared towards manufacturing but which is making inroads and holds applicability to many areas of the tech industry.
  • Take a CSM (Certified ScrumMaster) or CSPO (Certified Scrum Product Owner) class. This will give you a few glimpses of what Agility is and will teach you about Scrum, the overwhelmingly most popular Agile framework in the market today. There are classes all over the world and a basic certification can be achieved in two days.
  • Check out any of the numerous books about Agile methodologies and thought.
  • Get involved in Agile discussions on LinkedIn, blogs, and other online sources. See if there are any Agile Meetups in your area, and go  to them. Agile practitioners love to talk about Agile, so leverage that.

Additionally, get online to resources like Code School and PluralSight (who own Code School) and start learning about software development, at least at a basic level. You’ll be amazed at how far apart this knowledge alone can set you from your competition.

Remember, this may take some creative selling on your part, as well. I’m regularly surprised to see the number of established companies recruiting for an agile project manager who have no idea what “agile” actually means. This is a fantastic situation for you – as an interviewee. You can actually educate them.

However to do that, you must be prepared and armed with the knowledge you need in order to have the conversation in the first place. So forget about the PMP and invest in yourself and in the studies which will prep you to get into the tech giants of today and tomorrow.

Share This:

Six False Assumptions That Are Killing Retrospectives

These six commonly accepted (but false) assumptions about retrospectives are killing innovation and hindering your teams’ future execution.

  1. Retrospectives are meetings
  2. A retrospective length is dependent on sprint/iteration length
  3. Retrospective variety ensures team members do not get bored
  4. There are three basic questions in a retrospective
  5. The Scrum Master or Agile Coach must facilitate the retrospective
  6. A retrospective is designed independently of other Scrum/Agile events

1. Retrospectives Are Not Meetings

Retrospectives are not meetings. Retrospectives are events. Why is this important? We know that words have meaning and if you look at the definitions of “meeting” and “event” you will see that a meeting is an assembly of people for discussion or entertainment. An event, on the other hand, is something that occurs in a certain place during a particular interval.  Meetings start late and end late, and to be honest, meetings are typically a waste of time. Events are structured, start and end on time, have a purpose, and dare I say it, follow a process or method.

2. Retrospective Length is Independent of Sprint/Iteration Length 

The time needed for a retrospective is independent of sprint or iteration length. For example, a four-week sprint does not require a four hour retrospective.  A one hour retrospective is enough time for a high-performing team to identify the handful of action items required to improve their future execution, regardless of the sprint length. An average team, on the other hand, may need up to two hours to help them build individual and team retrospective muscle memory.

To maximize the amount of work not done, a team only needs to gather data (what went well/ what didn’t go well) for five events (planning, standups/communication, sprint execution, review, and retrospective) and this can be done in as little as ten minutes—shorter with a well-practiced team.  Analyzing sprint execution (generating insights), conducting a root cause analysis, and developing action items (lessons learned) are where the team needs to spend the majority of the hour.

Consider this: a four week sprint will have more standups and more execution days than a one week sprint, but this does not equate to a 4x increase in the amount of time needed to gather data in a retrospective. A high-performing team should be able to glean all their learning points from a 2-6 week sprint within the span of an hour. Anything more is a disrespectful waste of the organization’s money and the team members’ time.

3. Retrospective Variety is NOT the Spice of Organizational Life

Boredom: “an aversive state of wanting, but being unable, to engage in satisfying activity.”  

The idea of trying out a new retrospective activity (game) so team members do not get bored is misguided. The perceived or actual boredom displayed by individuals or teams toward retrospectives may be (1) a result of the type of work the team is doing, (2) a lack of understanding of the retrospective activity and/or a failure to achieve actionable outcomes, or (3)  the fact that great retrospectives are hard as they challenge people to be open and honest—we also know that boredom is a result of being too challenged.

Let’s assume that knowledge workers are challenged each sprint or iteration and their work is not the source of the perceived boredom. How does changing the retrospective activity (game) address the averse state of wanting to be engaged in a satisfying activity? And if retrospectives are perceived as being too challenging, then why would one believe that changing the activity would pacify this root cause of boredom?

Consider these points if you continue to believe changing up retrospectives in the name of boredom is a smart idea:

  • Inconsistent retrospectives, in structure and/or frequency, lead to mediocrity. According to Jim Collins, “The signature of mediocrity is not an unwillingness to change. The signature of mediocrity is chronic inconsistency [1].”   
  • Repetition. Repetition. Repetition. Learning something new, awkward, and difficult requires some repetition. It takes a while to get used to opening up, being self-critical, and learning how to respectfully challenge each other in and out of a retrospective.   
  • According to Doug Sundheim, “Debriefing (Retrospective) is a structured learning process designed to continuously evolve plans while they’re being executed.”
  • Culture is a product of retrospection. Edgar H. Schein points out that “culture is the result of a complex group learning process [2].”
  • Innovation is a product of interactions, and common processes that accelerate those interactions are necessary. According to a recent McKinsey Quarterly article, “…innovation is a complex, company-wide endeavor, it requires a set of crosscutting practices and processes to structure, organize and control it [3].”
  • So not only will “variety” in your retrospectives not produce desired results, it will also have a negative impact on your team’s ability to improve.

4. The Two Most Powerful Questions in a Retrospective Are:

  1. What was the primary objective?
  2. Did we achieve what we set out to do? Did we achieve that objective?

Why are these the most powerful questions during a retrospective? Simple: alignment. If the team is not aligned, if individuals cannot succinctly restate the sprint objective, then we (organization, leaders, Agile Coach, Product owner, etc.) have failed to establish the necessary conditions for the team to become empowered [4].

With an aligned team, the answer to the second question should be binary (yes/no) assuming the primary Sprint objective is clear, measurable, and achievable. Moreover, the primary Sprint objective should be connected to the external effects on the economic system (i.e. business value) and not an internal measures of performance (e.g. ready stories, velocity, burndown, etc. ).

What Went Well? What Didn’t go well? What can we do better? These three questions are commonly used and thought of as a proven retrospective design or process instead of as techniques that are helpful in gathering data and deciding what to do. Caution,  a real danger exists when asking a team “What they can do better?” if they do not share a common picture of “What” happened, understand “How” that something happened and, more importantly, “Why” it happened (root cause analysis). In a later post I will go into more detail on how a self-similar activity used in strategy and product development (What-How-Why) can be a powerful tool in building action items in retrospectives.

5. Who Facilitates?

A lot of people look to the ScrumMaster or Agile Coach to facilitate a retrospective, and indeed, when a team is just learning how to conduct and participate in a retrospective, this is important. However, the retrospective should be viewed as a leadership episode, where leadership is valued over facilitating the event.  In complex systems, leadership “takes place during interactions among [team members] when those interactions lead to change in the way those [members] expect to relate to one another in the future [5].”  How members relate to each other in the future is directly connected to how a leader (a person in an actual or perceived position of some authority) establishes a safe environment during the retrospective (a leadership episode).

The Product Owner’s position on the team is better suited for establishing this safe environment as they generally have over 51% of the vote when it comes to the product vision and backlog. On the other hand, the ScrumMaster or Agile Coach are often contractors or viewed as event facilitators, protectors of the framework, thus making the crucial step of setting the tone (establishing psychological safety) problematic. Development team members are also great candidates for leading the retrospective and should be given the leadership opportunity when the team is comfortable with a proven retrospective process.  It is perfectly acceptable for the ScrumMaster or Agile Coach to coach whomever is leading the retrospective during the actual  retrospective execution and then follow up with a one-on-one retrospective using a self-similar process.

6. The Leadership Pattern within a Retrospective Should be Tightly Coupled with Leadership Patterns of Other Events

Iteration or Scrum events should be viewed as a whole and not as standalone parts of a system. Just as Scrum exists in its entirety, the leadership patterns of each Scrum event should be tightly coupled (have interdependencies) where the relationships among those patterns work together in some fashion. Combining an off-the-shelf retrospective game with an ad hoc planning process (the letting the team figure it out approach), for example, is counter to basic Systems Thinking.  Leadership patterns within system events need to be connected. How a team plans, how it conducts its standups, and how it executes its sprint must be connected to how the team holds its retrospective.   

To illustrate this point, consider Russell Ackoff’s example of taking the best parts from 450+ different cars (best transmission, best tires, brakes, cooling systems, belts, spark plugs, etc.,)  and trying to put those best parts together to make the best car. The parts do not connect and therefore you do not have a car, you have a mess. The proliferation of retrospective games, ones that are designed independently of other Scrum events, are the equivalent of those incompatible best parts – they only contribute to an Agile mess.


Brian “Ponch” Rivera is a recovering Naval Aviator and Commander in the U.S Navy Reserve. He is the co-founder of AGLX, LLC, a Seattle-based Agile Leadership Consulting Team, and a ScrumTotal Advisory Board Member.



[1] Jim Collins, Good to Great: Why Some Companies Make the Leap…and Others Don’t (HarperCollins, 2001)

[2] Edgar H. Schein, Organizational Culture and Leadership, 3rd Ed. (Jossey-Bass, 2004)

[3] Marc de Jong, Nathan Marston, and Erik Roth, The Eight Essentials of Innovation. McKinsey Quarterly April 2015

[4] Senge, P. M. (1990). The fifth discipline: The art and practice of the learning organization. New York: Doubleday/Currency.

[5] Hazy, J. Goldstein, J, & Lichtenstein, B.B. (2007). Complex Systems Leadership Theory: New Perspectives form Complexity Science on Social and Organizational Effectiveness. http://emergentpublications.com/documents/9780979168864_contents.pdf?AspxAutoDetectCookieSupport=1

Agile <a href=”http://www.canstockphoto.com“>(c) Can Stock Photo</a>

Share This: